- "Critical Chain proponents claim that projects are shortened by an average of 25% and that the project throughput is significantly increased. By my understanding of the logic of project management both methods will have about the same Throughput." (I guess the author of the response means the critical path and the critical chain methods result in the same throughput.)
- "The author of the blog entry claims that many Critical Chain users are unwilling to report their success - since it represents a competitive advantage. How can the effectiveness of a method be proven if users are unwilling to report and describe their successes. Or is it simply so that Critical Chain des not have any success?"
Does Critical Chain Shorten Projects?
There are 2 ways to convince yourself of the likelihood that Critical Chain does actually cause projects to be significantly shorter than other methods.- Perform a thought experiment. Test the logic of Critical Chain in your mind. Based on what you know about single and multi- project environments build up the logic that either disproves or proves whether or not the Critical Chain method will be successful. If you choose this method you will have to build the cause and effect logic that leads to the correct conclusion. To ensure a correct conclusion every step in the cause and effect chain(s) must be checked using the categories of legitimate reservations. Not that difficult a task, but one that you must validate with colleagues, both those familiar with project management and others that are not.
- You can evaluate the simple Critical Chain solutions that are supposed to achieve the spectacular results claimed - they are risk free since the actual work does not change; just the organization of that work.
- Critical Chain cuts task times in half and places half of what was cut at the end as a project buffer. So the plan is 75% of what you started with - which proves nothing about project execution. The action places an aggregated project buffer at the end of the Critical Chain instead of spreading it over all the tasks (Side paths are handled in the same way but do NOT add to the project buffer.) The actual work we need to do is not reduced. What we have is a buffer at the end of the project plan that is to be used to give us early warning that trouble is brewing in the project - if buffer consumption is greater than the rate of project completion we are heading for trouble.
Why can we cut task times in half and the live with only half the buffer aggregated at the end?
The assumption Goldratt made was that we all include a significant amount of safety in every task - because every resource in a project wants to be seen as reliable. Since the time a task will take does not follow a normal (Gaussian) distribution - the distribution is skewed significantly to the right (statistics of repetitive actual projects show this well). The amount of safety for say 90% certainty of completing a task on time is very high - probably even more than the amount cut using Goldratt's rules. According to Goldratt's assumption we have plenty of safety, but we find ways to waste it. Putting the buffer at the end puts that safety under the control of the project manager so that any gains made in one task can help another in trouble. (Delays are still passed on, but task time gains are now also passed on - in very many of current and historical cases you know about most tasks were finished on time - but rarely early (more than half should be early). If tasks are rarely delivered early, then we must be wasting time by delivering on time instead of when we actually finished our task … early. (If we make task time efforts that are relatively certain to finish on time (before implementing Critical Chain), then it follows that more than 50% of the time a task should finish early. The fact the many tasks do not helps prove that time allotted to tasks is often wasted.
Try it … not much can go wrong and your information about the project is improved because of monitoring the buffer. Think about the risk is zero … at worst the project will take the same time as before. - When Critical Chain is introduced in an environment one of the first actions is to freeze at least 25% of all projects - stop all work on these projects. The impact of this action is to seemingly delay some projects in favour of others - so a good prioritization is essential. The further impact will be that resources will focus their efforts better - they will no longer be pushed to switch tasks as often. Multi-tasking will reduce significantly and the flow of projects will increase. This is not so easy to prove, but professor John D. Little (of MIT) did just that. His proof known as Little's Law. You can find his proof on the internet … but for most of us understanding the math it is not easy.
Another way to show the impact of freezing 25% or more projects is to use simulations. There are several that could be used including the bead simulation, the confetti factory and the columns of numbers. At least some of these simulations are explained somewhere on the web. Simulations are a simplification of reality, nevertheless they may convince you enough to at least try the freeze tactic.
What is the risk with freeze? Customers whose projects have been frozen for a time may complain initially. However, after doing the simulations you may well realize that even if a client must wait now, he will still get his project earlier than otherwise. Projects will complete much sooner (those not frozen) and the frozen ones have an excellent chance of finishing earlier than they otherwise would. Time lost due to multi-tasking is recuperated and ensures even the frozen projects complete earlier than they otherwise would. Risk is low, but you must explain to clients what you are doing and why!
(As projects complete, you can defrost a corresponding amount. Workload on resources should remain about constant … or be lowered further if multitasking is still very high.)
- Critical Chain cuts task times in half and places half of what was cut at the end as a project buffer. So the plan is 75% of what you started with - which proves nothing about project execution. The action places an aggregated project buffer at the end of the Critical Chain instead of spreading it over all the tasks (Side paths are handled in the same way but do NOT add to the project buffer.) The actual work we need to do is not reduced. What we have is a buffer at the end of the project plan that is to be used to give us early warning that trouble is brewing in the project - if buffer consumption is greater than the rate of project completion we are heading for trouble.
- Get references from successful implementations. I am certain you can find these in several place - Critical Chain software suppliers, Critical Chain consultants, Academia and the TOCICO. However, every project environment will be different from yours so even when you find the success stories you will still need to check the logic, check your paradigms and in the end check out the methodology on real projects.
When we were young … Baie Comeau, Quebec, 1953.
Technorati Tags: 6-Sigma, Continual Improvement, Critical Chain, Execution Management, Focus, Goldratt, Little's Law, Management, Multi Tasking, Project, Project Execution, Project Management, Project Manager, Project Plan, Risk Management, Strategy and Tactics, Theory of Constraints, TOC
No comments:
Post a Comment