Critical Chain Project Management vs. Critical Path

Learn the differences between Critical Chain Project Management and Critical Path.
Try our Award-Winning PM Software for free: www.projectmanager.com/?...
Learn how and why the ground-breaking critical chain project management methodology left critical path management in its wake!
Devin Deen presents the history of critical chain project management and its advantages over the long standing critical path methodology.
He explains how this style of project management came out around 1996-1997 when Eliyahu Goldratt published his book, Critical Chain Method.
Want to learn how to plan, execute and monitor a project using the critical chain management approach?.
Discover the benefits of incorporating the critical chain management methodology into your projects by watching this info-packed video now!
Subscribe to our KZbin Channel here: / projectmanagervideos
Want some more great Project Management Tips? Go here: • How to Manage Your Cus...

[@classanddignity]

You not only taught what it does, but you explained it's purpose and the differences to the other critical path method, which gave the ultimate clarity. Bravissimo!

[@nps115]

After a couple of iterations team adjusted by providing a 2x longer scheduling estimates :)

[@shkaushal]

I watched many presentations on CCPM however this is by far best in term of clarity and content.

[@anthonyowolabi]

I agree Shweta!

[@ProjectManager]

That's amazing to hear, Shweta! Thanks so much!

[@giantcat4354]

That's a really useful explanation, thank you. You hit all the main points concisely and clearly.

[@iliakherrera7416]

Excellent video, help me a lot on a assigment!!!

[@ashleywolf5522]

Nicely explained. Thank you

[@BadarSyed]

Excellent, simple and to the point explanation

[@holyonfire]

Thank you for this! It was very helpful.

[@jimhodgson5851]

Thanks for the video - very helpful. Can I just query the way in which 'crash the schedule' was used here - as in PMP we are taught that this means adding more resources to compress the schedule, however in this example 'crashed schedule' meant something else?

[@tootrue6529]

Excellent presentation. I now have a good understanding of the CCPM concept and its use. Thank you so much!

[@ProjectManager]

Thanks for watching!

[@xingchunmeng]

Thanks for a Clear and straightforward session!

[@ProjectManager]

Thanks for watching!

[@saianookumar]

Excellent explanation. Thanks a lot!

[@sarahmawell9876]

Thank you for the overview on CCPM.. very good example... well done ..

[@MrEngrfarhansiddiqui]

Thank you Brother

[@massaro231190]

Very helpful. thank you.

[@RaghuKasturi]

nice video! thank you!

[@rachelfernandes2545]

This is explained so well! Got a presentation regarding this topic and I'm so glad it has cleared my conepts.

[@ProjectManager]

so glad to hear it was of use!

[@vdsingh2learn]

Thanks, nice explanation ..

[@EmmanuelHemmings]

I worked with a Senior PM who did CCPM, except he neglected to actually promote the buffer date and instead pushed for the 50% reduced date.... you guess how long his dev team stuck around.

[@tracya5194]

So helpful🙏

[@Paki14W]

Thank you so much

[@rizihsan]

Should the original timeline and buffer be kept a secret from the project team and only used for upwards communication?

[@jaybakst121]

No! If anything, it is more important that it be thoroughly communicated with the project team. One of the difficulties in making introductory videos on Critical Chain (and this is a very good one) is that it is easier to explain that we cut task estimates than it is to explain why we cut task estimates. One big part of this is that estimates are just that, estimates! When I worked in 'traditional' PM, If I gave an estimate of 40 hours to complete a task, I expected that I would finish within the 40 hours. I knew that if I were late, then the next task would start and probably finish late. A quick cost benefit analysis told me that it was better to finish early than late. No one ever gave me kudos for finishing early and I received several 'what happened' when I was late. Experience has shown that people give an estimate that they can hit about 85% of the time.This is not being coy or unethical, it was my realistic estimate of when I was very confident that I could finish. Experience has also shown that the variability in these estimates effectively doubles the time to complete. Part of this is the CYA above and part is due to multi-tasking with my other project responsibilities. What never seems to come across in these videos is that after an organization has used CCPM for a while, and people understand that they are to provide 50% vs. 85% estimates, and they do not get yelled at when finish an individual task late, then they start to give aggressive dates to begin with and the buffer is added to their estimate (usually at a 50% add-on). This effectively is the same thing as described in the video with the 'cut 50%' part removed. Getting back to your question, for this to evolve successfully, the project team needs to understand the culture change required for CCPM.

[@shivanisorakhe4589]

very helpful video it is!! Thanks

[@ProjectManager]

So glad it could help!

[@davidaustin6962]

Robotically cutting their expected completion time by 50% is a great way to loose your best employees. Instead you should explain to them the urgency, ask them for a best case and worst case, and then expect from them the best case, but your buffer is added by (worstcase - bestcase)/2 for each task. Everything else he says is good. Shareholders have a expected delivery date of bestcase plus percentage buffer or buffer left whichever is less (if you are halfway through and buffer is gone then you need to crash or fast-track to get back the lost buffer). Also, you should always refer to your used or remaining buffer status in terms of percent, not hours.

