Critical Chain: A Business Novel (12 page)

Most of the class is already sitting down, but to my surprise, there is almost nothing on my desk. I'm aggravated. These people are supposed to be serious. I gave them a homework assignment, they argued to get more time, I gave them two more weeks... and now only one report is submitted?

Something is wrong. Before I get all over them, I'd better find out why.
"The subject for today," I say in a calm voice, "is the magnitude of the safety people put into every step of a project. You were supposed to interview people and find out how much safety they add. And then you were supposed to submit your findings. Today."
They look at each other. They look at their desks. They look out the window. Nobody looks at me.
"It was impossible to find anything," Ted snaps.
"How come?" I'm genuinely surprised.
"Because people don't like to talk about the safety they put in."
"Did you push?"

"You bet I did," he says bitterly. "That was my mistake. All it did was irritate some foremen." Without a smile he adds, "And believe me, those people you don't want to irritate."

"Anybody else have better luck?"
Nobody answers.
"Charlie, did you find out anything?"
Smiling, Charlie replies, "I didn't get any threats, if that's what you mean, but I didn't get any real answers, either. People don't remember, or don't want to remember. In any event, nobody admits to putting safety in their time estimates. When I mentioned safety of two hundred percent, they laughed in my face."

"Of course they would," I say. "You two went about it all wrong. What was your mistake?"
"If I knew, I wouldn't have made it." Ted doesn't take criticism well.
And he is right. When I gave the assignment, I should have been more specific.
"There is no point asking people how much safety they put in because people believe that they give realistic estimations," I explain. "The problem is in what they call realistic. Remember Mark's reaction before we explained the probability distribution? Remember his astonishment when he realized how big the difference is between the median and eighty percent point?"
"So how were we supposed to do it?" Ted is very snappy. Probably his questions to the foremen stirred up a hornet's nest, and he still stings.
"You should have asked people for their opinion about the chance of finishing a task in the time they estimated," I answer.
"That's all?"
"Yes. We can do the translation. We know that an evaluation of eighty percent chance means about two hundred percent safety. Sometimes more. Remember what we said about the shape of the probability distribution: the higher the uncertainty, the higher the resulting safety."
"If that's all you wanted," Charlie says, "then I did find something."
"Let's hear it."
"From my inquiries, one thing came out very clearly." And he makes the following declaration: "The time estimates are impacted, in a major way, by the last overrun the programmer had."
Everybody is laughing. They too are aware of this phenomenon.
Then Charlie continues. "I don't think that there is much point in asking computer programmers to evaluate their chance of finishing on time. Computer programmers will never admit ninety percent chance, not even eighty, because a programmer who finished on time has not yet been born. At the same time, let me tell you, there is nobody like an experienced programmer to pad himself with safety."
Not knowing much about programming, I ask, "Why?"
"It's obvious. Otherwise they wouldn't have the time to add all the bells and whistles that nobody needs. If you don't sit on a programmer, he will never finish, he always has another something he must add."
Thanks to Charlie, the class mood is cheerful again. Even Ted is less gloomy.
"I didn't ask the right questions," he says. "But from my experience I can tell you what the answer will be."
"Yes?"
"Every foreman will say that if everything is ready for him, and that's a big if, then he won't have much difficulty finishing his share on time. They don't talk in terms of probabilities, but they mean over ninety percent."
Now that everybody understands what they were supposed to do, more share their experiences. Their experiences are amusing, but not leading us anywhere.
Not entirely happy, I ask the class, "Does anyone have anything more than just general impressions?"
"Yes," says Mark. "We did force people to give their evaluations. We even prepared a questionnaire for that. It's in our report. As you can see there, except for one person who is known to be paranoid, the vast majority said they think that they have better than an eighty percent chance of finishing on time."
"There is a caveat to it," Ruth adds. "Almost everybody emphasized that their answer is dependent on others not delaying them, and not being loaded with too many other things at the same time."
"That's reasonable," I say. "So, where do you think we stand?"
And I answer my own question. "I think that we did confirm what we said last time. We expected people to give estimates that would give a good chance of finishing their step on time, well over a fifty percent chance. And that's what you found. At the same time, we predicted that people would not realize how much safety this over fifty percent means, and you verified that as well. That basically sums up your findings."
"That's not all," Fred calmly says. "Mark, Ruth and I found something else. We found that five plus five equals thirteen."
"What?"
"It's very common," Mark comments.
"It's very common that five plus five equals thirteen," I repeat. "What kind of a joke is that?"
"Whenever a step in a project is a collection of several tasks, each done by a different person," Ruth explains, "the boss of this project asks each person for their own estimates, adds them up and then adds his own safety factor on top."
"So, if one estimates his task to take five days," Fred continues, "and the following task of the same team is estimated to take another five days, the person in charge will give an estimation of thirteen days."
"I see."
"That's standard," Ted confirms.
"Sometimes," Brian interjects, "there are several management levels involved. Each level adds safety."
This phenomenon is news to me. Considering human nature, it makes sense, but it doesn't appear in the textbooks I have read. "Is this the case at your companies as well?" I ask the class.
Many confirm it.
"There is something else," Fred adds. "In our environment, top management is frequently not happy with the final estimation of when a project is expected to be finished. They want the results sooner. So in half the cases, when all the estimates are done, they demand the lead time of the project be cut by, say, twenty percent. This global cut is usually translated into everyone, across the board, having to cut their times by twenty percent. By now everybody is used to it, so they inflate the final estimates by twenty-five percent to start with."
Many nod. It must be happening not just at Fred's company, but at others as well.
"Any more good news?"
There isn't any. "Let's see where we stand," I say. "As far as we can tell, there are three different mechanisms by which safety is inserted into the time estimates of almost every step of a project.
"The first one is that the time estimates are based on a pessimistic experience, the end of the distribution curve.
"The second is that the larger the number of management levels involved, the higher the total estimation, because each level adds its own safety factor.
"And the third is that the estimators also protect their estimations from a global cut.
"When you add it all up, safety must be the majority of the estimated time for a project."
Then I ask, "Do you see something strange?"
Charlie is quick to pick it up. "If our estimations include so much safety, how come so many projects do not finish on time?"
"Let's take a specific project, so we can really examine this question," I say. "Is anybody willing to present a case where a project was very late?"
"The Denver airport."
"I mean a project you were involved with. One where you know what really went on."
Ted raises his hand.
Jokingly I say, "Ted, admitting that you had a late project is contrary to the image construction companies try to promote."
He laughs, "We are among friends here. And I have a real case that shows that sometimes projects will be late and you can't do anything about it.
"A year ago, we built a new mall. A big one. We were late by two whole months. We blamed it on last-minute changes, but the truth is that we were struck by particularly bad weather. Also, you can't imagine how many things we had to redo. There was nothing we could do."
"How much time, in total, was lost?"
"About two months. That's why we were late."
"Maybe," I say. "But tell me, what was the original estimate, from start to finish of the whole project?"
"Fourteen months, I think."
"Ted, don't run away from the dilemma we are facing. If most of the time estimates are actually safety, your safety was much more than two months. You shouldn't have been late."
Ted does not agree. "The fact is we were late. I think the reason is that we build safety against regular problems. Somebody doesn't show up, a window is damaged, a bad weather day. That type of thing. We don't plan on major catastrophes."
"I don't buy it," Brian argues with him. "If I understood the probability distribution correctly, we do guard against big surprises. Otherwise, why do we claim that we take two hundred percent safety?"
"Then I don't believe that we take so much safety. At least in our company we don't."
Brian doesn't let him get away with such a statement. "Ha! You are different. But if I'm not mistaken, you told us that in your company, people use estimates that put them in the range of ninety percent probability of finishing each step on time."
The debate between them might develop into something unmanageable. Especially with others trying to jump in. I decide to cut it short. "Well," I say, "is there something wrong in the logic that leads us to assume that so much safety exists? Or is there something fundamentally wrong in the way we are using that safety?"
There is nothing wrong in our logic, and they know it. Even Ted. But that doesn't help them to come up with an answer.
I turn to the board and draw two boxes. "Suppose these boxes represent two consecutive steps in a project. The estimated time for each step is ten days. Now suppose that the first step took twelve days. That means that the second step will start two days later than planned. That's obvious. But what will happen if the first step finishes in eight days?"
"Is it a trick question?" someone asks.
"If the first step finishes in eight days, when will the second step start?" I repeat my question.
A light is coming on in Ted's eyes. "It will start when it was originally planned to," he confidently states, and smiles.
"Why?"
"Because the team that finished ahead of time won't report it. You see, the way we are set up, there is no reward for finishing early, but there is, in fact, a big penalty." And he explains, "If you finish early you just invite pressure from management to cut the times. Your friends, in charge of other similar teams, will not like it, to say the least."
"So what will happen?"
"They will find ways to play with it. Don't worry, if they don't want you to find out that they finished, you won't."
As a second thought he adds, "Besides, even in the unlikely event that they do report it, it doesn't mean that the second step will immediately start. That team is probably busy doing something else, they might even be at another site."
"Another site, hmm . . ." Ted's explanation is tied too strongly to his specific environment, the construction industry. I'm afraid that my students won't see how general these phenomena are. That's why I ask, "Do we find this type of behavior in other industries?"
"Definitely," Charlie is firm. "Even though not exactly for the same reasons. A programmer is not afraid of his peer's reaction, but as I already mentioned, it will not cross his mind to say that he finished ahead of time. He or she will always find something in the program that can still be polished a little more."
"And if they report an early finish?" I encourage him to continue.
"Still not much will happen. The person who is supposed to do the next step knows that there is sufficient time, so what's the rush?"
"Let me see. What both of you are telling us is that it is likely that an early finish will not be reported. And even if it is, frequently the time gained will not be taken advantage of by the next step; it will just be wasted."
I write on the board: "A delay in one step is passed, in full, to the next step. An advance made in one step is usually wasted."
There were many other comments, but the conclusions held.
"You see what it means?" I try to drive home the message. "In sequential steps our deviations do not average out. Delays accumulate, while advances do not. This can explain how so much of our safety disappears."
I let them think about it a little, and then proceed. "What happens in the case of parallel steps?"
I draw four boxes all leading to one. "Suppose that in three of these steps we were early by five days. And in one step we were late by fifteen days. Statistically, if we average out all four boxes, we are on time."

