To kill a project ...

Written by Bryan Fenech, Director - PPM Intelligence.

"Action expresses priorities" - Mahatma Gandhi

When to kill off a project, and the decision criteria for doing so, has been a prominent discussion topic among my colleagues lately. It seems that it doesn't happen nearly as often as one would expect. And, perhaps surprisingly, there is not a lot of science that goes into such decisions.

What the theory says

The theory says that you should kill a project when its business case no longer makes sense. There are 2 reasons why this may be the case. Either:

1. Costs are higher than expected because of delay, poor estimation of effort, error and rework, or resources have become more expensive than planned, or
2. Benefits have been compromised due to delay, overly optimistic estimation of new revenue or cost savings, competitors getting to market first, downturn in market conditions, or disruption of the market due to external conditions.

The availability of other projects that represent a better return on the investment of organisational resources should be a determining factor also. Why persist with a project that is no longer expected to deliver valuable outcomes when there are other more attractive options?

What happens in practice

In practice these principles are a good basis on which to make a case to wind up a failed project. More often than not, however, I find its much simpler than that and if there is a major project failure - usually a significant delay or cost blow out - no one will want to be associated with it.

However, statistical studies such as the CHAOS Report suggest that, while about 25% of projects are failures that are killed off at some point, about 50% continue on through to completion even though they are on average around 200% over budget or late. The latter figure suggests its harder than expected to kill a project, and not always a rational decision.

Human factors

This accords with feedback from some of my colleagues from the MBITM Program at the University of Technology, Sydney who work in the field. Consider the following 2 quotes which I think put the matter succinctly:

"It seems to me that many projects don't refer back to the Business Case often enough. And that human trait of wanting to salvage something (anything!) from the investment in the projects leads to a reluctance to kill it off." 

"I've not seen any project 'killed' in my experience. What I've experienced is that when a project fails to deliver, rather than killing it then and there, more resources (money, labour etc.) are thrown at it to 'make it work' - nobody wants to be seen or associated with a failed project. Or it is re-scoped to such an extent that it really bears no resemblance to what was originally envisaged or sign(ed) off on. Successful projects have many parents, while a failed project is an orphan."

Killing a healthy project

I have heard it sometimes said that the maturity of an organisation's portfolio management capability can be measured by its ability to kill projects that are not troubled.

The reasoning is that an organisation with a high portfolio management maturity level will be so in tune with its resource-supply/project-demand equation that it will be able to respond to new opportunities and make space for them by stopping or deferring less valuable in-flight projects.

But is it really that easy? In my experience, not only do organisations not have the tools to do this with any level of rigor, but there is no agreement on the critical issues involved.

For example, when comparing the value of a new opportunity with an in-flight project should we take into account the sunk cost expended to date in the latter? If we do a straight NPV comparison at the time of decision the in-flight project has already expended some of its costs so its NPV at that point will be hard to beat? Alternatively, should we include this sunk cost in the NPV equation? But if we do that then it is no longer an NPV that we are measuring but a present value of both past and future cashflows.

Another problem is that the estimates for in-flight projects are likely to be more accurate than those for a new idea. Should we discount estimates, or apply a risk factor, to account for the different levels of confidence?

What does best practice say?

There are no hard and fast rules here. Both of the key industry standards - Management of Portfolios (Axelos) and The Standard for Portfolio Management (PMI) - are silent on these questions. This is curious given that killing off projects when appropriate is often cited as one of the key objectives of portfolio management.

This area is ripe for field research to survey and gather data on how organisations are approaching these issues.