A runaway project is like a married couple on the brink of divorce. There are two opposing points of view, both sides are usually angry, each side blames the other, legal action is imminent, and a lot of time and money is being wasted.
So why do projects go into a runaway mode? It’s usually because requirements are changing faster than the project team can keep up with them. It’s like swimming upstream in a tidal wave — no matter how hard you swim you still get swept back by the overwhelming water.
But that just raises a different question, doesn’t it? Why is it that requirements are changing so much? Shouldn’t requirements change the most at the beginning of the project while they’re still being defined, and then settle down once the requirements are written down and agreed to? Yes, of course, but that “normal” way to define requirements is usually based on some erroneous assumptions.
The Usual Erroneous Project Assumptions
Most runaway projects start by making one or more of these assumptions:
- It makes sense to freeze requirements at a moment in time and then stick to them, no matter what happens.
- The requirements process is perfect and what’s written down is exactly what the customer wants.
- The requirements as written are totally unambiguous, consistent, and doable.
- The customer fully understands what’s been written down and agrees that it’s correct.
- The project team members fully understand what’s been written down and plan to do exactly what the requirements say.
- The project estimates are in fact based on the requirements — not on a similar project done elsewhere for a different set of requirements.
- The project will be completed quickly enough that no requirements will change during the project work.
None of these assumptions are valid. In most cases we base a project on incomplete requirements that are likely to change during the project — requirements that aren’t totally understood by either the customers or the project team. In fact, when you think about it, it’s a miracle that any IT projects are ever completed on time and within budget. The latest statistics from the Standish Group show that only 32% of IT projects are completed on time and within budget, so in fact it does seem to take a minor miracle to make a project succeed.
The Path to a Runaway
Let’s look at a typical runaway project. Some of them start on time and even look pretty good for a while. But pretty soon minor things start to get on people’s nerves. A requirement changes, and the impact of the change on the project is underestimated. A new technology turns out to be more difficult to use than anyone thought. A higher-up agrees to a change without understanding the huge effect it will have. A late delivery of a key subproject causes everyone to reevaluate what’s going on. Changes begin to accelerate, making the project later. The later the project gets, the more changes there are. The change rate exceeds the capacity of the project team, and someone naively suggests that more project resource ought to be added. Of course the additional resource just makes everything even later due to coordination issues and getting everyone up to speed, and the late project builds up momentum. The “burn rate” of the project increases to the point where it gets more executive attention, and this leads to extra executive reviews, which tie up critical project resource and make the project even later.
Runaway projects aren’t called “runaway” for nothing. They burn money like crazy, they get later with every passing day, and they often can’t be stopped except by killing the project outright.
Go back to the married couple on the brink of divorce. What could be done to try to save the marriage? Many people try counseling — bringing in a third party to help with communication [more on that subject next week]. I’m told that most marital problems have their root in communication, and if two people can really talk to each other and if they really want the marriage to be saved, then they can usually work things out.
Why don’t we attack runaway projects the same way? It’s the same issue — communication. The customers want something, and the project team is having trouble delivering it. There are really only two choices: revise the requirements to deliver what’s possible, or figure out a way to deliver what the customers want. Usually the solution is a little of each.
What’s different about the runaway project is its scale. Big projects involve big egos, politics, and all of the baggage of previous projects gone wrong. Working things out between customers and the project team isn’t just working out a disagreement between two people. It’s working out many disagreements among huge groups of people. It’s owning up to mistakes that were made. It’s accepting the fact that you may not get everything you want. It’s making compromises.
Marriages tend to collapse when the husband and wife lose respect for each other’s goals. Many marriage ceremonies recognize three interests in a marriage: the husband’s, the wife’s, and the interest of the married couple together. All three interests have to be recognized, discussed, and prioritized.
It’s the same thing with projects. There are three interests in a project: the customer’s, the project team’s, and the interest of overall project success. Runaway projects happen when the focus shifts off of overall project success and instead onto the individual interests of the customers or the project team. Irreconcilable differences and runaway projects go hand in hand. And after a divorce or a cancelled project, it’s only the lawyers who end up ahead of the game.