The following interview originally appeared in the August 1998 issue of
Management Roundtable's PDBPR
ON SADDAM HUSSEIN, MILESTONES, AND HOW THE THEORY OF CONSTRAINTS APPLIES TO PROJECT MANAGEMENT
AN INTERVIEW WITH ELI GOLDRATT
With his latest novel, Critical Chain, Theory of Constraints pioneer Eli Goldratt tries to do for project management what he did for manufacturing in his 80s best seller The Goal. In a largely favorable Harvard Business Review critique, Jeffrey Elton and Justin Roe argue that Goldratt’s book presents powerful suggestions for individual project management, but falls short when it comes to overall portfolio management and overlooks what they think may be the greatest constraint: a shortage of skilled leaders. We spoke with him about these and other issues:
BPR: What led you to turn from manufacturing to product development ?
EG: "If you look at my work as a whole, you’ll see that I started in production, then went to finance and accounting, then to marketing and sales, then to distribution, and, finally, with Critical Chain, to projects. In Theory of Constraints you start to believe more and more that there is one constraint that is limiting the leap of the company. But when you open that constraint, of course, performance does not jump to infinity. Some other constraint jumps to the center for performance improvement.
"Many times, it is simply moving from one function to another. The problem is, when it moves to another function you don’t know how to handle the new constraint. Then you start to stagnate. Unfortunately, what happens is not really stagnation because after awhile the stagnation turns into common practice. Then you may ruin the company. So if you improve production what happens many times is that the constraint moves to distribution or sales. Then you improve that and it moves to engineering. And then what? That’s what led me to product development and project management."
BPR: The ideas in Critical Chain sound great—if only everyone was that rational!
EG: "Everybody is rational. Unfortunately, not everybody starts from rational assumptions. I had this debate once with Israeli intelligence. They wanted to use my methods. After four or five days, when we had analyzed many things, they said, ‘Wait a minute. We have here a preconception problem. We’re analyzing everything logically. But some of our enemies are not logical. So whatever we do in terms of predicting what they are doing is worthless.’ I said, ‘No, what we call irrational behavior is simply the person behaving according to another set of assumptions. But within that he is very logical.’ So we took as an experiment the most illogical person you can imagine—Saddam Hussein—and we built the future scenario of his actions. And he was behaving so logically that we knew what he was doing before he
did. Many times we claim that people are behaving irrationally because we put them into a conflict and we are looking at only one side of the conflict. So of course it looks to us as though they are behaving irrationally."
BPR: You seem to say that a key part of planning is to really focus on a few key constraints. One of these is resources. How does an organization get the kind of internal collaboration needed to move resources where they are needed, when they are needed?
EG: "You must always go for a win/win solution. What we usually do is act out of a culture that teaches us to think the cake is finite. Then you have lose/lose: if I win, you must lose. You can always find resources, if you really want to. Look at the peace process [Middle East]. They argued about three percent and then they found it in the Judean Desert. There is always a way the question is do you want to do it?
"It's much easier in an organization. If you look at my books, you'll see that I show that the thing that needs to be sacrificed are some policies that nobody wants to protect. Nobody. The size of the batch, for example. Everybody thinks it's stupid, but it's convention. Or look at how we do projects in a multi-project environment. It looks like four people trying to rush through the same door at the same time. Eventually they will come out--a little bit crippled!
"If they go one at a time, there is no problem. But there is a stupid assumption that says the earlier you start, the earlier you finish. That's not always the case. And once you explain the whole cause and effect logic, you don't have a problem. It's not as though we are trying to sacrifice something holy."
"Part of the discipline Goldratt offers involves the proper use of measurements. He reminds managers of two criteria: measurements should induce the parts to do what is good for the whole, and measurements should direct managers to those parts that need their attention. Many managers rely on milestones to monitor a project's progress (and individuals' performance, but that practice violates both of the above principles. Following the maxim, How you measure people is how they'll behave, the book [The Critical Chain] points out that management by milestone motivates members of project teams and their managers to insert safety time before each milestone. Once safety time has been added to each task, various mechanisms arise that waste that time. So, Goldratt concludes, the fewer the milestones, the fewer the delays. We have found such dysfunctional behavior occurring when milestones are set as artificial review points tied to the end of a development phase or task stream."
Jeffrey Elton and Justin Roe
"Bringing Discipline to Project Management"
Harvard Business Review March-April 1998
BPR: How do you respond to those who say the biggest constraint in product development is lack of executive decision-making discipline?
EG: "Of course! How can you make a decision when the things on the table are so big and whoever you ask says, 'I don't know'? Even when you ask, 'When are you going to finish, in two months or four months?' you get 'I don't know.' And the same people who refuse to give the data complain about lack of decisions from the top. What happens if you sort things differently, by sacrificing one of the assumptions, is that all of a sudden you can give reliable estimates and the same person can make a decision on the spot."
BPR: Jeffrey Elton and Justin Roe, writing about Critical Chain in Harvard Business Review, suggest that more often than not the big constraint is a real shortage of leadership skills.
EG: "I disagree. I find that in most organizations, when we are dealing with the more tangible constraints, the constraint ends up usually being friction in human relationships."
BPR: How does the time it takes to implement Theory-of-Constraints thinking in product development differ from production? What key behaviors change? Is it about eliminating waste?
EG: "It takes six weeks in production, six months in product development. Behaviors that change? Better communication, increased trust, greater pride, and people not running around like chickens with their heads cut off. You call it eliminating waste, I call it eliminating ingrained stupidities!"
BPR: Is it a correct reading of your book that you don't favor formal milestones?
EG: "I hate formal milestones! It's one of the diseases. It's nobody's intention to get control in such a way that you definitely lengthen the project, yet that's what formal milestones do. The problem with milestones: if you have a milestone two months from now you immediately get the student syndrome. 'There's time, let's waste it.' You'll get some surprises and the safety's gone. Then, when you achieve the milestone, it's 'Now we can relax.' Then another week is gone. All in the name of control!
BPR: Buffers are a key element of your Critical Chain thinking. What about the tendency to pad?
EG: "Today, we put a buffer in for each activity. Everyone is protecting his own activity. His 'realistic' estimate means he has a 50 percent chance of finishing, which means he's already padded, he already has a buffer. The idea I'm proposing--and it's known to every student of statistics--is that statistical deviations average out.
"Which means that if you strip the safety from individual tasks and put it at the end of the path you need much less safety to handle the same amount of deviations. "You don't really care if each task, on its own, will be early or late. What you care is whether the project will be early or late. So the whole idea is to swap all the safety to the end.
"This is not so easy because you have to convince people to give up covering their ass in order to protect the company. You're asking them to trust their managers not to crucify them and most people don't trust their managers very much for that sort of thing. So, to implement this idea means a lot of education, particularly of managers. After it's done once, the whole environment changes because everyone gains so much confidence."
BPR: What do you say to those who see the book as mostly suited to individual projects?
EG: "Before I wrote the book, I knew I was dealing with two distinct markets: the single-project market and the multi-project environment. I told myself that it would take a long time for the multi-project environment to move on my ideas. The cultural change needed would be tremendous--it would take longer than it took to change production. I wrote The Goal in 1984, for example, and only now are the ideas being widely implemented.
"Because cultural change in product development in a multi-task environment is so much bigger, I decided to focus on the single project. The person in charge is a single manager. He's already in trouble so he'll do anything to save his project. I was surprised by the intense interest in the book that came from the multi-project environment. I immediately wrote another book called Project Management the TOC Way in which I show exactly how to implement in a multi-project environment."
BPR: Is it available?
EG: "I've distributed about 4,000 copies personally, so the pressure's off. Hopefully it will be published by the end of the year, but it's not at the top of my current priority list."
BPR: What is at the top of your priority list?
EG: "When I talk to managers, I find that one of the biggest problems in most companies is that most of their people don't see the company as a whole. They see fragments. Because of this, you get localized optimums, many wrong decisions, and much miscommunication. So the question I'm currently focused on is: can we educate the entire management of the company, in one shot, in a short time, and very effectively? I don't know.
"But next March I'm doing an eight-session satellite program starting from the same base and covering all functions. I'll show exactly how to change each function to common sense rather than the prevailing view. We'll look at how everything ties together, hoping that this will generate a common language, much better communication, and a slew of correct initiatives that can lift the company."
BPR: Will you share your thinking about this at MRT's conference?
EG: "Yes, yes, yes. Project management was the last piece of the puzzle. Now all the parts are covered by the same logic. You've seen how Critical Chain works with the concept. Now I can show how everything is tied together and how every function can understand and help the other functions."
When you open one constraint, some other constraint is likely to take its place
Often constraints merely move from one function to another
The best way to get collaborative resource sharing is always to go for win/win
It's about "eliminating ingrained stupidities"
When it comes to buffers, don't focus on individual tasks; keep your eye on the end of the project
The big problem in most companies today is getting people to see the company as a whole