Comments on _Critical Chain_, ch 16

Chapter 16

“I fooled myself long enough on answers that look good but are meaningless. What's the meaning of "don't waste the critical path?"

“Don't waste what?" I ask.

The safety? So like if a step finishes early, the person responsible for alerting the rest of the system should immediately and honesty claim that he's finished instead of the standard procedure of wasting that safety cushion. This allows the next step to get started earlier.

“So we have to protect the completion date of the critical path? Correct?"

"Yes."

We put all the safety at the end of the critical path. Stripping the time estimates of each step frees up sufficient time to create a 'project buffer.' " I draw two pictures to clarify what I just said. The original critical path and the critical path with the project buffer. That helps.

At last they settle on the following. The time allotted for each step will only be cut by one-half (Mark squeezes from them some lip service that they will try to beat these times). On the other end, the project buffer will not be equal to what they trimmed. It will be set to only half of it. Mark is adamant that two months is more than enough. I suspect that he insisted on it in order to put the project back on the promised date.

I see a parallel to a problem I ran into early in my business life. The problem is related to a phone system with multiple phone lines handling incoming calls such that the number of paying-customers that could call into the phone system is much larger than the number of people that would call into the phone system at any given moment. And part of the problem is that we don't want any calls to get a busy signal. I recall looking up a book in the library that solves this math problem (this was the most fun part of it!). I applied the formula (I don't recall it) and it worked well. The parallel I see to the book's concept is this:

• the old way of thinking about projects is that we should account for stuff messing up at each step, and add up those "deltas", and the resulting sum is the safety we want for the whole project. This reasoning treats things as if every single step will finish late, which is not true.
• the new way of thinking about projects is that we should account for the fact that some steps will finish on time or early and some steps won't. and we should think of like the average number of steps that might run long, and use those numbers to create the project safety. 
• the parallel to the phone system idea is this: we don't assume that all paying-customers will call into the phone system at the same time. instead we recognize that only some of the paying-customers will call in at the same time. and that amount can be calculated such that we guarantee say a 99% chance of no customer getting a busy signal. 

“Exploit the constraint," I start. "Don't lose any time on the critical path. We really can't do a good job of exploiting the constraint until we do the next step, until we subordinate everything else to it."

Ok I think I get it now. I answered wrong above. I said "The safety?" I think the answer is: don't waste the capacity at the bottleneck. If you can do that, then you've maximized the throughput of the whole system.

“Without subordination," I answer, "we are unable to protect the constraint from losing time due to problems occurring elsewhere."

... "Do you agree that we must do something about it? That somehow we must protect the constraint from problems occurring at the nonconstraints?"

They don't have any problem agreeing. Their problem is figuring out how to do it.

"What is done in production?" I ask. "How do they protect the bottleneck from problems occurring at the nonbottlenecks?”

“They build a buffer of inventory before the bottleneck."

The parallel to projects is this:

It doesn't take them long to conclude that we must insert a time buffer at the points where a feeding path merges with the critical path.

By now they have the formula. For each feeding path they decide to cut the original time estimates of the steps in half and use half of the trimmed lead time as a 'feeding buffer.'

... The 'feeding buffer' protects the critical path from delays occurring in the corresponding noncritical paths. But when the problem causes a delay bigger than the feeding buffer, the project completion date is still protected by the 'project buffer.'