Beyond Execution

Have you every worked with people who can't see the forest for the trees? That is, folks who tend to deal with the details and not think about the higher level principles or strategies that drive the lower level tasks? If you think in the opposite way, or if you need to determine the high level first, then this can be become frustrating if you are not able to overcome the difference.

Fortunately, I've found a way around it, which seems to work fairly effectively. It's the same approach as determining root cause - 5 Whys (sometimes also referred to as 7 Whys). This method is used by Toyota and is a critical component of problem-solving training. According to Wikipedia, the tool has seen widespread use beyond Toyota, and is now used within Kaizen, lean manufacturing, and Six Sigma. As the approach usually states, 5-7 whys is the upper limit as to how many times you need to ask. One should be able to determine the root cause within or earlier than that range.

I was recently helping my client come up with a strategy document for licensing examinations. The first draft had what I would call a lot of detailed statements, as opposed to higher level, strategic points. For example, stating an examination is computer based doesn't address the reasons for making that approach. By asking why, we find that the first level above states: To make it easier to take and easier to mark. As we continue with "whys", we find a core of high level reasoning: reduce errors/bias, increase speed of results, increase test taking flexibility and increased security.

Once each statement has a higher level reason attached, then the reasons should be grouped together to common strategic "legs" or "pillars". Ideally there should be a core group, no more than 3-5 legs in total. If there are more than 5, it might suggest 2 things:

1. There is overlap amongst the legs. More consolidation may still be required
2. The strategy is too broad. Consider reducing the scope. If there are still more than 5, pay attention to how these strategic points will be implemented and measured.

Since the 5 Whys approach is kind of associated with Root Cause Analysis, I'd like to call this technique something else to differentiate it: "Reverse-Decomposition". This approach can be used in a number of different project management development approaches - WBS (not re-useable projects), Risk Breakdown Structure, Quality metrics, and continuous improvement programs. Perhaps I'll come up with some easy-to-remember acronym.

Good luck in using this approach.