Critical Chain: A Business Novel (3 page)

I look around the class. There are many more students than I expected, almost thirty, but it doesn't matter; I've taught classes four times as large and I'm well prepared. I slaved all summer, reading everything I could lay my hands on. I interviewed over a dozen people with a lot of experience in project management, much more experience than these young managers have. I think I can handle anything they throw at me. Or at least I can swing at it.

They all take their seats. It's quiet. I'd better start. As usual, the first row is almost empty. The last person to become quiet is sitting in the back row. Good. He is a large man, about my age. He can stand some abuse. "What's your name?" I ask, pointing at him.
I picked right because he doesn't try to pretend I am pointing at somebody else. "Mark Kowalski," he replies in a booming voice.
"Why have you chosen this course?" I ask bluntly. One thing is for sure, I have everybody's attention. They are not accustomed to my teaching style. A professor is supposed to lecture, not interview. Half are looking at me, half are looking at him. Some are smiling.
"I'm a project leader," he answers.
When I don't reply, he continues. "I work in a company that produces modems. I'm in charge of one of the development teams."

I continue to stare at him, but he doesn't add anything more. The situation becomes really uncomfortable when I finally say, "You haven't answered my question."

I look around. Nobody meets my eye. Nobody wants to be the next victim. I return to Mark. "Do you have any problems managing your project?"