[@harineemosur6530]

David Austin Absolutely right.This is a common trend in Fixed bid projects where it can got 40-60, burn out the resource to achieve excess profit.

[@sariuitto]

Yeah I was also wondering about that, how can you just cut 50% off. That will have the employees just add extra days in their estimates in the future to get the time they need, since the trust is gone. The problem is here that there is no urgency, it is a made up one. And that would happen in each of the projects that they do, not just one. That will backfire sooner or later. I do think that this (worstcase-bestcase)/2 is a good middle ground to solve this as I think there should be some sort of a buffer.

[@AaronG303]

I totally agree with David A's comment "cutting 50% is a great way to lose your best employees". I can attest to this experience. Disclosure and communication is one of the greatest asset for an organization (Organizational Behaviors 101). Its disturbing that on one hand students are taught the best method to piece together WBS, amount of effort etc is by drawing on those who actually execute the work. In my view, dependent on the level of trust, honesty and professionalism, those asked to provide the estimates would take it as a great professional insult that PM would naturally assume their estimates are inaccurate (cutting their estimates by 50%)! This is why there exists a great divide between execution and project management! I have experienced this time and time again, builds discord, distrust of management and permeates through-out the organization, obliterates motivation, breeds contempt. No wonder thier are statistics supporting significant numbers relating disengagement!! This theory in reality (particularly) is highly questionable as I have witnessed first hand.

[@AaronG303]

....also, for a PM to focus on the burn rate of the "buffer" only serves to favor the outcome for the Client and the PM's (his organizations) reputation. Those on the Project Team are surely "team players" however, clearly it is recognized some teams within the project teams can be clearly unproductive/inefficient (at time struggle to meet baseline) and take advantage of those teams and individuals who consistently perform! Once again this is poisonous to an organization if this is not recognized by the responsible PM or addressed by responsible Functional Managers. Recognizing performance and attending to under performance is just as important as fixation with the burn rate of the buffer.

[@xzotzvvs6492]

Perfect

[@MaherRamdan]

is taking time from the schedule called crashing? as far as i know crashing is adding more resources and overtime to cut time

[@ashleywolf5522]

I believe he meant collapsing but crashing can be used interchangeably. He isn't referring to crashing as a form of schedule compression

[@Simply_the_Best_One]

Crashing is using additional resources for additional money, you can't crash if you're overbudget. Simple is that. You can also fast-track (lead) activities, I.e. working in parallel several activities, but sometimes it might harm the quality of the project.

[@MrTchann44]

well explained

[@Cold-er]

When I typed in "Chain Thinking" I wanted to see if there was anyone else that did it. What I mean by chain thinking is sometimes I start thinking about something then end up thinking about something totally different. For example, I think about Basketball then end up thinking about Chinese board games. I can't really explain it just happens.

[@OutOfTheBoxThinker]

If you want to learn more about the phenonemon you're describing and how to utilize it in a creative process, you might want to look into the concept of "mind mapping" ( en.wikipedia.org/wiki/Mind_map )

[@JonKGKeys]

This was FANTASTIC!! You are a great communicator and I would think this method suits better than Critical path as that is more rigid and introduces possibilities for less or more effort from the project team. Love it!

[@ProjectManager]

Thanks so much for watching! Glad you enjoyed!

[@miedono]

Thanks. The white board is a very effective tool for explaining the CC concepts.

[@batirk1899]

It won’t work. Consider this, the Resource A (R.A) estimates time to complete Work Package 1 (WP.1) in T time. The PM compresses schedule for WP.1 to T/2 time (plus T/2 buffer). Now, R.A will finish late and use buffer time, or finish in T/2 time and submit incomplete work with hidden errors. R.A knows he/she is now underperforming and feels bad about it. For the next Work Package B, R.A will submit time estimate of 2T. The PM will half it to T and allocate a buffer T. This will allow R.A to comfortably complete WP.2 on time. It will also wise up other resources to use inflated numbers in their estimates. Great, isn’t it? Another problem is, what happens if there is dependency, if R.A has to hand in completed WP.1 to Resource B. As I mentioned above, Resource B will either receive incomplete package on time, or will have to delay working on WP.1 because R.A is late and is using extra time from buffer. Also, this completely goes against principles of agile (self-organizing teams, and what not).

[@vutsxx]

Yeah, CCPM is totally different than Agile. I dont like it, it can be put to work, but its just a mess system that ensure that the PM is blind to problems until the fever chart is on red.

[@JohnMorleyJT]

I can't see how your software using TOC's CCPM methodology??? It's just only Gantt stuff???

[@ProjectManager]

If you have a technical question, please send it to [e-mail]. Thanks.

[@GabriellaMarpaung]

his eyes were blue and brown

[@ashleywolf5522]

That's so so random lol