22 Feb Why Killing Projects Is So Hard (And How to Do It Anyway)
It was to be a great digital leap for Germany’s biggest discount grocer. Instead, after seven years and €500 million in sunk costs, the project tasked with creating Lidl’s new inventory management system with SAP was killed in July 2018.
In planning since 2011, the project quickly lost its shine when roughly a thousand staff and hundreds of consultants started the implementation. The costs quickly spiraled beyond the two groups’ estimations without bringing the project much closer to success.
Not every project makes its way to the finish line, and not every project should. As a project manager or sponsor, you’re almost certain to find yourself, at some point in your career, running a project that has no chance of success, or that should never have been initiated in the first place.
The reasons why you should kill a project may vary. It could be the complexity involved, staff resource limitations, unrealistic project expectations, a naive and underdeveloped project plan, the loss of key stakeholders, higher priorities elsewhere, market changes, or some other element. Likely, it will be a combination of some or many of these possibilities.
Why Killing Projects Is So Hard.
When it comes to killing projects, a number of obstacles can get in the way, leading to projects being killed too late or not at all.
#1 Ego
Most people want to succeed. After putting time and effort into a project, no one wants to give up without a fight. Being labeled a quitter can mar an otherwise stellar career. As a result, some projects continue long after it becomes apparent that significant problems exist.
And when multiple parties collaborate to produce an outcome, the many points of failure exacerbate the situation.
Ego is a big part of our professional lives, because no one wants to fail, and certainly not in public. If it was your idea to start a project, it’s tough to say, ‘I was wrong.’ However, project managers and sponsors should set aside ego and reevaluate projects based on costs and benefits, no matter whose idea it was.
#2 Ownership
People who have ownership of a project often aren’t objective about it. They get too close to the project and become emotional about it, taking it personally.
If 20 people are working on a project for a year, they feel invested in the outcome and want to bring the project to fruition no matter what. Telling that group that its work is headed to the trash heap sounds like failure. You’re killing their “baby,” and it might be difficult for them to accept.
#3 Momentum and inertia
Newton’s first law of motion states:
When object at rest stays at rest and an object in motion stays in motion with the same speed and in the same direction unless acted upon by an unbalanced force.
The bigger the mass and the faster the object is moving, the more force you need to apply to stop or divert it.
Often, projects are not killed simply because they are close to being completed, and the desire to check the final few boxes and declare the finished project a success may outweigh the fact that the project is not very useful.
People’s natural inclination is to focus on the positive. The question we ask ourselves is, ‘How do we save this project?’ instead of, ‘Should we be killing this project?’.
#4 Culture
It’s easy to kill a project if the culture is one of taking risk and understanding that some projects will work and others will fail. Such a culture will help you look at those projects as learning opportunities rather than failures.
But most organizations are far away from having such a culture, and tend to play it safe rather than abort something they’ve invested valuable time and resources in, even if it’s doomed to failure.
#5 Sunk costs
The decision to kill a project should be based on future tasks and future value. Sometimes, a project continues because of money already spent. When time and resources are invested, no manager wants to stop a project. But that money isn’t coming back.
The focus should be on how much more needs to be done, or how much more needs to be spent, and what benefits would accrue from the project once completed. If those benefits do not exceed the costs of taking it from here to completion, then you should kill it, regardless of the money spent already.
#6 Fear
Killing our own project is scary. We are afraid of losing the respect of our peers, a promotion, or even our job. We are afraid of the unknown, of what happens next.
How to Do It Anyway
Whatever the underlying reason for keeping something going might be, knowing when a project is doomed, and knowing how to end a project gracefully, are essential skills for any project manager or sponsor.
Killing a project is never a fun or rewarding process, but the alternative—allowing a hopeless project to linger for months (or even years), continuing to consume valuable resources—is even worse.
The strategies listed below will help you when it’s time to put an early end to a project.
#1 Understand the impact to the organization.
Ending a low-priority, low-visibility project can be very simple — a quick meeting or two with project stakeholders, a bit of documentation to tie up the loose ends and you’re done.
Killing a project with a large budget, large project team and high level of involvement at the executive level, on the other hand, is enough to rattle the nerves of even the most confident project manager and sponsor.
Before you take any steps toward ending a project, think about who will need to be involved in the decision, who should hear the news first and what (if any) contingency plans will need to be put in motion.
#2 Don’t play the blame game.
Usually, when a project needs to be terminated, a number of people have made (big) mistakes somewhere along the way. No matter who’s to blame, you won’t do yourself any favors by pointing the finger.
Your end-of-project report should give an accurate description of the reasons that the project needed to be killed, and that’s all. Any unnecessary or excessive details about mistakes by team members, executives, vendors or anyone else will give the impression that you’re trying to deflect blame from yourself.
#3 Establish a process.
Implement a decision-making process to shut down non-functioning projects. If a temporary endeavor fails to progress on schedule or produce intended results in a timely manner, it’s time to close the project and consider re-allocating its resources towards starting a new effort.
You need to have somebody on the team whose focus is always about, ‘Is this reality? Can it get us to where we want it to?’ Without a formal process, team members may assume they have to continue until the documented end of the project.
#4 Set a time bomb.
Set a time bomb for your project. Essentially, it’s an exploding deadline that forces you to kill your project if it doesn’t get to the level of success you want by a specified time.
If _______________ (project name) doesn’t achieve _______________ (directly measurable metric of success) by __/__/____ (specific date less than 6 months in the future), _______________ (project name) automatically shuts down. We will cease future work on it and the automatic consequence goes into effect and I have to shoot my project in the face (figuratively) and walk away.
This is extra tough when you have a project that’s not necessarily bad, but may not be the best project, either.
#5 Fail fast and kill early.
Try to kill as many projects as possible as early as possible.
Ask yourself the following question: “What must be true for this project to be successful?”
In most projects there are probably thousands of things that must be true as well, but generally no more than four to five items control the success of a project.
Validate these assumptions and if they prove to be false, you’ll know the project doesn’t have any legs to stand on and you should kill the project on the spot by not allocating any more money or talent to it.
The beauty of this approach is that you can get answers to these questions by conducting small and inexpensive tests to give you a sense of whether your new product will be successful or not.
#6 Get buy-in from stakeholders.
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 it’s announced 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.
#7 Face reality.
Ironically, ending a project is easy if the project simply can’t be done. Enumerate the strategic reasons why it’s not possible; perhaps 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 this is performed clumsily, the project originators could give the impression of being poor planners for not knowing something was impossible before launching a project based upon it.
#8 Communicate what’s inside and what’s outside your control.
If conditions changed during the course of the project and rendered it impossible (for example, a key vendor went out of business, 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 every effort to do so.
#9 Focus on business impact.
When canceling a project, always approach the decision from the angle 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 that you’re acknowledging you’ve gone down the wrong path and are returning to the proverbial fork in the road to pick a different option.
The goal of a project is always to do what’s best for the company, rather than pursuing its own ends or striving to save face.
#10 Focus on the financials.
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 in the midst of 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 it 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 for the company, not what’s advantageous to your reputation in the short-term.
#11 Create a supporting culture.
People that kill projects should not be punished. They should get a spot bonus from their manager. They should get promoted because of it, not despite it. They should get exciting new jobs — as soon as a project closes down, people get snapped up by other projects.
In other words, remove the fear and make it safe for people to kill their project.
If you are a project manager or sponsor, it’s your job to remove as much inertia and fear as you can for your team.
Closing Thoughts
Knowing when to kill a project and how to kill it is important for the success of organizations, project managers and sponsors.
Keep an eye out for warning signs, ask yourself tough questions, and set aside your ego. By doing so, you can easily identify projects that need to be abandoned right away.
Closing failed projects might not be the easiest thing to do but if you know how to kill it the right way, it won’t be a problem.
Have you ever killed a failed project? What were the reasons? What do you believe is the right way to kill a failed project?
Article written by Henrico Dolfing 22 January 2019.
www.henricodolfing.com