Software

The truth about zombie projects

Zombie projects are failures that just won't die. Gain insight and understanding into these nasty beasts, and find out how you can be a hero in your organization by killing your local zombie.

This is a guest post from Michael Krigsman of TechRepublic's sister site ZDNet. You can follow Michael on his ZDNet blog IT Project Failures, or subscribe to the RSS feed.

Zombie projects are failures that just won't die. These monstrosities stick around because they're a hassle to fix and no one is willing to muster the effort or courage needed to do the final deed.

Although it's not a new topic, a post today on the client k blog does advance our insight and understanding of these nasty beasts. Client k is interesting, because all her posts are written in free style verse (!); yes, it's weird, but actually does work.

Anyway, I'm reprinting the client k post in its entirety, because it's short and I don't want to break the rhythm:

Zombie Projects

I do NOT like zombie projects.

When I hear of

a project rising from the dead,

I immediately become ‘busy'

with something else

(like filing invoices or painting my toenails).

Zombie projects are rarely successful.

Why?

Because

usually

a project gets brought back to life

due to no one having a ‘better' idea.

That's not reason enough

to see a project

over the many obstacles

a normal project has to overcome.

And a zombie project

isn't a normal project.

It has many more obstacles.

This project has already failed.

No one likes to associate themselves with failure.

The second time around,

most of the people who were so enthused

the first time

are now bitter and negative.

The project team is fighting history.

It is not a new never-been-done-before project.

It is a tried-to-do-and-failed project.

Does this mean a zombie project

won't be successful?

No.

But the odds are not in its favor.

Want to be a hero in your organization? Step up and think through the issues associated with killing your local zombie. Consider the ramifications, develop a plan, gain consensus, refine your ideas, and then take action.

Stopping zombie projects is an essential skill that's hard to master, even though it may not bring either fame or glory. But, remember this: anyone capable of killing a zombie (without causing lots of collateral damage) probably also has the ability to manage a complex project successfully.

[I'm glad client k used the term zombie project, since I don't recall anyone else (aside from me) employ that phrase. Hey PMI, you guys should adopt such terminology into the official Project Management Body of Knowledge (PMBOK).]

20 comments
Baber Majid Bhatti
Baber Majid Bhatti

Relinquishing zombie projects takes a careful consideration, stakeholders' involvement, funding approval and commitment from Management. It must be understood, however, that generally this is a very fruitful exercise in terms of saving from wasted resources as well as time, resulting in better focus toward enhanced productivity. Baber Majid Bhatti - PMP, ITIL CIO / Head of IT Warid Telecom Congo S.A., a company of Dhabi Group from UAE Republic of Congo, Africa Phone: +242-400-7000 Email: babermb@gmail.com

boxfiddler
boxfiddler

Deep in the earth beneath Area 51, scientists have been experimenting for decades in an attempt to create the perfect zombie horde, with limited success (Britney, for example). Their problem lies with the fact that, being scientists, they refuse to employ obligate Vodou technique. (Resistance is futile, though I held off as long as I could without flat exploding.) etu

matt.birchall
matt.birchall

The action list of think, consensus etc is absolutely sound. You have to make sure that you are actually dealing with a real Zombie and you must NEVER try to deal with it on your own. Distinguishing a real zombie from the project where you can't actually see the real goal (perhaps your PM can't articulate the goal very well?) takes judgement and experience. If you speak out without establishing consensus then you will be shot down, torn into small pieces and shown the door.

mdhealy
mdhealy

A former boss called these "NOTLD Projects," from the movie title Night Of The Living Dead.

Englebert
Englebert

1. Kill it or 2. Implement it. I've done both. For 1., make a clear logical case in writing, for killing it. There's always a few who like to keep it going, but if you can make your case well and get support from other execs, the project can be officially terminated. For 2, delegate to a superior Project Leader and throw him the support/tools/resources/profile etc needed to get it over and done with.

jazzdiaz
jazzdiaz

