“Dilemma” is term properly reserved to describe a situation in which we must choose between two more-or-less equally unpleasant alternatives. This pretty much sums up how most organizations feel about documentation for Six Sigma projects.
On the one hand, there is always an organizational craving (note that I am specifically avoiding the term “need” here) for templates, documents, forms, and metrics that can feed the dreaded “roll-up” of information. These roll-ups often result in dashboards or scorecards that are supposed to be used to make decisions and steer a program.
On the other hand, there are Black Belts and their teams who are probably already working 16 hour days and still not finding enough hours to get everything done. They are digging deeply into problems and opportunities using techniques and tools they have been trained to use at great expense to the organization. They see documentation mostly as a distraction (“non-value-added work,” they will knowingly mutter) and something that takes away from their more important tasks.
A dilemma indeed. On the surface of it, the organization has to choose between having limited visibility and little information on which to base decisions, or saddling the “best and brightest” with a lot of busy work filling out incredibly repetitive templates and forms. Neither alternative is palatable.
In a sense, the answer is simple: strike a balance. But from what I’ve seen, finding that balance is very tricky, and organizations rarely get it right.
Part of the problem is that often the higher one goes in a company, the more simple and summarized information becomes. This phenomenon drives a pyramid of information collection in which many people at the bottom scramble to produce information and reports in a pre-determined format at whatever frequency is seen as “necessary” to a small audience at the top. The “roll-ups” thus produced containing a surprisingly small amount of information which may or may not accurately reflect what is actually going on. This is almost certainly not what the folks at the top want to have happen, but it’s usually what does happen.
At the other end, Black Belts and template designers often prefer to provide information that is easy to provide, rather than what is useful. Automated software “solutions” are terrible for this, enabling the tendency rather than reversing it. For example, many electronic dashboards ask users to enter project phases so they can show a roll-up of, for example, what percentage of projects are currently in the “improve phase.” This is what I like to call a “feel good” metric; it doesn’t really mean anything, so the presenter can spin it any way they want to make the audience feel good. Number of projects in the improve phase going up this month? Great! We love improvements! Number of projects in the improve phase going down this month? Great! More project proceeding towards completion! I can’t imagine a scenario in which we could make a decision based on a metric like this, but it makes us feel good to see it displayed (in color) on a dashboard. Trouble is, it takes a huge number of people building and maintaining projects plans, then doing data entry on a repeated basis, to generate the dashboard. It’s a huge investment of time just to make a few people feel good.
And no small part of the problem are the template-and-form crowd (which includes me, by the way). Buy a few drinks for your table at any Six Sigma conference and you’ll soon hear a litany of complaints about being forced to re-format templates so they are in the “right” font, or fit on two pages instead of three, or meet any number of other arbitrary requirements. Black Belts hate doing all this, and the people who have to provide the roll-ups hate it when Black Belts don’t do it.
So what to do about all the dilemma? Like I said above, the answer is simple: find the right balance. Design project tracking processes to be minimal in terms of the work required. Ask only for information that will inform decisions at some level. Provide a mechanism to flag problems and exceptions when they arise rather than monitoring whatever is convenient to monitor. Roll-up where you need to roll-up, but don’t assume the recipients of that rolled-up information are incapable of understanding complicated relationships between variables and non-intuitive conclusions. In short, treat documentation like a process, strive to manage the inputs and outputs, and keep your Lean and Six Sigma hats on when you do so. Easy to say, very hard to do it right.
