Project planning in most organizations consists of identifying all of the tasks necessary to carry out a product development program, assembling them into a plan, estimating the time that each task will require, presenting the plan to management, revising the plan to reflect more aggressive targets requested by management, and then managing the project on a task by task basis to ensure completion.
So with such a well defined process in place, why did Planview’s 2010 survey find:
- 48% of product development leaders rated finishing new product projects late as one of their greatest risks
- 42% viewed their forecasted schedules as “mostly or highly inaccurate”
The problem starts with the estimates used for individual tasks. Even estimates for a task as simple as going to the Starbucks up the street for coffee can vary dramatically .If everything went perfectly, you might do it in 10-15 minutes. Others will factor in traffic, the possibility they might have to wait in line, the barrista might have to brew a new pot, etc. They might estimate as much as an hour. The average estimate, the one with a 50% probability is 30 minutes. The important thing to keep in mind is that estimates are not deterministic so each is possible depending on circumstances.
Of course, new product development is risky, and no one can predict exactly how long innovation will take. So team members, who know they will be judged on performance, have to juggle multiple priorities, and be asked for more aggressive estimates, give safe task estimates. The smart ones build in a buffer that allows them to meet estimates a very high percentage of the time – usually 95% of the time or more.
The problem isn’t the existence of that buffer, but the fact that it’s hidden and located at the task level. If every task is buffered, some will finish late, others will finish early, and the project should finish on time. Unfortunately, that doesn’t reflect the real world where most projects finish late. That contradiction happens for two reasons:
Student syndrome – It is human nature, especially when balancing multiple priorities, to delay starting a 3 day task until 3 days before the due date. That results in any unexpected events delaying the project since the buffer has been consumed by procrastination.
Parkinson’s Law – Or work expands to fill the time available. Team members hesitate to hand in work too early because they know they will be pushed to trim estimates next time or see no harm in polishing a workable solution to perfection. In either case, the buffer isn’t available to protect for unexpected variation.
The Critical Chain solution resolves these problems. After resource leveling and identifying the series of tasks with the longest duration (the critical chain), the PM builds the plan based on un-buffered (50% probability) estimates and then inserts a smaller aggregate project buffer after the tasks. The 50% estimates are built by first asking team members for their 90% completion estimate and then cutting them in half. Since early completions will offset late completions, central limit theorem statistics allow us to size the buffer at half of the length of the tasks on the critical chain. This means that the project plan duration will be 75% of the length of a traditional resource leveled plan and be made up of 67% critical chain tasks and 33% safety buffer.
But make no mistakes. Critical Chain is a change in management practice – not just a tool for managing projects. Some of those changes are:
- Managers don’t control task completion dates. Instead they encourage relay racer like handoffs where CC tasks are smoothly passed onto the next step with no delay. This requires informational resource buffers to ensure the next resource on the CC is ready for the pass.
- Tasks durations must be treated as estimates – not commitments. By definition, 50% will be late. 50% will also be early. This results in team members being judged on ability to execute rather than ability to game estimates.
- Managers can’t assign people to multiple tasks at the same time since multi-tasking wastes resources on task juggling and creates waiting time for others on the critical chain.
- Projects are executed not by micro-managing (or locally optimizing) tasks but by tracking the percentage of the buffer consumed. Management only intervenes if buffer is being consumed faster than the project is proceeding.
To some managers, these changes may feel like they are giving up control, but that control was only an illusion anyway. The old task estimates, while treated like determinant commitments, were never more than probabilities – and not high ones at that.
But more importantly, successful CC implementations cut time-to-market in half and deliver on-time completion rates as high as 95%. Now that’s the kind of control managers should be able to get behind.
