≡ Menu

How to Stop a Runaway Project

What do you think when you hear the phrase “runaway project”? When I hear the phrase, it reminds me of movies I’ve watched where there’s a runaway car hurtling down a steep mountain road with no brakes, barely hanging on around each curve. Or maybe you think of a runaway train, flying down the track toward imminent collision or derailment. In either case the idea of a “runaway” refers to something that’s out of control and getting more out of control by the minute. Unless a runaway is stopped, disaster always ensues.

This article looks at a runaway project, drawing parallels to the runaway car example. Let’s start with the cause: what’s the project equivalent of losing your brakes? Car brakes in our mountain road situation help us keep our velocity below the point where we lose control over the car. Of course the maximum speed at which we can maintain control depends on the driver and on the vehicle. An experienced race car driver in a small car that grips the road can stay in control at a higher speed down a mountain road than the average person driving a minivan overloaded with baggage.

The same situation exists with projects. An experienced project manager can move a project a lot faster than someone who is inexperienced; and projects that are well-defined with no obvious technical hurdles are likely to move a lot smoother than projects with lots of murky ill-defined objectives. So right from the start you know that a huge, unwieldy project with an inexperienced project manager has to go slower to stay “in control.”

Brake Failure
The project equivalent to brake failure comes from:

  1. Not stopping to make key decisions
  2. Letting key decisions be made for you without consideration of project implications
  3. Making decisions based on goals that are unrelated to project success, and
  4. Emphasizing project velocity over project control

When you’re driving a car down a mountain, you need to slow down as you approach a tight curve. The faster you approach the curve, the more likely you are to hit a guard rail.

The same thing happens in projects. There are points in the project where you need to slow down and make sure that you’re making the right decision about the next step in the project. If political or deadline pressures cause you to make a decision too quickly – without proper consideration of alternatives – then you’re going to crash into a project guard rail and swerve down the mountain road out of control. You might be able to regain control, but now your momentum has increased, and the likelihood rises of a second crash into a project guard rail. Crash into a few of these guard rails and you begin to panic, causing you to make worse decisions. Bad decisions proliferate, and the project becomes a runaway.

Gravity = Complexity
Now we all understand that gravity is the ultimate cause of a runaway car (you never see a runaway car going up a mountain), but what is the project equivalent of gravity? What is the force that makes the project worse and worse, that makes the project take longer and longer until the project ends with cancellation, a major organizational restructuring, a corporate write-off, or even a corporate bankruptcy?

The project equivalent to gravity is complexity. Just as gravity makes everything fall toward the center of the earth, there’s a natural tendency in human organizations to make things more complex than they have to be.

A key element in successful project management is taking a complex objective and breaking it down into a series of simple tasks that can be accomplished with existing resources in a reasonable amount of time. But with the pressure and attention focused on a big project, not all project managers are able to get far enough along in the simplification process to stay ahead of project effort, and if project effort gets ahead of your ability to manage it then the complexity gets worse.

The more complexity you have, the more decisions you’ll have to make. The project manager gets even further behind in the simplification process. The complexity grows and feeds on itself, building the same momentum of a failing project that you would get from gravity pulling a runaway car down a mountain.

In a runaway project the number of issues will continuously rise, and revised estimates are always too low no matter how many project obstacles are overcome. In essence the runaway project passes the “tipping point” of complexity, and the complexity now feeds on itself to the point where no one seems to be able to get it under control.

How Do You Stop a Runaway Project?
Just as with a runaway car, the first step is to recognize that the situation requires drastic action. Runaway projects continue because everyone refuses to compromise, and so the complexity of objectives gets worse and worse. You can’t stop a runaway project by doing the same things you’ve been doing so far. The only way to bring a runaway project to a reasonable outcome is to make a radical change that drastically reduces the complexity. There is no single approach to doing so, but here are some possible ways to accomplish this goal:

  • Make a drastic cut to the functionality required by the project, possibly by postponing achievement of some of the objectives
  • Break the project into multiple independent pieces
  • Take a multi-organization or multi-person responsibility and give it to one organization or one person who can make decisions to reduce complexity
  • Take multi-location responsibility and give it to one location

