Critical Chain - Eliyahu M. Goldratt [65]
"No. We don't do it that way. A week before the expected time we just remind people that their work on the critical path is coming. Then three days ahead we give another reminder. And then again, one day before, when we know for sure that everything else is going to be ready. The important thing is that people know that when the time comes they must drop everything and work on the critical path."
"I haven't heard anybody complaining," Ruth says. "On the contrary, they appreciate the early warnings."
"This is very important," Fred emphasizes. "Without it I'm sure that most of the advances we have made would have been wasted. To show you how well we are doing, let me give you one number. Three weeks ago, when we started, the project buffer was nine weeks. Now it is still nine weeks."
"In spite of the fact," Mark adds, "that everyone thought that the times we left for each step were much too short."
"Thank you," I say. The class applauds.
As the three head back to their seats, Fred turns, "There is one thing I wanted to ask."
"Go ahead."
"I'm not happy with the way we measure the progress."
That stops Mark. "What's the problem?"
"I am monitoring just the critical path, and so far everything is fine. But I'm afraid that a problem might be brewing in a noncritical path, and by the time it reaches the stage that it delays the critical path, it will be too late."
"That's a problem." Mark is stuck in the aisle.
"Sit down," I say. "There is no problem. You are monitoring correctly."
I'm confident. In the last meeting we had with Johnny to discuss operational measurements we covered buffer management in detail. I'm convinced that what they are doing is okay.
"Fred," I say, "you are monitoring the project buffer, correct?"
"Yes."
"How?"
"It's very simple," Fred says. "If a step on the critical path is completed, for example, two days earlier than estimated, I enlarge the project buffer by two days. If it's late, I reduce the buffer. Actually I don't wait for a step to be completed. Every day the people who work on the critical path give me their estimates."
"Estimates of the percent of the work they finished?" "No, I'm not interested in that. They give me their estimate of how many days until they are going to pass the hot potato to the next step. I must say that sometimes it looks funny. For example, last week the report from day to day was four days to pass the potato; three days; six days, they ran into a problem and they panicked. Then, next morning, it's down to one day. By solving the problem, they found a good shortcut." "If you are afraid of a problem brewing in one of the noncritical paths, why don't you do the same thing there?" He looks puzzled.
"Don't we do it?" Ruth looks confused. "Mark, how do you determine if you have an emergency on a noncritical path? Don't you calculate the same for each of the feeding buffers?" "Come to think about it, basically we do. But not formally. Fred, can you monitor all the buffers, not just the project buffer?"
"No problem. I'll give you a daily report." Fred is very collaborative.
"How should they arrange such a report?" I ask the class. "According to importance," one person answers. "Define importance."
It doesn't take long for the class to create the priority list. Highest in importance are steps that reduce the project buffer, either because they are somewhat late and are on the critical path, or because although they are not on the critical path they are late to the extent that they have already swallowed the corresponding feeding buffer and then some.
Then they debate how to arrange the second category—the steps that are not yet affecting the project buffer but are consuming part of the corresponding feeding buffer. There are several suggestions.
Some claim that the only thing that makes sense is the accumulated delay, or in other words, the number of days already consumed from