Hillarious and True. I'm dealing with a zombie right now. Its hard to kill a zombie when absolutely nothing has changed since the inception and $0.00 exist in the weapons vault ;)

TheSwabbie
TheSwabbie

When they turn on you and the attacks start.. you can only stop them with head shots. Wood doors offer no protection.. double bolted doors will give you time to get out of the window but if you work in a high rise - you're screwed. Then there's the legal issue of taking guns to work thing. Most employers dont like guns in the workplace, even if you are working on Zombies... Upper Management just never understands the dangers we face on a daily basis. Sad.. and who is left to clean up the mess? Poor janitorial staff - unfortunately THEY sometimes are assimilated into the zombie fold as well and you end up having to shoot them too. Sorry.. you had to say "Zombie" didnt ya... :)

r.m.allen
r.m.allen

When I killed off a Zombie project the team and I came up with some T shirt slogans such as 'Headshot only', 'Loaded with silver bullets' and 'This time we must COMPLETELY sever the head!' We achieved success by saying that it was a truimph of good project management which made everyone feel good about it.

bastien
bastien

Take note of what The Zombie Survival Guide tells us and shoot them in the head so they can't come back for more

MDub
MDub

Due diligence mandates finding a sponsor to "resurrect" the zombies - otherwise..."giving life" to a zombie project could be a career limiting activity. AKA bottom feeder projects that may need to simply be tossed or re-evaluated into another project.

Bob Oso
Bob Oso

Sometimes I swear that our bread and butter seems to be bringing back these nasty critters. Brains!

hauskins
hauskins

that would be interesting to me. We have a few things go on that I think meet the bill. For example, an IdM project that has been going on for at least 5 years if not longer and really has produced very little, except a shibboleth interface that requires hoops be jumped and walk through fire in order to use it. We still don't have a basic directory system to do even simple authentication.

QASIMARA
QASIMARA

re-evaluated into another project. perfect!

b4real
b4real

if that makes sense or not!

ogregator
ogregator

I've seen it before but I never understood what it was and how to deal with it. Also, how do you deal with it if you've got a mad scientist behind the zombie (namely the boss). That's what happened in the past. Some strategies on what to do would be appreciated. K

Gadbois.Joshua
Gadbois.Joshua

One way to kill zombie projects is to point out, nicely, how much the cost is overrunning the budget. That on top of the developed alternate methodology to accomplish the goals of the zombie, building on its bones without catching the rot... Yeah, throw that together and you might be able to convince the mad scientist to refoscus his attention. Make it seem like his idea (We were talking about this the other day, and it got me thinking... what would you do with something like this...)

tr
tr

how management sometimes works. The numbers were kept to a very few people, but the overall effort was considered by most to be a failure. As I said...someone made a promise and was more concerned about delivering on the promise than on doing what was right for the company. It makes you wonder what drives some managers (or directors and VPs) to making the promises they make, especially with such high-level estimates.

JLar
JLar

Not sure what accounting rules allowed the write of the project cost to be greater once the solution was in production but I'll take your word for it. Question is did tax saving from the write off justify the additional costs of completing development, implementation and supporting a redundant application in production for 6 months. Not to mention the opportunity lost using resources that could have been deployed to provide real business benefits. Sounds like it was done mostly to save face for the project sponsor and team which is not a good reason to go forward with a project.

tr
tr

is that sometimes someone made a promise they are unwilling to drop while other times the project spent too much money to throw away. In both scenarios, depending on how much over-budget or how delayed the project is, the original business need may have already been addressed by another solution. This is actually a good thing because it allows the PM to "adjust" the purpose and triple-constraint of the project. For instance, we had a program that was a failure, but management did not want to throw away the "invested" money. We re-aligned the scope to produce a product that was redundant, but in production for a time (six months I believe). Simply having an application in production allowed the "investment" to be written off in a manner that simply cancelling the project did not. This also allowed the promising manager to save some sense of dignity.