Critical-Chain-Project-Management, CCPM, is the most successful and widely known application of TOC. The most striking feature of CCPM is the handling of uncertainty, and the second most striking feature is the understanding of the impact of performance measurements on the human behavior and how it affects the performance.
I’ve put handling of uncertainty first, because adding a visual project buffer time at the end of the project is a bold statement that we do not really know the exact date when the project would finish. It is a clearer buffer than the DBR buffer, which seems like a regular lead-time attached to a chain of operations. This concept of the project-buffer is a significant contribution to handling of “common and expected uncertainty”.
The famous Goldratt saying “Tell me how you measure me and I’ll tell you how I’ll behave” was coined a decade before CCPM. The realistic negative impact of performance measurements on the behavior of humans is clearly seen in the shop floor and it is even more relevant for projects, where people are the key resources. The devastating use of multi-tasking is also derived from performance measurements that judge every project manager in isolation from all other open projects and by that force him to fight for “his project.”
While CCPM is a breakthrough of huge value, one should always ask:
What are the boundaries of the given methodology?
In other words, when the use of CCPM is beneficial and when certain changes have to be introduced?
It all comes to checking the assumptions behind the methodology and when they are not valid.
Just to illustrate the point let’s think about a program to find a cure for cancer. At the beginning of such a research is it possible to give it a due-date? Is it possible to build the network of tasks for the whole project? Do we have any idea how long it would take? Is there any role for a project buffer when you do not have a due-date to start with?
Here is my list of basic assumptions behind CCPM, which might be sometimes invalid in certain situations:
- We have a good enough idea how to perform the project from start to finish.
- In particular, we have a good idea, from the start of the project, what features have to be developed.
- We do not have conditional points in the project that could dramatically change the downstream operations or go backwards to an earlier task.
- Completing the project before or at the due-date is of utmost importance.
- Finishing on-time is nicely correlated to meeting the specifications and budget.
- The control on the progress and its timing issues are at our hands.
- We plan to work continuously on the critical chain. Without that the definition of the critical chain as what determines the duration of the project is meaningless.
What happens when one or more of the basic assumptions are not valid?
Let’s view two examples:
Suppose the client has to confirm certain stages in the project, and the client takes his own time to confirm. Two assumptions are not valid: the fourth and the firth. The fourth is invalid because we do not have the means to force the client to adhere to our timetable. The fifth is invalid as the whole project is in hold during the client’s check. One might include the client’s task in the planning and assume a certain 50% time for that task. The point is – when the client delays the signal to go ahead how can the project people keep the due-date?
My recommendation for such a case is to cut the overall project into subprojects. The project team controls the progress until the client gets the output for confirmation and that is the completion of project one. Once the client confirms to go ahead, even with new requirements, the second project starts.
Another problematic project is one where the due-date is mandatory, so no delay is possible. In such a case the content of the “complete project” might be much less than the original plan, or the costs might go up sharply, which means the third assumption is invalid. The time buffer does not protect all the truly relevant variables. The planning of such a project has to make clear distinction between “must-have” and “nice-to-have” features. I can see a direction of solution with a buffer-of-nice-to-have-features on top of the project-buffer protecting the mandatory due-date.
A general comment: I find CCPM as the least holistic methodology in TOC. It is target to solve a problem that is quite common, but not necessarily the key problem of the organization. I’m troubled by solving an undesired-effect (UDE) without seeing the overall picture. You can improve the management of projects and the organization would not reach more of the goal.
As a concluding anecdote: I met a high executive is a huge international conglomerate. When I mentioned the nice CCPM implementation done in Israel, the executive commented: “They finished early the WRONG project!”
Shouldn’t TOC be involved not just in the planning and execution of the projects, but also making sure they are the RIGHT projects with the right choice of content and specifications?
Can we do it without being involved with the Strategy of the organization?