"Not really," he answers.
"So why have you chosen this project management course?" He starts to grin. "I guess I do have some problems," he admits.
"Can you elaborate?"
"Well, I didn't start this project, and the person before me made some wild promises that, I'm afraid, are unrealistic." "Like?" I press him.
"Like the expected performance of our new modem and the time it will take to deliver it."
Some other students are grinning with empathy. "And you expect," I look him straight in the eye, "that what you are going to learn in this course will enable you to perform some miracles?"
"I wish," he uncomfortably admits.
"So, why have you chosen this course?" I repeat my question.
"Look," he says. "I am a project manager. I am working toward my MBA. This is a project management course, isn't it?"
"Ah! So you chose the course because its title resembles your job title?"
He doesn't answer. What can he say? It's time to let him off the hook.
"Can anybody tell me why he or she chose this course?" I ask the class.
Nobody answers. Maybe I was too intimidating.
"When I was a student," I tell them, "I chose courses that were given by professors who were known to be light on homework. I'm afraid that I'm not one of them."
It helps a little, but not much.
"Listen," I continue. "We all know that you are here to get the degree. To get a piece of paper that will help you climb the organizational ladder. But I hope that you want something more than that. That you want to get know-how that can really help you do your job."
Heads nod around the room.
"You have to choose between two alternatives. One is that I'll stand here, on the podium, and lecture for the entire semester. I can flabbergast you with optimization techniques and take you through every complicated heuristic algorithm. It will be tough to understand, even tougher to use and, I guarantee you, won't help you one iota.
"Or, we can put our heads together and, drawing from your experience and the know-how that exists in books and articles, we can try to figure out how to manage projects better. Which do you choose?"
Not much of a choice is it?
At the back, Mark raises his hand. "So what should I expect from this course?"
Good question. Good man. "Mark, you told us you have problems with your project. I think that this course should give you better ability to deal with those problems."
"Fine with me," he says.
Turning to the class, I start. "Assume that I have good knowledge of the know-how as it is written in books and articles. What we have to find out now is the level of experience you have with projects. So, besides Mark, who else is deeply involved in projects?"
A slim redheaded young man in the third row raises his hand. "My name is Ted and I work in a construction company. Everything we do is a project."
"How long have you been working there?" I ask. "Six years."
"Excellent," I say. "Anybody else?"
To my surprise, nobody else raises a hand. I'm saved by a blond woman, sitting by herself in the front row. Hesitantly, she asks, "Can you define what you mean by a project?"
I swiftly scan in my mind four definitions I read in textbooks. Somehow they all seem too pompous to me. How can one relate to a definition like "A set of activities aimed to achieve a specific objective and have a clear start, middle and end." If I want to bring this course down to earth and relate it to their situations, I'd better not quote any of these oversimplified or complicated definitions. Rather than defining, I choose to describe. I say, "In your work, have you come across a complex initiative that in order to manage it, people have to draw the picture of what they are supposed to do?"
"I don't understand," she replies.
"Some block diagram of the various steps that must be accomplished in order to achieve the objective, showing which steps should be done in sequence and which in parallel. Or alternatively, some time charts, which display when each step should start and when it will end. If you came across a situation where people use such charts, you came across a project."
"I see," she says.
"Are you involved in projects?" I ask her.
"According to your definition, I am," she answers. "I am a brand manager, and we spend a lot of time building such charts before we launch a new product."
"And your name is?"
"Ruth Emerson."
Her example probably helps the others because it quickly becomes apparent that everybody is involved with some type of project. Some of them are working in an almost pure project environment, like Mark in design engineering, redheaded Ted in construction or Charlie, in the Hawaiian shirt, who told us he is in software programming.
Others are interacting with, or even conducting projects. Like Ruth in marketing; Fred, an accountant who also audited some projects, and Brian, who is involved in the expansion of his plant. What is very good is that between them they cover a broad spectrum of project environments. But that is also dangerous. If I do not succeed in steering them to concentrate on what is common to all their projects, we are bound to flounder all over the map.
That is why I don't inquire about their specific projects. Rather, I ask, "The channel tunnel, what do you know about it?"
Ted, my redheaded student, is the first to comment. "Isn't it the train tunnel between England and France?" When I confirm, he continues, "I read that they have huge budget overruns."
"In the billions," Fred, our accountant, adds.
"It became such a big problem," Ted is on a roll, "that at one point they contemplated stripping some of the ambitious original design."
To encourage more conversation I ask the class, "What else?"
Ruth, in the front row, picks up the ball. "I saw the grand opening of those tunnels on TV. The queen herself christened it. The opening was a few months late and they were still unable to run trains."
"A classic example," I summarize, "of a project that didn't finish on time or on budget."
I give them another famous example; the oil rig platforms in the North Sea. These oil rigs are enormous plants built three hundred meters above the floor of one of the most stormy oceans in the world. From each platform they drill not one, but many, oil wells. They drill at angles of up to 57 degrees to hit oil three kilometers below the surface. Then they have to separate the oil from the sand before pumping it through pipes to shore. No wonder the investment in each one of those huge projects is close to four billion dollars. One might think that after putting up several of these big babies they would have their act together. It's not the case. It's been said that they plan a project meticulously, then multiply by four and pray.
"Well," I tell the class, "prayers are clearly insufficient. In the early nineties the top gun of StatOil, the Norwegian oil company, was forced to resign due to mammoth overruns on one of these projects.
"You see, Mark," I jokingly add, "you are not the only one whose project does not meet its due date. At least in your case, you are not going to run over budget."
"Yes, I will," he calls out, and then explains. "The project manager before me, the one who so carelessly spread promises, is now my boss. He is determined to save face, so he has forced me to take on more people and use expensive subcontractors. We definitely are going to be over budget, the only question is by how much."
"There is another question. Who is going to be blamed for it?" I add.
"Not him, I'm afraid. Knowing my boss, I'm definitely the one going to be blamed."
"So what are you going to do?" Charlie, our software manager, is sincerely concerned.
"Nothing," Mark brushes it off. "In engineering, every project is overrun and overdue. Besides, there is another tack. When push comes to shove, we will reduce the targeted specifications of the project."
To stress this last but important point, I ask, "Do you do it frequently?"
"More than we like to admit," he answers.
"Has anybody else come across a project that due to its overruns and its being overdue, compromised on its original specifications?"
"I don't know if you can call it compromising the original specifications," Brian comments, "but when they finished our new offices, only four months after they were due, we moved in only to find out we didn't have desks, and the air conditioning was not yet functioning."
Before I have a chance to comment, Charlie confidently states, "Everybody knows that projects don't finish on time or on budget, and if they do it means they had to compromise on content. Especially in systems programming or product design."
"That is not necessarily the case," I say. "Occasionally, there are design engineering projects that finish much ahead of time, significantly under budget and deliver more than was promised."
Those with any experience working in or with design engineers, which means about half the class, find it hard to believe such a claim.
"In the early fifties," I continue, "the Russians announced that they, too, had an atom bomb. That came as a total surprise. It became apparent to the U.S. that it had to find a way to monitor what the Russians were doing in their vast Asian territories."
"That's how the space satellite program started," one of the students guesses.
"I'm afraid that at that time satellites were to be found only in science fiction books," I have to disappoint him. "But, jet airplane technology was rapidly developing. One reputable engineer, Clarence "Kelly" L. Johnson, suggested building a plane that could fly at altitudes above the ceiling reached by fighter planes. Do you know how much time it takes to develop a new airplane? I mean from concept to an operational weapons system?"
"Over ten years," Brian says confidently. "I served in the Air Force."
"That's doesn't make you an expert, yet," Ted picks on him.
"Usually, it does take more than ten years," I confirm Brian's answer. "The U-2 was developed in a surprisingly short time. Eight months after start, this airplane was already flying over Russia, taking pictures."
"Until 1960, when Francis Gary Powers was shot down," Brian demonstrates that he does know the details.
Everybody is impressed. Slightly with Brian, mainly with the achievement of the people who built the U-2. The only one who looks skeptical is Fred. The accountant.
I look at him, raising one eyebrow. That's enough to make him start.
"You gave us two examples of major snafus, Professor Silver. Can you give us more?"
"No problem," I smile broadly, "how many would you like?"
"You also gave us one example of a major success. Can you give us more of those?"
"I'm afraid not," I admit, slightly embarrassed.
"Exactly as I suspected," Fred responds flatly.
Dear Fred has given me an excellent opportunity to drive home the conclusion I wanted them to reach, but I cannot control myself from asking, "Why did you have this suspicion?"
"From experience." And then he elaborates, "I have worked as a financial manager in three large companies. I have audited more new product development than I care to remember. And like every project auditor, I am quite cynical. Not that I haven't seen projects that do finish within the original, allotted budget, but they are the exceptions."
"That is probably the situation in design engineering," I confirm. "Charlie, is it much different in computer programming?"
"In computer programming we say that a project will always run out of time but never run out of excuses."
I join the laughter. When it dies down, Brian comments, "In the Air Force we always met the final due date." After three seconds he adds, "That means that we didn't meet the first due date that was set for the project, or the second one."
When I can finally speak again, I point at Ted, "What is the situation in the construction industry? Over there, there is less uncertainty regarding the content of the project."
"That's correct," he says. "Our projects are usually not so different from each other so we have a lot of experience." And grinning, he adds, "We also have a lot of experience using any change requested by the client to cover our butts for cost or time overruns."
I glance at my watch. It's time to start summarizing. "Can we conclude," I ask the class, "that the problems common to all projects are," and turning to the board I write as I continue to talk, "the high probability of, 1. Budget overruns; 2. Time overruns; and many times, 3. Compromising the content."
Wall to wall consensus.
"We tend to blame it, in each specific project, on one string of bad luck or another. In my eyes, the U-2 project is important because it's different. It's unlikely that they succeeded in finishing in less than one-tenth the time just because of a streak of good luck. It must be that somehow they succeeded in avoiding the generic pitfalls that get almost every other project."
"How did they do it?" Ruth asks the question that bothers everybody.
"Wouldn't it be nice if we deciphered it?" I answer. "Which brings me to your assignment for the next class."
No matter what the age of the students, the reaction is always the same—a deep sigh.
Heartlessly I continue. "Select a project in your company. A project that has recently finished or is about to be finished. Interview the person running this project—the project leader. Interview the people who did the actual work, and interview the bosses of the project leader. Prepare two lists for class. One: the official reasons for the overruns. The second: the unofficial reasons.
"See you in two weeks."