Critical Chain - Eliyahu M. Goldratt [61]
We go through the expected questions and answers. The answers move from "critical path" to "time" and then, when we once again clarify that the time is based on estimates and pressures, we finally arrive at: "Don't waste the time allotted for the critical path." Any waste here will delay the project.
Semantics? Maybe. But semantics are sometimes crucial.
Now I ask the big question. "How do we, currently, waste the time allotted for the critical path?"
Based on the last three hours, they now have a lot of answers. Too many answers. But they seem to go out of their way to avoid the obvious one. Nobody mentions the core problem, the fact that we pad each step with a lot of safety time.
Maybe it's because of their fear of letting go of their precious local safeties, maybe they just don't see it. I don't know. I only know that I have to spend quite a lot of time relating each answer back to what is written on the board. Pointing out, over and over again, that it won't help us to deal with symptoms, we must deal with the core problem. We must bite the bullet and deal with our tendency to pad each step with a lot of safety time.
Maybe it was so difficult because of the implied action: "So, you want us to reduce the time to one-third?"
"I don't want you to do a thing," I clarify. "I just point out the unavoidable conclusions stemming from what you said. Do you agree that we shouldn't protect each individual step with safety time?"
"Yes."
"Do you agree that each step has a minimum two hundred percent safety?"
After more beating around the bush, the answer is still, "Yes."
"One plus one is two."
I had to repeat it, in one form or another, at least five times. At last someone asks, "But are we going to put in some safety?"
"Of course," I say. "Murphy does exist. But we are going to put the safety where it's going to help us the most. We are going to put it so it will protect the constraint. What is our constraint?"
"The critical path."
"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.
They start to translate it into what it means for their project. The A226 has to be ready six months from now. There are many steps on the critical path that are not done yet. Their current estimates lead them to believe that they will be late by two months, which in their environment is verging on a crime. They already talked about saving time by compromising on some of the performance of the modem, but Mark hasn't allowed it yet.
"If we take the current estimates for the remaining steps," I help them, "it adds up to eight months. If we do what we just said, we can create a project buffer of more than five months!"
Nobody likes it. Not Mark, who booms that a five-month buffer is much too much. And not his people, who categorically state that anyone who thinks they can finish their individual tasks in one third of the time must be out of their mind.
For a while, it's a zoo.
Mark has to use his voice at full volume to quiet them down. "With these trimmed estimates," he tries to calm them down, "I understand that for each individual step, the chance of finishing is only fifty percent."
There is rapid response. "Fifty percent, ha!" "Less than ten percent." "Not a chance."
It's one thing to agree that theoretically there is more than two hundred percent safety. It's another thing to commit to a trimmed estimate. Inertia.
"I'm not going . . ." Mark's voice booms above everybody else. "I'm not going to put anyone to the wall if he or she doesn't finish on time.
All I want to see is that we are working on it as fast and as prudently as we can."
It helps. Especially when he repeats and repeats and clarifies what he means.
Some caution against creating such a buffer.