Over the years, I’ve seen various statistics on the success rate of software implementation projects.

These metrics are usually used to point out the superiority of Agile over Waterfall, but I get something different out of these numbers: I get that 86% of Waterfall projects and 58% of Agile projects fail or are “challenged.”

There are plenty of other studies out there with their own figures, but the key message is this: Well over half– at the very least– of software development projects will face “challenges.”

Obviously, you want your projects to not be on that list. And let’s generously say that your projects never have those sorts of problems. But other people’s projects do, and sometimes you’ll get asked to rescue those projects.

Rescuing projects is clearly a common activity; too many projects need help, even more so because so few projects simply get killed when they have problems.

So how do you know when to kill it…or save it?

Kill It…or Save It?

  1. Sometimes there’s a misunderstanding on the level of difficulties that may be faced. Project sponsors think a project is close to being pulled out of the fire when, in fact, it is completely ablaze. Verdict: kill it!
  2. Sometimes the answer is to adjust the project’s goals, sweep some issues under the rug, declare victory and pretend that this is where you were headed all along. That’s not being dishonest: That’s being honest about how the project value measures against continued investment. In this case, the option might not be “cancelling” the project exactly, but still… Verdict: death, but in a gentle way.
  3. Sometimes there’s a feeling of stubbornness, not unlike the primary participants in World War I: After all the effort and cost, the only justification for the sacrifice is victory, and that victory will be achieved regardless of the additional sacrifice required. Verdict: kill it!
  4. A good test question is the extent of the problem you’re facing. A project may be facing challenges, but they’re surmountable challenges: The core activity of the project can be maintained, the objective remains the same, but other changes are needed. The schedule should be re-baselined, perhaps, the team structure modified, and maybe make a few additions, changes, and deletions to the team roster. Verdict: rescue!
  5. In some companies, some proportion of projects are expected, and perhaps even desired, to fail. There may be a spirit of, “If we never fail, we’re not pushing the envelope enough.” At Microsoft (at least at one time), there was a philosophy of permitting multiple competing projects to operate, with the best one surviving. If you’re in an environment like this, there’s probably a protocol for handling the projects that aren’t going to make the cut. A desperate rescue attempt would be a waste of time. Verdict: kill it!

Project SOS

Finally, there are the projects that truly in desperate shape. How can you tell if your project is one of these?

The less emotional way to judge a project is by what the risks are compared to where the project is in it’s lifecycle.

Early in the project, an indication that a rescue may eventually be needed is that the project has significant issues that are already indicated as “red,” with near-certain impacts on schedule, although no delivery dates may have been missed yet.

In the middle phase of a project, the danger is suggested by significant issues indicated as “red,” preliminary delivery dates have been missed, and it’s becoming apparent that deployment dates cannot be met.

Late in the project – near when the project should be completing its deliverables – the need for rescue should be obvious: the project has missed delivery or deployment dates, and not by a week or two.

Those are the unemotional answers. However, if you’re using words like “rescue,” you’ve probably already got a pretty emotional situation.

That sort of situation looks like this:

  • The project is in dire straits.
  • It cannot practically achieve its objective, schedule, or budget.
  • Stakeholders question the value of the project.
  • Projected benefits are openly ridiculed.
  • People associated with the project cannot agree on the situation and rarely agree with each other on anything else.
  • Even a straightforward declaration on meteorological conditions and the time of day will be challenged.

In short, something has gone terribly wrong, and incremental change will not work. The project is drowning and needs to be rescued.

Given the dreadful situation the project finds itself in, it should be no surprise that the remedy will be uncomfortable.

Making the Decision

A project cannot be rescued without significant changes to its structure, scope, resources, approach or objective. If all it took were a minor tweak, you wouldn’t be talking about rescuing it.

So when we talk about rescuing a project, all of those things have to be on the table. If anything is kept off, you’re restricting your ability to make the changes necessary for success.

Originally published on LinkedIn. This article is adapted from John’s upcoming book, “Project Leader to Project Believer.”