There are other ways to do this as well; what we’re trying to do is to get the project past a complexity impasse so that we can restart the project with simpler objectives.

Inappropriate Approaches to Stopping a Runaway Project
You’d be surprised how many people refuse to address the complexity problems of a runaway project. A much more common approach – which doesn’t work – is to add more resource to the project. But with more resource comes even more complexity, and a typical runaway project placed in this situation just accelerates more rapidly out of control. Using this approach is like adding more people to a runaway car – it just adds more momentum and therefore more acceleration, and it increases the casualty count when the car finally crashes.

Another common approach to stopping a runaway project is to change project managers. While it’s true that a more experienced project manager might be able to cope with more complexity than an inexperienced one, the typical runaway project has more complexity than any human being can handle. Even an experienced race car driver can’t drive a car down a mountain road at 500 miles per hour. If the new project manager doesn’t take radical steps to decrease complexity then the project is still likely to crash.

How Do You Prevent a Runaway Project in the First Place?
This is a much easier problem to solve. To prevent a runaway car you just have to make sure that your car is in good condition, that it’s not overloaded, and that the driver of the car is experienced enough to handle the road ahead. The same rules apply in preventing runaway projects:

  1. Avoid huge projects. If at all possible, break big projects into a smaller, less complex series of deliverables.
  2. Focus control on one organization and one person. If work has to be done in multiple organizations or in multiple locations, then (a) define clear objectives and deliverables for each organization or location, and (b) make sure that there is still a single organization and person defined as a focal point for decisions that span multiple organizations and locations.
  3. Avoid project dependence on a new unproven technology. If you have to use a new unproven technology, then do a smaller pilot project first. If this isn’t possible (and I can’t think of too many situations where it isn’t) then identify a fallback plan in case the new technology doesn’t work, and define clear trigger points that specify when the fallback plan will be invoked. These trigger points are important because there’s a natural human tendency to keep postponing the use of a fallback plan, hoping that things will somehow work out. A well-defined rule for a trigger point makes the decision clear-cut and you won’t waste time.
  4. Minimize the number of uncertainties in the project. For uncertainties which remain, do the same thing I recommended for an unproven technology: create a contingency plan and define clear trigger points that specify when contingency plans will be invoked.
  5. Minimize dependence on factors outside the control of the project. They virtually guarantee that the project will run late and over budget, and can cause the project complexity to grow to the point of a runaway project.
  6. Minimize the unknowns. At the very least, you need to know (a) what has to be done, (b) who is responsible for getting the work done, and (c) who signs off on the successful completion of the project. If these three things are not clarified before the project starts, then you might as well start down the mountain road without any brakes at all.
  7. Avoid “over-using your brakes.” Most brakes fail in a mountain road situation because they’re used too heavily at the top of the mountain and so they overheat and stop functioning. You can do the same thing in a big project if you exert too much control early and then have the control taken away from you in retaliation. Like brakes, project control is something that should be used judiciously and with some finesse and delicacy.

Conclusion
There are probably a few of you reading this article right now who are in the middle of a runaway project, and I wish you luck in applying some of the techniques described in this article. What most people don’t realize is how emotionally charged the issues are. There’s unbelievable pressure from everyone to make the project succeed, yet that pressure just makes matters worse. Even if everyone agrees that complexity needs to be reduced, there will be a huge debate about how the complexity will be reduced, since no one wants to give up on their own objectives for the project. Often it takes an impartial outsider to break the logjam and figure out the best way to reduce complexity.

For those of you who have never been involved in a runaway project, my advice is to be careful – you’re not immune. Follow the recommendations in the article for preventing runaway projects, and you may be able to avoid them down the road. The advice is good for all projects so you don’t need to worry about when to apply the recommendations – just apply them all the time and your projects are more likely to be successful and less likely to be runaways.

Comments on this entry are closed.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this. For more information on the use of cookies on this web site, see http://blog.makingitclear.com/cookies/

Close