It’s a week before halloween and I’m getting prepared for the neighborhood beasties and ghosties and their insatiable appetites for tooth-decaying treats. Several years ago, my wife did something different and bought a case of microwave popcorn packages for me to distribute to the spectral beggars. I was expecting insults and the odd raw egg but to my surprise, I heard a lot of complements and not a single complaint.
Halloween is full of projects – from setting up the decorations and purchasing the candy to the individual projects each kid (or their parents) undertakes (unintended pun) to put the perfect costume together and collect their treats. It got me to thinking about Halloween and how it can apply to project management.
The first thought that popped-out of my sometimes overactive imagination was the “death march” project concept described by Edward Yourdon in the eponymous book Death March. In a nutshell, a death march project requires unsustainable effort on the part of the project team to complete. Team members feel as if they are on a real death march because they may have to work extraordinary overtime in an attempt to finish the project and deliver the product. In his book, Ed Yourdon goes into all kinds of detail about death march projects, which I won’t go into here. You are better off learning from the master by reading his book.
Conflating Halloween and death march projects got me to thinking about what happens in the space between a death march project and the successful (or otherwise) end of a project? Can a project be “undead”? A zombie project? Maybe I’m on to something? Nope. A quick internet search showed a slew of stuff out on the web discussing zombie projects.
So what is a zombie project? Like its namesake, a zombie project never ends, it just keeps lurching along, perhaps dropping an appendage here and there, eating brains along the way (I added this to heighten the sense of Halloween – projects don’t really eat brains…). Imagery aside, what a zombie project does is ceaselessly consume resources (people, time and budget) that could go to other, more important efforts. It’s the project that won’t die.
Checking the Pulse
How do you know if a project is among the “undead”? Trust your gut, it will tell you if the project is stuck between a death march and the dead. But if you need more than a feeling to judge if a project is a dead project walking, here’s a few things to look for:
Who’s in charge?
If you can, place everyone directly involved in the project – from the executives in charge to the project team members – in a room. If you can’t do this (perhaps because it’s never done), picture it in your head. Now go to the front of the room and describe the role and characteristics of an effective project sponsor. (Have an outside consultant do this if it could result in a career-ending injury.) Next, ask the project sponsor to raise their hand.
Did anybody raise their hand? If not, the project is a zombie because there’s no executive leadership involvement.
Did more than one person raise their hand after each person scanned the room like contestants in the old To Tell the Truth television show? Two or more sponsors are not better than one plus the people with their hands up are not sure who the sponsor is. This is the same as not having a sponsor.
If a single person raised their hand, and they said the sponsor was not in the room, this is the same as not having a sponsor. If the sponsor can’t spare the time to come to the meeting, then there’s a good chance that the project is not important to the sponsor.
If the person with their hand raised said they were the sponsor, do they have the “horsepower” to serve as the sponsor? For example, is the person claiming to be the sponsor a senior executive with the formal authority to clear a path through the organization for the project? If so, maybe they don’t understand their role on the project. Some one-on-one training may help. Or, they may not have the time or inclination to serve as the sponsor. The path forward could be to appoint a different executive to serve as the sponsor.
If the person with the raised hand doesn’t have the formal authority to affect the project beyond their span of management, then they cannot be an effective project sponsor. There are two options: you can give them the formal authority (by promoting them) or find a new sponsor with sufficent authority and the will to effectively sponsor the project.
I’ve picked a lot on the project sponsor here, but the key to preventing a project from turning into a zombie or to lay the zombie to rest lies with those having the formal authority to do something about it. Project team members can’t stop the zombie nor can the customers and stakeholders.
Is there a project charter?
I know what you’re thinking – why would any organization spend resources on an unchartered project? A zombie project may have a charter – but it could be so old and dusty that it’s lost somewhere in the file cabinet of time. If you can’t find the project charter, then it is time to write a new one.
We’re not done yet, keep reading on…
Is the project charter up to date?
Assuming you found the project charter, when was it last updated? Things may have changed since it was written. The charter should identify and have the signatures of the project sponsor, project manager, and other key participants (such as the SCRUM master and product owner if using SCRUM for software development).
Are the people that signed the charter still working on the project or have they since left?
If the key project stakeholders (sponsors and team members) have left the project, then you should update the charter to show who is currently acting in what capacity. It is also a good indicator that your project oversight processes are moribund and it is to liven them up.
Is the project charter consistent with the project team’s understanding of the project?
The project charter is the project team’s charge – it defines the scope, or the boundaries, of the project result. It is like a contract between the project sponsor and the project team. Without a well-crafted project charter, you have a zombie football game. The players mindlessly lurch down the field while the goalpost move farther apart, never to be reached.
Periodic review of the project charter helps the team maintain focus. It also helps prevent significant changes in project scope, which could cause the project to go off in an unintended direction (moving the zombie goalposts). Perhaps the project team is pursuing some objective never envisioned in the project charter? Or the project scope is inaccurately described in the charter?
Another issue could be the charter itself. A well written and organized project charter shouldn’t take up more than a single sheet of paper – front and back. If you have one of those 10 page project charters (and I’ve seen them), then chances are the charter describing a program and not a project. Or it could be a project management plan (which usually comes after the project charter).
You’ll know if it is a program if you can break down the objectives into separate, smaller well-defined “de-scoped” projects. You should also review these smaller project scopes and determine their complexity because it plays an important role in how the project is ultimately managed. You should then create new project charters (because there may be more than one project).
Do you have the right people working on the project?
Do the project team members have the experience and skills necessary to complete the project? Review the complexity of the project. In addition to the technical complexity, you should also review the project stakeholder “social structure”. A more complex project could have stakeholders from many different organizations. Dealing with the politics and communications challenges in this kind of environment adds another dimension of complexity to what could already be a very technically complex effort.
Complex technical projects with complex social structures call for experienced project managers and technologists. It’s OK to have inexperienced team members on the project – that’s how they become experienced. But it’s a big risk putting people not having the relevant experienced in charge of these kinds of complex projects.
Are project leaders accountable to the sponsoring organization?
Project leaders (project managers, SCRUM masters, product owners who are not contractors) have to be accountable to the project sponsor. A quick way to determine if a project leader is accountable is if the project sponsor can directly influence a project leader’s performance review. Having a project leader making unsupervised project decisions affecting the sponsoring organization’s budget while not technically an employee of the sponsoring organization is a big risk.
Now that you’ve verified that you have a zombie project, what’s the next step? There’s three things you can do:
- Don’t do anything and let the zombie lumber along. This will work for so long until you can’t afford to feed the zombie or the zombie hunters (auditors or the inspector general) sends it off its partially mortal coil.
- Use a magical potion to return the zombie to normal project life. After reviewing the project and making changes to address the situation, restructure and relaunch the project. You’ll have to make some tough decisions along the way. Also, you can’t let things go back to the way they were before lest the zombie return.
- Terminate the project. This may be impossible if the zombie project is a high priority for your organization, leaving the magical potion as your only choice.
If you have a zombie project, good luck and try not to get bitten!