Cancelling Projects: The Project Isn't Being Done Right

In part 1 of this article series, we accepted that Projects sometimes need to be cancelled. In part 2, we look at how sometimes the Project being worked on is no longer the right Project. In this part 3, we will look at the other cause of cancelling: the Project isn't being done right.

A classic way to consider project performance is via the triple constraint of scope/cost/time, often with quality thrown in the mix. However, despite the best of intentions, it is widely documented how projects often go awry during delivery. Cost or schedule over-runs, or low quality output that don’t meet the requirements; everyone has not only heard but probably been involved in a project car-crash. Although these Projects can sometimes eventually be recovered and successfully deliver what they set out, on some occasions they could go so far off the rails that they becomes undeliverable – perhaps it many times over budget and years late. It may be time to cancel.

The focus here should be on the Project Business Case: the document where the benefits of the project are weighed against the associated costs. This Business Case will constantly evolve, and as a Project is delayed or proving more costly than initially forecast, it will start to impact that careful balance of cost vs benefit to the point where it may eventually tip over the threshold of just not being worth it. What causes this? There are of course a myriad of potential causes, but if a Predictive lifecycle was used then essentially the Projects Performance Measurement Baseline wasn’t robust enough: Estimates too optimistic indicating a flawed estimating process, too many unknowns not effectively managed via the risk process, ineffective project management or technical skills, or perhaps requirements were not well enough defined. If an agile development method was used, perhaps the initial backlog wasn’t sufficiently documented, Project or Sprint goals ineffectively understood, poor backlog prioritisation and maintenance by the product owner – indicating a skills gaps etc

In this case, the desire that drove the original project to be initiated may often still exist. The result here is that a change of approach may need to be considered. Perhaps a revisit of the often key “buy vs build” decision, change in a key supplier, or perhaps a fundamentally different technical approach to delivering the desired outputs.

Have you ever worked on a Project which has been way behind schedule, or hugely over cost? Have you ever had to fundamentally change your approach? Let us know in the comments below!

Stay Healthy! Project Health Check - projecthealthcheck.org