PPM - The Spectre of PPM Failure and Knowing When to Abandon a Project

Best practice guidance insists that, at the initiation of a project, there is an assessment of how the undertaking supports the organization's objectives and analyses the impact of its potential failure. The guidance goes on to discuss what makes a project successful in the eyes of the organization and how an experienced board should identify the missing pieces from a project plan right at the beginning.

The simplistic view of what constitutes project success is "completion"; we got through it and we delivered something. But is the thing delivered what you wanted? Is it fit for purpose? Has it met the cost parameters agreed at the start? Four out of five projects don't deliver exactly what was promised and there needs to be a review at the end of the project that examines fully the cost, benefits, and quality of the output and whether any changes that were made to the project plan are acceptable.

The traditional view of a successful project is that it achieves all of the following: delivered within the agreed timescale, on budget and meeting a desired level of quality.

However, it's not always a guaranteed formula: London's Tower Bridge is a good example of a project that failed on time and cost but excelled in quality. No-one could have predicted that it would work as an end-product, but it did. London's Millennium Dome didn't deliver on its original intended purpose - and was regarded a failure - but is now a successful building.

Nevertheless, the potential fall-out from missing any one of the time/cost/quality criteria very much depends on the type of project. Preparations for any Olympic Games couldn't fail on time; in pharmaceutical manufacturing, drug quality is paramount, therefore time and cost can afford to slip. It's necessary to apply the test for how far a project can deviate from its original tolerances in order to be judged a success.

In terms of pulling the plug on a project, it's easier to evaluate the time and cost elements for failure and as soon as the associated tolerances are broken the issue should be escalated immediately to the project board and executive. Assessing a failure of quality is a trickier task, but there should be a quality management strategy and quality criteria in place. Is it a lack of quality in the processes or the product? Whichever it is, the endgame should be about concluding whether or not the project should progress.

Projects can be halted for a number of reasons, and there are several technical terms that describe the differences:

A delayed start, as the name implies, might be the end of the project before it even gets going, especially if the delay affects the viability of the business case. But once a project is underway, slippage can happen; based on costs escalating and time slipping out of control. This needs to be monitored constantly throughout the project as some of the original considerations may make the project unviable as it progresses. If, at some point, project suspension is deployed, the prospect of re-starting the project is, consequently, founded on a fundamentally negative business case. Availability of sufficient budget and resources will dictate whether it's worth starting the project again.

The decision to abandon a project is one for the board and is normally informed by a project's increased costs, inadequate quality, overrun time and absence of benefits.

What the board needs to have is comprehensive information from the project to make the decision and that should have included lots of "red flag triggers" along the way. This is easier when the signs of project failure are more extreme and less so when the project problems are more marginal.

There has to be a clear understanding of the consequences of not continuing with the project and, in some cases, there could be a strategic advantage to persisting with it. For example, if the project is part of an overall programme the board may decide to continue with the individual project because it fits into a bigger, and necessary, picture.

With project best practice frameworks such as PRINCE2® there is a governance structure in which decision makers are tasked with reviewing the viability of projects at every stage and ensuring that that board remains informed. And there are defined, control mechanisms that specify the information needed to make the decision about whether a project lives or dies. Project plans will often include decision points for the early stages of a project that will facilitate termination so that resources can be redirected to other projects that present a greater chance of success. And the best practice frameworks are more than theoretical; rather a set of best practice tools based on the real experience of project managers in the field.

Altogether, it provides a sound approach when confronting the unsavoury, but sometimes genuine, prospect that a project is doomed.