≡ Menu

Can letting go get innovation under control?

Get control of innovation

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”

Probability of on-time completionThe 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.

{ 3 comments… add one }
  • Bill March 23, 2011, 5:42 pm

    Mike, Excellent way to summarize very clearly how Critical Chain shortens the duration of the project.

    Regards, Bill

  • Brad Barbera March 23, 2011, 9:45 pm

    Mike,
    You are dead on, and provide an excellent, succinct summary of Critical Chain thinking. When I was first exposed to Critical Chain project management, it was one of those smack-myself-in-the-forehead-and-say-“duh” moments. The project management fallacies, particularly around multitasking as a critical skill, and the benefits of changing project management approach, were both blindingly clear. Yet implementing a change from “the way things have always been done” is at best extremely difficult, and more often virtually impossible. Why?

    You correctly offer that it has much to do with management changing behavior. However, I do not think it is necessarilly due to an unwillingness to give up control, although I have worked with and for a number of controlling-types that would fit that mold.
    I believe there is something deeper, the same something that keeps 90% of open-heart surgery patients from changing to a healthier lifestyle, even though they are explicitly told that they will die if they don’t.

    I am currently reading “Change or Die” by Alan Deutschman, which is a fascinating discussion around the psychology of change. For implementing change in an organization, it may be necessary to go through the relate-repeat-reframe cycle discussed in that book, and not rely on simply the facts and benefits to speak for themselves. When people can’t change when faced with imminent death, as all those heart surgery patients can attest, they certainly can’t be counted on to change when told that they should have more reliable project deliveries.

    Thanks for the excellent article!

  • Michael A. Dalton March 24, 2011, 10:22 am

    Thanks both Bill and Brad – Brad you mention Deutschman so you might also enjoy the short post http://www.guidedinnovation.com/si/2010/12/13/dying-for-change/

    Deutschman’s ideas are intriguing, but I find Kotter’s approach very practical starting with creating sense of urgency, then guiding coalition, communicating vision, and on as the most useful.

Leave a Comment