That’s right, we’re not supposed to talk about death, even when talking about projects! But let’s be honest, some projects are destined to fail. Some are destined never to even start. So why is it then, when we have an initiative “coming off the rails” or the market suddenly shifts, there seems to be a push to keep a project alive? Instead of charging the paddles and clearing the area, we should be talking about how to move it to the next life.
There are a couple types of project deaths we experience.
The first is the project that, though conceived, was never born. Someone had a great idea, or an operational efficiency project, that never was initiated. Mature organizations with portfolio management and governance committees reviewed the request and decided not to move forward with it. Sure, the person requesting the project may be upset, but as the individual or committee charged with selecting and prioritizing projects, you know this is for the best.
But, instead of governance saying (in your most angry German voice) “NEIN, ZIS VEE CANNOT DO!!” and storming away, there needs to be a library of project requests for future reference. Maybe the idea is two years too soon. Instead of forgetting about it, create a space to archive these project requests. People come and go from companies all the time, so periodic review will be necessary.
The second type of project death, and the more difficult, is the project that’s in progress. You and the team initiated this effort with high hopes of success and already put in time and effort. Sponsors and the management team committed money and personnel. Maybe there was even a press release. In any case, a project was initiated and work under way.
But something’s happened. Maybe the project has come off the rails (massive scope creep, uncontrolled expenses, another important project comes up that takes priority, continually fails testing, sponsor hit by a bus and no one else to give direction). Maybe the market shifted or a competitor released before you, grabbing potential customers. Whatever it is, the project needs to be killed.
Now, I won’t go into how it could be saved or how to be more proactive up front to ID potential issues. Instead, I’m going to assume all that was done and despite best efforts, it’s time to pull the plug. Yes, it sucks, but it has to be done. As humans, we’re born with compassion and by nature struggle with death. This includes your projects, because with its death comes the thought of a bad mark on your career and potentially a job loss for you (especially if a consultant) or members of your team (especially if they’re consultants brought in for this project).
Just because a project is terminated doesn’t mean you shut the lights off and walk away immediately. It’s best to make the termination decision, close it out quickly and get staff re-assigned sooner rather than later. Why prolong the agony?
PMBOK offers inputs and outputs for closing a project, so I won’t elaborate. Instead, I’ll offer my recommendations on preparing your project for death:
With the Sponsor/Exec Team:
- How the hell did this happen (aka document lesson learned)?
- How much money will be lost/sunk costs?
- How quickly can we get the project team re-assigned so they don’t feel like crap and think they failed?
- Who can attend the team meeting to help explain why we’re killing this project?
- I need money for a happy hour!
Be ready for a finger-pointing session. Even if you say at the start of the meeting no one is to be blamed, it’ll happen. Because money is lost, blame will be cast and those in the room will try to protect themselves. Do your best to stick to the facts, just know the conversation usually turns to the blame-game.
With the team:
- Explain why the project is being terminated (keep it factual and don’t place blame either on them or anyone else)
- Did we finish anything that can be released or transferred to another team?
- Anything 1/2 done and is it worth finishing it up (i.e. half way through a sprint)?
- Determine what documentation needs to be buttoned up
- Any process or document improvements (i.e., lessons learned)?
- Throw a happy hour and reimburse the Uber rides home!
One of the real “messy” aspects in both of these instances is the emotional issues. Those requesting projects can feel like their ideas have no merit and they’re not listened to. Project managers of in-progress initiatives feel like they’ve done something wrong (and sometimes they have). When emotions come into play, try to remain empathetic, but also be factual and honest about why this is happening. As someone who’s had a project killed half way through as well as been the one to decline a new project request, honesty is key in the discussions you’ll need to have.
Preparing a project for death is never easy. It can happen anytime between inception and before completion. Most times you see it coming (at least you should). Other times you don’t. In any case, when it happens have conversations and document. Death can come to any project, so be prepared when it happens.
Bridge the Gap Consulting, LLC 