Critical Chain - Eliyahu M. Goldratt [62]
"Not a chance," Mark is confident. "The project is well on its way. Top management is not going to mess with it now. We just have to deliver on, or before, the original promised date."
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 add their version to the diagrams on the board.
When all this is settled, Mark passes the baton back to me.
"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."
"Why?" Ruth asks.
"Without subordination," I answer, "we are unable to protect the constraint from losing time due to problems occurring elsewhere."
She agrees. The others look puzzled.
I explain. "So far you've dealt with the steps of the critical path itself. That will surely help. But tell me, hasn't it already happened in this project that you suffered a delay on the critical path because of a problem that occurred outside the critical path, in one of the many feeding paths?"
They laugh and start to bombard me with examples. I don't understand their jargon, but I let them speak. It's important that they realize that most problems that impact the critical path do not occur on the critical path itself. That's the only way they'll realize that subordination is not a nicety, it's a must.
When they somewhat run out of steam, I ask, "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."
"We don't talk in terms of inventory," I remind them. "We talk in terms of time. So what do we have to do?"
"We have to build a buffer of time."
"Where do we have to build these time buffers?" I go to the PERT chart hanging on the wall and put a ruler on the critical path. "What is the meaning of ‘before the bottleneck' in our environment?"
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.
"Where are we going to take the time from?"
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.'
In less than half-an-hour we have a new PERT chart. It's amazing how much the computer software available today simplifies clerical work. It's also amazing to what extent this sophisticated software doesn't help us solve the real problems.
They examine the result. The situation looks much better than one might expect. Only in two feeding paths have delays already swallowed the buffer that we just created.
"I told you that it wouldn't work," one skinny guy is quick to conclude.
"What do we do about it?" Mark asks me.
"Concentrate on bringing them back on track," I answer. "But I don't see any reason for alarm. In each of these two cases the delay is about two weeks. Don't forget, if you really can't get it back on track, you still have a project buffer of two months."
That's an angle they hadn't thought about yet. 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.'
They