When you have a failing project you are faced with the question of whether to perform project CPR or let it die. There are times when a project shouldn’t be resuscitated, even if it’s not failing.

I had a client that had spent $1.5 on an HCM implementation. They were faced with a product that wasn’t aligning to their needs and a software provider that wasn’t responding to the issues. As painful as a decision as it was, they decided to kill the project and go back out to market for a new solution.

You should kill a project if:

The business outcomes can’t be achieved. In my example, the solution was the wrong fit and couldn’t meet the business objectives. The software provider wasn’t culturally aligned either. If you are going to be working with a software provider on an ongoing basis, the company culture needs to be a good fit to yours. It’s often something we overlook when evaluating solutions, but time should be spent understanding how the solution provider deals with problems and supports their customers.

The market changes and the business case becomes irrelevant. I do a lot of work in Australia and am consistently frustrated with slow internet speeds. In 2009, Australia was faced with an inadequate broadband network. It had fallen behind other first world countries. Because of this, it rolled out the NBN initiative in order to get broadband to small businesses, schools, and homes. The goal was to reach 12MBPS. In 2016, $7.3b had been spent and less than 5% of households had been reached. The project is still ongoing and is quickly becoming a pale solution with the impending rollout of 5G networks. 

The business case isn’t validated, particularly the assumptions. Better yet, don’t even start the project. A mining company wanted to buy a new mine. As part of the business case, they said they would buy the mine and build a rail line to move the ore. If for some reason they couldn’t build the rail line they would put it on a barge and send it down the river. The business case was predicated on the movement of this ore. They bought the mine and the government wouldn’t give permission to build the rail line. No problem. Barges down the river! After spending $3B on this mine, they discovered they wouldn’t be able to move the ore. Barges couldn’t go down the river. The water wasn’t deep enough. Ensure your business case is built on valid assumptions.

The ROI is going to be poor. If the spend is out of control and you can’t justify the outcomes against the cost, the project should be killed. 

The organizational buy-in is lacking. The idea may be great, the ROI fantastic, the outcomes completely desirable, but if you can’t get commitment from the organization to complete the project, it should be killed. Being able to implement an IT project successfully requires partnership within the organization. If that partnership isn’t there, the solution is either not going to obtain the targets or it will but at a significant overrun in costs. An organization that is resistant to a project will drag it out, put up artificial barriers, and delay adoption all of which impacts project costs.

Organizations should be brave enough to kill projects. With limited resources, it’s imperative we are focused on the right areas. That said, if you’ve decided you’re in a position where there is still value in finishing the project, it’s time to rescue it! Check out our other posts about recovering failing projects.

Jana Axline is Chief Project Officer at Project Genetics and the author of Becoming You. Through her leadership musings, she inspires audiences to grow as leaders and ultimately achieve who they were created to be. For more information visit Project Genetics.