Get 
Hey, it looks like you're new here! If so, you should get your free copy of the first 3 chapters of my upcoming book (Recently I posted a quick-and-dirty guide to process improvement. One particularly difficult question that I skipped over in that post was this one:
When you are mapping your workflow, how do you determine the ideal level of granularity? In other words, how much detail is too much?
Conventional wisdom is that:
- Planning and execution are two discrete activities (remember this assumption)
- The key to good execution is lots and lots of planning (which tends to mean planning at a very granular level)
Conventional wisdom is wrong, however. And this is evidenced by the many examples of poor execution we encounter on a day-to-day basis.
My argument (and this is classic TOC) is that, above a very low detail threshold, more planning actually means worse execution!
In other words, in most cases, to execute better, you should plan only at a high (non-granular) level.
The relationship between granularity and confidence
Let’s imagine that we are planning a simple workflow – getting to work in the morning. Here’s a high-level (low-detail) plan:
- Get out of bed
- Shower
- Get dressed
- Drive to work
- Log-in to computer
And here’s the low-level (high-detail) one:
- Upon awakening, check to see if alarm is sounding
- If so, deactivate alarm
- If not, check to see if current time is greater than [alarm time minus 10 minutes]
- If so, cancel alarm and get out of bed
- If not, go back to sleep
- And so on …
Imagine that you completed the second (low-level) plan, and then compared it with the first – and answered this question for each plan?
Rate your degree of confidence that reality will play-out as specified in the plan? In other words, how confident are you that each of these activities will be performed in exactly the sequence specified?
My guess is that you will be highly confident where the first plan is concerned – and not-at-all confident in the case of the second.
In fact, it’s probably worse than that. In the case of the second plan, you will likely be certain that reality will not play out as specified by the plan.
The irony is that the second plan creates a perception of accuracy, in spite of the fact that your confidence in the plan is practically zero!
Finding the inflection point (essential and non-commutative)
It’s tempting to assume that there’s a linear relationship between granularity and confidence (that they vary in direct proportion). And, if that’s the case, there’s no correct answer to the critical how much detail question.
The reality is that the relationship is definitely non-linear: as the granularity of the plan increases incrementally, beyond a critical detail threshold, your confidence in the plan plunges rapidly towards zero.
Here’s why:
- All the activities in the first plan are essential (you simply can’t skip any)
- Each activity (relative to its predecessor or successor) is non-commutative – meaning that you can’t swap the sequence without dramatically changing the outcome
However, with a slight increase in granularity, these two conditions cease to apply: not all activities are essential and the outcome can conceivably be delivered with an alternative sequence of activities.
So, my suggestion is that you should plan only to the level of detail where you are confident that all activities are (a) essential and (b) non-commutative (relative to their neighbors).
Semantics are important!
I can almost feel your incredulity at this point! How can a plan at this high level of detail be sufficient for execution?
And your reaction is warranted … because it can’t be!
The high-level plan that I’m recommending is sufficient for planning – but not sufficient for execution. The thing is that planning must continue after the creation of the plan!
To clear the confusion we need two words for planning:
- Pre-plan planning (the planning phase, terminating with THE PLAN) – let’s call this planning
- Post-plan planning (the execution phase) – let’s call this fine-tuning
So, in summary, here’s the solution:
- Create a plan that contains only the degree of detail that enables you to be highly confident that reality will play-out as prescribed
- Accept that the level of detail in the plan is insufficient for execution
- Manage prioritization decisions on a day-to-day basis to ensure that reality tracks to the plan
In the post referenced above (quick-and-dirty approach), I talked about the importance of centralizing scheduling and building a management information system (MIS).
If you re-read that article it should be clear now that both of these initiatives are essential for the management of execution. It should also be clear that the MIS should be designed to enable management to fine-tune the prioritization of low-level tasks so as to ensure the compliance of the undertaking with the high-level plan.
(Execution management is outside the scope of this posting. To explore the subject further, read my brief overview of Critical Chain Project Management.)
Quite right, Jaycen!
It also seems like an excuse to avoid doing anything. When you spend all your time and energy working out strategy to the nth detail, day-to-day issues end up crushing the effort.
I've heard people complain about an inability to execute, but they demand a rediculous level of detail and even de-rail meetings in an attempt to examine every possible angle. Sometimes, you have to just say "good enough", and make adjustments as you go.
Wouldn't it lead to micromanaging?
With the pre-planning, it sounds like the executioner(s) knows exactly what sub-tasks are involved for each activity; which would be true if executioners are also planners. The detailed example which sounds too granular is more like a script where only two or three scenarios are considered for each scenario. Now I am wondering how to manage the project and people efficiently without micromanaging when planning day-to-day, or do we need to let the executioners decide which path they would take on daily basis?
Well, micro-management (or tampering) is a major concern but I think an overly-detail plan is *more* likely to contribue, because management will hold team members accountable to a plan that has zero liklihood of being executable in reality.
That's almost a definition of micro-management!
In most cases, team members know what's involved in activities. If you stop me and ask for directions someplace, I'll tell you to turn right at the lights, second-left at the fountain, etc. I won't tell you where to brake and when to indicate.
If team members don't understand activities, the additional detail should not be part of the plan proper. So, if you're using PM software, the plan would be the work-breakdown structure. Additional detail should live inside the activities (e.g. checklists).
Now, where management at the task-level is concerned, this is where the design of the execution system is critical. Management's approach should be to *leave well alone* until they see that the maintenance of the current trajectory will compromise the performance of the project (relative to the high-level plan).
Then, and only then, they should intervene, and do the *minimum necessary* to get the project back on track. (The Critical Chain approach to buffer management is a good example of such a system.)
Something I noticed in my work environment is the executioners know what to do, when to do, and how to do but hold back on starting a certain task because *they think* the task of deciding whether to take the task – whether to assign a task to themselves – is not something they own; it's what their managers own in the daily-basis planning.
I found this highly inefficient especially when they know everything to get the task done. I agree with you that the intervention by a manager should be done only when it is necessary but there are more managers/planners than executioners who know when to interrupt.
In most environments, team members should have limited degrees of freedom when it comes to the commencement of tasks because (a) management chokes the release of projects and (b) most tasks have upstream dependancies — meaning that team members need to wait for the predesessor task to be completed before they can start.
In such an environment, management's intervention should be limited to (a) determining when to release each project (ideally, as late as possble) and (b) monitoring the velocity of the project to ensure that it is likely to be completed on time.
If team members operate an an environment where there is a queue of tasks that they can select freely from, I would have thought it would make more sense for team leader to control the release of tasks to avoid the inflation of work-in-progress.