One of the greatest challenges can be knowing when a project has passed the point where it can no longer feasibly be completed. The factors behind terminating a project may vary; the complexity involved, limited staff resources, unrealistic project expectations, a naive and underdeveloped project plan, the loss of key stakeholders, higher priorities elsewhere, or some other element – but likely it will be a combination of some or many of these possibilities.

For example, a company with multiple sites might have decided to migrate from a tape backup environment – which is expensive, time-consuming to administer, and prone to error – to a cloud storage backup solution provided by a third party vendor. Halfway through implementation it becomes clear the backup process will consume more bandwidth than expected, will take an inordinate time to complete backing up servers with hefty storage levels, and will cost more in the long run than the existing tape solution which can be refactored for cheaper, more efficient and less complicated administration. Clearly this is the proverbial “record coming off the needle” moment at which a harsh truth must be acknowledged.

It’s all too easy to get trapped in the mindset of wasted investment. When we’ve invested time, labor and reputation on the completion of a project that might not pan out, the pain of losing existing investments can be a terrible burden to shoulder. However, it’s important to take a look at the big picture.

Last year, Genpact released a report based on investment in digital technologies called “Putting digital to work the lean digital way.” The report stated that “Our research indicates that if the right strategies aren’t adopted, nearly US$400 billion per year could end up in initiatives that return inadequate ROI. What’s more, these mistakes could provoke strategically dangerous delays in adopting digital business and operating models–and that could result in significant missed opportunities.”

More unsettling is the fact that, according to the report, “on average only 33% of significant IT projects have been fully successful since the year 2000. Worse, that figure falls below 20% for projects larger than US$3 million.”

It’s clear that a graceful exit strategy is needed for projects that must be euthanized. Here are ten tips to help you pull it off and move forward to more fruitful pastures.

1.Get buy-in from project stakeholders and agree on conditions

Before terminating an unworkable project ensure that the stakeholders are all on board with the decision as well as the reasoning behind it. Everyone involved should come to a consensus regarding how and when to end the project before announcing it to the rest of the company or management. No one involved with the project should encounter any surprises when it is terminated.

If possible, announce the decision collectively as a group, so no one person or entity is seen as being to blame or being naysayers.

2.Work within the realm of possibility

Ironically, ending a project is easy if it simply can’t be done. Enumerate the strategic reasons why it’s not possible; either the technological concepts behind the project aren’t sufficient, security constraints or requirements are too prohibitive, cost has grown prohibitive or some other factor renders the project objective unobtainable.

However, tread with caution here, because if performed clumsily the project originators could be seen as poor planners for not knowing something was impossible before launching a project based upon it.

3. Communicate what’s inside and what’s outside your control

If conditions changed during the initial course of the project and rendered it impossible (a key vendor went out of business, for instance, or a discount thought to be valid turned out otherwise and inflated the costs), make sure to include this information in the announcement.

Similarly, if the project needs to be canceled because staff lacks sufficient knowledge at present, be honest and upfront about this – but see if you can rectify the situation to revisit the project down the road. If it’s within your power to change the situation in the future, make all available efforts to do so.

4.Emphasize what you can do, not what you can’t.

Not every doomed project needs to completely bellyflop. Is there some sort of alternate solution, even a stripped down concept? For instance, rather than killing an initiative to deploy tablets to the entire remote worker fleet due to security/loss concerns, can you identify a subset of the original user group who might still receive such an implementation? Gaining some measure of benefit from the original project rather than none is obviously preferable and can help pave the way towards revisiting the project in its entirety later.

5.Stress the need to support the business

When canceling a project, always approach the concept from the aspect of doing what’s right to deliver the best value to the business by not wasting capital or resources on an initiative with lower payoff than you expected.

The goal is to make it clear you’re not shirking work simply due to a complexity factor (nobody wants to be seen as unwilling to follow through on their objectives), but rather acknowledging you’ve gone down the wrong path and are returning to the proverbial fork in the road to pick a different option. The job of the IT department is always to do what’s best for the company, rather than pursuing its own ends or striving to save face.

6.Emphasize the cost advantages of moving onto other priorities

If you can achieve cost savings by shutting down a non-workable project, make sure to enumerate the details. Hopefully if you’re pulling the plug amidst a proof of concept or demo phase, any investment in hardware, software, support, and other elements is minimal or non-existent.

If a project can be completed but would be too costly to do so (or the expected outcome would not be up to par), provide details regarding the return on investment to explain why it’s not feasible. Don’t forget to factor in the expected labor as well as actual costs, since that constitutes an expense for the company as well.

This may be painful if you lobbied hard that the project would in fact save money down the road, but it’s important to realize that circumstances change and again, your job is to do what’s best, not what’s advantageous to your reputation in the short-term.

7.Emphasize the business gains of moving onto other priorities

Emphasize what the IT department intends to work on in lieu of the terminated project and what advantages this endeavor will bring, to illustrate the bigger deliverables at stake.

Focusing on urgent priorities elsewhere to bring about a greater strategic advantage is one example. Retooling the project for a later date when conditions change so you can address outstanding needs (or await technological developments which might rekindle the project) is another.

8.Hold a postmortem review to avoid repeat mistakes

An analysis with all involved stakeholders should be conducted to examine what went wrong, where the problem lay, and how to determine viable project candidates next time. Keep it blame-free and focus on what gains have been made from the failed project – learning about restrictions or capabilities previously uncharted, finding out about system or software limitations, addressing knowledge gaps, etc. – to realize and benefit from all available positive outcomes from the experience.

9.Analyze the project management product or methodology

This is a perfect time to review how projects are managed by the organization and identify areas of improvement. Is there an issue with planning or research? A breakdown in communication? A problem with a vendor? Inefficiencies in time estimation? Find out the pain point here which caused the project to fail.

10.Improve the project planning process for next time

With the facts gathered, now is the time to improve the project planning phase so that the pitfalls encountered here might be anticipated and avoided next time. The goal is to either determine more effectively what will or won’t work from the outset or to establish a point of no return at which point an ongoing project either goes forwarded or should be shut down as simply as possibly if determined to be a bad fit for the organization.

Hopefully these tips will serve as a good guideline for you to effectively implement future projects, or at the very least establish a baseline for identifying when an ongoing project should be canceled with minimal disruption, cost, and impact to departmental reputation.

Also see
How to mediate disputes during an IT project
5 ways a negative corporate culture can kill your IT project
Pull the plug on an IT project as a last resort
How to evaluate project management software