How to kill a dead project

What do the zombie apocalypse and many businesses have in common? Answer: dead things that refuse to lie down and be still.

The dead, brain-eating things businesses have a hard time killing are shambling, resource-eating projects.

You know the ones. They’re projects where the meetings continue, team members still charge their time, but not only is there no forward progress, no two people seem to even agree which direction “forward” is.

But while everyone knows how to kill a real zombie (chop off its head), killing a dead project isn’t quite so simple.

There are three equally difficult steps to dead-project killing. The first is identifying the zombie. The second is persuading those who can kill it to kill it. The third is shutting it down. The first is forensic. The second is primarily political. The third is a matter of logistics.

How to spot a dead project

In zombie cinema, mistaking a live human being for a zombie can be pretty embarrassing. That’s also true when killing zombie projects, so first make sure the project really is dead, with no hope of resuscitation.

With zombies it isn’t hard to tell the difference — either there’s a pulse or there isn’t; either it’s trying to eat your brains or it’s not.

A dead project? Here are some of the signs and portents:

Team dysfunction: No two people on the core team can stand to be around each other.

Blame shifting: Whether it’s the sponsor, project manager, or a team member, when there’s no progress being made there’s always a reason that has nothing to do with the project’s definition, governance, leadership, expected value, methodology, or anything else, other than something “they” should do but aren’t. And “they” generally lacks an antecedent.

Definition: As in, too many definitions as to why the project is important enough to take on. This isn’t a problem at project startup, as there’s a sometimes-uncomfortable process through which project teams figure this and each other out. But within the first month or so, everyone should have ironed out their differences, and their views of the project should have converged by then. But after enough time has passed, if everyone still has a different perspective on the project’s fundamentals, the situation is grim.

Redefinition: For many imploding projects, the “real reason” for the project — according to team members, the project manager, and possibly the sponsor as well — has nothing to do with the official reasons used to approve the project in the first place. If the company’s decision-makers only understood that this is what really matters — “this” being some fringe benefit that seems to be panning out better than the project’s planned work products — they’d understand everything is fine.

Sponsor apathy: Some projects are unmistakably dead on launch. They’re the ones where the company’s executives have to assign a sponsor because nobody cares all that much whether the project succeeds or fails. Or they reassigned sponsorship when the original sponsor moved on to greater things.

Project sponsors have to want their project to succeed, deep down inside. They have to be willing to take risks, advocate budget and schedule changes when a situation calls for them, and make difficult decisions about controversial matters such as design trade-offs. Projects with apathetic sponsors — or no sponsor at all — have no chance of success and never did.

Committee as sponsor: Sometimes companies mistake steering committees for sponsors. Big projects usually do need steering committees, but their role is project governance, not sponsorship. If a committee is supposed to be the sponsor and there isn’t someone on the committee who’s acting like a real sponsor, that’s another sign it’s time to pack it in.

How to initiate the kill command

Whichever of the above symptoms apply, if you’re convinced the project is truly dead, gather your arguments and head to the executive sponsor’s office. It’s the one and only place to go to kill a dead project. Just as the sponsor has sole authority to declare a project done, so too is the sponsor the only one who can put it to pasture.

What’s that? You thought a project was complete when all the deliverables in the statement of work were checked off? That may be what it says in textbooks, but it isn’t how it works in your average corporation. The sponsor either agrees it’s done or it isn’t done. Period.

Anyway, if you can’t persuade the sponsor the project has “joined the choir invisible,” give up. You’ve done all you can. Making your case with anyone else will cause you political grief with nothing to show for it. You’ll look like a backstabber no matter how pure your intentions.

But don’t sit in your office and suffer, either. If your reputation is attached to the project, start your job search now, when the project is still officially alive and reputation-enhancing, before the symptoms of project zombiehood are so pronounced even the most head-in-the-sand sponsor and steering committee can’t ignore them.

How to shut it down

Shutting down a dead project is a lot like shutting down a successful one, only without the celebratory pizza. Here’s what has to be done, by whom, and most important, in what order, because the sequencing rates somewhere between sensitive and problematic.

Conduct a post mortem: But don’t call it a post mortem. Otherwise, you’ll have violated the most sacred rule of the executive suite: the No Surprises Rule.

Executive leadership can’t hear the project is dead from anyone except the sponsor. But the sponsor won’t have the ammunition to survive the experience until after the post mortem.

So don’t call it that. Call it the Project Rescue Planning meeting instead. The sponsor convenes it. It’s attended by the core project team, a few trusted stakeholders, and a dispassionate outsider whose role is to keep everyone honest.

The official purpose is as the name suggests. The real purpose, however, is twofold: To persuade attendees that the project can’t be saved, and to develop a plausible Plan B that’s relatively low risk, relatively inexpensive, and avoids the mistakes that led to Plan A’s demise.

Ideally, this meeting is in the morning, followed by a meeting between the sponsor and executive leadership team (ELT) later the same day.

Inform the executive leadership team: Every failure that involves enough money to matter makes the ELT look bad, so they won’t be happy. But delaying won’t make them happier, and if they don’t hear directly from the project sponsor before they hear from someone else, well, the consequences are obvious, aren’t they?

Nobody likes getting bad news. The more strategic the project had seemed, the worse the news will be. If it’s big enough that the board of directors knows of the project, it’s going to be downright ugly, especially if the board is wondering when the results will go live. But it still has to get done.

To the extent the sponsor can direct the conversation, it covers the results of the project rescue planning meeting, and a sketch of the Plan B that came out of it. The only outcome that’s required, though, is that the ELT agrees the project is dead and it’s time to stop throwing good money after bad.

Protect the project manager and project team: Except in Dilbert cartoons, nobody comes to work planning to fail. It’s almost Shakespearian: Some people are born to fail, and a few more achieve failure. Most, though, have failure thrust upon them. Odds are, the project manager and most project team members fall into the third category.

So, making exceptions for a possible few bad apples, the project sponsor and project manager should meet with each team member’s administrative manager to explain what went wrong on the project and how the team members were more victims than perpetrators, encouraging the administrative manager to find productive roles for them.

In some cases it will make sense for the sponsor to bring the project manager into his/her organization, too.

Announce Plan B: Presumably, a lot of employees know about Plan A, the now killed project. If for no other reason than to limit grapevine-driven disparaging conclusions, it’s worth announcing that Plan A is no more.

Except, what the announcement will ostensibly be about is the launch of Plan B, which will incorporate the most important components of Plan A.

Decompress: Being part of a zombie project is, if anything, harder work and more stressful than being part of even the worst death march project. Just as you give employees a breather when a successful project team disbands, extend the same courtesy to those who were part of the zombie project.

Learn something: A famous story about IBM’s legendary Thomas Watson Sr. describes how he refused to accept the resignation of a sales representative who had blown a very important deal: “Why would I accept this [letter of resignation] when I have just invested one million dollars in your education?”

Your employer just invested quite a lot of time, effort, and money in a project that delivered no direct value.

You have an important role to play in making sure its indirect value — important knowledge about how make sure the next project doesn’t turn into a zombie too — becomes institutional knowledge and not just a subject everyone politely avoids.

Related IT strategy articles:

More about IBMPlan B