This website covers knowledge management, personal effectiveness, theory of constraints, amongst other topics. Opinions expressed here are strictly those of the owner, Jack Vinson, and those of the commenters.

PF2009: Break the vicious cycle

The Project Flow 2009 conference started with a pair of workshops on implementing Critical Chain Project Management, one on the fundamentals and one on advanced concepts.  I picked the fundamentals session, which was primarily a workshop introducing Critical Chain Project Management as Realization does it.  Much of the material was very familiar, but it was interesting to hear their take on the familiar topics of the problems of typical project management, the direction of a solution and how to begin implementation.

The session used three different simulations (games) to demonstrate common the negative effects of common project management practices and new rules that should be put in place to supplant the old practices.  The bead game is familiar to most TOC consultants for demonstrating multi-tasking.  They also used a variation on the dice game to show the effect of uncertainty on integration points.  And then they used another bead game to demonstrate the impact of forecasting on resource decisions.


All of this simulation and the surrounding discussion was boiled down into an interesting drawing that highlighted the vicious cycle of standard project management practices.  Here's my attempt at the drawing.

Read from the inside out, it might go something like this: all projects are subject to uncertainty and dependencies, so there are bound to be delays at integration points and elsewhere within the project.  Loop 1: To handle delays, people start work as soon as possible (ASAP) in order to finish sooner.  This generates high work-in-process (WIP), which overloads the constraint, which causes further delays AND leaves non-constraint resources idle.  Loop 2: So, we add more work to the system to keep those resources busy, which adds WIP, which overloads the constraint even more.  Vicious cycle.  Loop 3: On top of that, organizations try to enforce project due dates by holding people to their time estimates, which has the natural effect of people providing their absolute worst-case time estimates: there is all sorts of hidden capacity in the system.  And yet, people still deliver on time or late because they have no incentive to deliver early (they will be tagged as sandbaggers and their next estimates will be cut), so Parkinson's Law prevails and more delays build up.  Loop 4: Finally, with all these delays, people are constantly being asked to shuffle between projects with no clear sense of priority, so they hide more capacity in their duration estimates, leading to more Parkinson and more delays.

Those lower three boxes are all the old rules: start soon to finish soon, use local rules to force success, no priority mechanism.  They all lead to the exact wrong outcomes: projects that never finish on time.  Organizations need to stop doing this and replace these assumptions with something new.  Realization talks about these as three rules of project management:

  1. Pipeline work based on the capacity of the constraint (cut out excess work in the system; stop adding work to the system to make people appear busy)
  2. Use buffers to protect the execution of the project (stop holding people to individual task performance; encourage as-fast-as-possible task execution)
  3. Use buffer management to set priorities across the whole portfolio of projects

Lencioni is a fun speaker

State the problem, not the solution