The class bursts out laughing.
"In the case of parallel steps, and in any project there are many of them, the biggest delay is passed on to the next step. All other early finishes do not count at all."
"What you are telling us," Ruth is thinking hard, "is that most of the safety we put in doesn't help at all."
"Correct."
"If we could find a way to put the safety only where it's needed..."
Ted can't control his impatience. Mockingly he says, "If we had a crystal ball that would tell us, in advance, exactly where the problems would occur, then . . . Come on Ruth, let's be realistic."
Ruth blushes a little, but she is not going to be bullied. "Still, let's face what we see here. The only thing that counts is the performance of the project as a whole. At the end, it doesn't matter how many steps were not completed on time, as long as the project was delivered when promised. And what do we do? We try to protect the performance of each step. Most of this protection is wasted. So even though we put in that much safety, the project as a whole is exposed."
Ruth's words trigger a train of thought in my head. "We try to protect the performance of each step." That sounds to me like a cost world mentality. "The only thing that counts is the performance of the project as a whole." That sounds much more like the throughput world mentality. Is it possible that we are facing here the conflict that Johnny Fisher was talking about? Is it possible that bad performance is the result of a wrong assumption? What assumptions have we made?
The class is silent for a long while.
I'm supposed to do my thinking outside class, here I'm supposed to teach. I break the silence. "Anybody want to comment on what Ruth said?"
Fred raises his hand. "There is something that bothers me from before. For the past half hour we've been speaking as if we agreed that people put a lot of safety into each step. I'm not sure about it. I've checked some numbers, and they don't support that conclusion."
That's interesting, especially coming from Fred. "Share it with us," I say.
"In our company we keep records of when each step started and when it was completed. I used the data to compute the elapsed time of the steps, and I compared it to the original estimates. Do you know what I found?"
He waits a second or two, then tells us. "I found some steps, very few, for which the elapsed time was shorter. Now I understand that it might be a result of people's reluctance to report an early finish. It also solves another problem that I had, estimations that are too accurate. Now I understand why almost half the steps were reported finishing almost exactly on the nose.
"What bothers me is what I found for almost a third of the steps. For this large group I found that the elapsed time was about ten to twenty percent longer than the original estimate. If there is so much safety in the original time estimates of each step, how can we explain it?"
And he continues. "Everything that I've heard so far can, maybe, explain why the safety does not protect the completion time of the project. The safety is wasted in the connection between one step and another. But what I'm talking about here is that I haven't found the safety that is supposed to protect the performance of each step."
"That's important," I say. "It means that if we don't have a mistake in our logic, it must be that we are somehow wasting the safety, not just on the project level but on the step level as well. Anybody have an idea?"
After a long while, Tom raises his hand. "Maybe we just waste it?"
I'm eager to encourage more students to speak up, so softly I say. "So it seems. Can you give an example?"
"Our assignment for today."
I don't see the connection. But Charlie does. "Tom is absolutely right."
For those who didn't get it yet, and that includes me, he explains. "When we got the homework assignment we all claimed that two weeks was not enough time to do it. And we succeeded in getting a postponement. Now how many of us, after we screamed that we needed more time, went back and immediately started working on the assignment? I bet that no one did."
Tom nods his head.
"The students' syndrome," Brian says. "First fight for safety time. When you get it, you have enough time, so why hurry. When do you sit down to do it? At the last minute. That's human nature."
Fred jumps on the bandwagon. "Only once we start the work can we find out if there is a problem or not. If there is, we start to work frantically. But we have already wasted the safety, so now we are going to be late. Yes. This can explain why, in spite of all the safety, so many steps finish a little late."
"Very good, Tom," I say. "It seems that everybody agrees with you. Based on personal experience, me too."
"I hate to spoil the party," Mark says in his deep voice, "but I don't agree. What Tom says exists, but not always. And definitely not when we are under pressure."
Then he adds, "I went over the steps Fred checked. I can tell you that in many cases that he checked, people were working under pressure. For example, many of the steps that took longer than estimated were done in the digital processing department. That department has been under constant pressure for years. Believe me, they don't waste time."
I look at my watch. Only ten minute left. If I want to finish this topic I'll have to speed things up.
"Mark," I say, "this digital processing department. Are they involved in many projects?"
"All projects. That's our bottleneck. We can't afford to dedicate these people to one project at a time. And in each project, there are many steps that they must be involved in."
"So, if I understand you correctly," I say, "each person is multi-tasking."
"You understood correctly."
"In that environment, being under pressure means that many people are putting pressure on them to work on different things? I suspect that the digital processing people are in no position to really know which tasks are more urgent?"
"How can they," Mark agrees. "I think that their priority system is according to who shouts loudest. And every project has several people who know how to shout."
"So what do they do?"
"The best they can. Jumping from one project to the other, trying to satisfy everybody."
"Typical multi-tasking," I say. "Do you all realize what impact multi-tasking has on lead time?"
They apparently don't.
"Suppose that a person has three steps to do, A, B and C. These steps might belong to different projects or the same project, it doesn't matter. Each step takes ten straight working days. If our person works sequentially, the lead time of each step is ten days. Ten days after he starts B, for example, B is released for somebody else to continue the work. But our person is under pressure and he tries to satisfy everybody. As a result, he works on a step for only five days before he moves to another step. Suppose that the resulting sequence is A, B, C, A, B, C. What is the lead time of each one of the steps?"
I draw the diagrams, so it's easier for them to figure out the answer.