How to Revive a Dead Project

Before you start planning a slew of projects for the year, revisit last year’s duds. A project that appears to be dead may be a prime candidate for revival. Make a list of projects that either you or someone else started, but never finished, last year and ask yourself these questions:

Why did we drop the project?
How far did it get?
What’s changed since we dropped that project – company objectives, the competitive environment, project personnel, technology, etc.?
What new information do we have now?
Is the project still relevant?
Is it still viable?

In terms of time, budget, effort, and professional rewards, completing a project that everyone assumed was dead can be an extremely appealing venture. The glitch is – be sure you can resurrect and finish the project. Once you take it on, you own it and you don’t want to be the owner of a twice-failed project.

A poor set of objectives is the main reason projects fail - the objectives are either too vague, too ambitious, or too complex. It doesn’t matter whether it’s about raising hamsters or designing skyscrapers – when the situation is too complex, people feel like they’re over their heads. When they feel like that for too long, they’ll do anything to relieve the stress – meaning they’ll release hamsters into the woods and let building projects die.

Other, less common, reasons for failure are poor communications, lack of planning, and schedule/budget overruns.

On the other hand, projects tend to be successful when:

They have clear objectives.
They have executive support.
They meet milestones.
They allow for flexibility without compromising core parameters such as budget, deadlines, and accountability.
They’re run by an experienced manager.

An experienced manager will limit the scope of the project, present a concise case to executives, create evenly spaced achievable milestones, and build strategic flexibility into the plan. In short, whether it’s a new project or a derailed project, experienced project managers keep things as simple as possible.

So, the best way to begin reviving a dead project is to simplify it. Consider a project revived - not when there is nothing more to add - but when there is nothing left to take away.

It’s true, you can fix almost anything by simplifying it – but it’s much harder to simplify things than complicate them. Ask artists which they’d rather paint, a simple cube or an urban landscape and most will go for the urban landscape. Complex allows for mistakes; simple doesn’t.

Complex requires action; simple requires thought.

There are seven basic steps in the sequence for identifying and reviving viable projects.

1. Decide if the Project is Worth Finishing

Ask yourself if aspects of the remaining project could be accomplished more efficiently some other way or if they even need to be accomplished at all. Imagine that you’re able to finish the project successfully. What contribution will the project make to your organization?

2. Determine the Reasons for Failure

If you can’t pinpoint the reasons for failure, don’t resurrect the project. But if you know why the project failed, it’s fairly easy to determine what the chances are of overcoming those failures. Talk to the members of the project team and ask them three questions:

In your opinion, why was this project shelved?
Now that you’ve had some time to think about it, do you think it’s worth saving?
What would it take to bring this project to a successful conclusion?

Be sure to ask these questions to each member in isolation. Otherwise, you’ll end up being drawn into the same group dynamic that may have caused the failure in the first place. Look at the project documents and notes objectively. See if you can find evidence to support what project members have told you.

3. Determine if the Failure can be Overcome

For example, if an IT R&D project was dropped because it ran seriously over budget and you know that R&D will have a tight budget this year, your chances of successfully reviving the project are slim. On the other hand, if two unqualified members of the project team caused the project to fail and neither of them is working for your company now, it might be worth taking another shot.

4. Document the Current Status

How far along was the project before it was dropped? What was accomplished? What still needs to be done? A six-month project that died in the third week is very different from one that died in the fourth month. The longer the project survived, the better your chances of concluding it on the second try. Projects that end early usually have a fundamental planning flaw. Projects that end late are often plagued by time and/or budget overruns - sometimes it’s because team members are simply fatigued.

Also, you may find that there is actually very little left to be done. For example, the project may have derailed because two different consultants were unable to produce a customer survey that the project team could approve. Even though the project was just about done, the survey was a critical piece and finding another consultant was a hassle the team couldn’t deal with.

5. Clarify Requirements

At this point, if you’re clear about taking on the project, start by clarifying every aspect of the project plan. Look for vague language and remove every qualifying word that’s not necessary. A big culprit is the word help. Eliminate it from your project planning vocabulary. For example, don’t’ write, The new cubicle configuration should help facilitate communication. What does help really mean here except that the planner is unsure of the project’s value and wants to build in a little wiggle room. Any time you take on a project – new or unfinished – you’ve committed to see it through. The project plan’s language should reflect that.

Also, look for phrases that can be interpreted more than one way. For example, Members will meet every other Tuesday. What about months with five Tuesdays? Does that actually mean every other Tuesday or twice a month?

If you find requirements that are so fuzzy you can’t figure out what they mean, eliminate them. Alternate project team members cannot be supervisors even though they may be in a supervisory position. What on earth does this mean?

Don’t rule out writing a completely new plan – it might be easier.

6. Simplify the Remaining Project

Projects have a way of ballooning – especially in the early stages. Some projects are more vulnerable than others – website revamps, for example. Strictly limit the number of people that are allowed to have input on the project’s scope and content and you limit the bloat.

Returning to the hamster analogy, once you realize that you have more hamsters than you can handle, it’s usually too late to regain control. So keep the project as simple from the start as you can. Better to start with 1-3 objectives, have a clear plan on how to accomplish each, and proceed micro-methodically, than have 12 objectives that no one can keep track of.

Areas to trim include:

The number of people involved in the project
The complexity of the project plan
The scope
The number of objectives
The number of supporting documents
The number of meetings

7. Adjust the Parameters

Once you’ve edited the project plan so that the language accurately reflects your intentions, you’ll want to re-estimate everything – most especially the budget and schedule. Be precise and clear. Use calendar dates and even specific times, where possible.

Here’s the part you won’t want to do, but you must.

Take the revised project plan to the original project team members. Ask them to review your plan and get their feedback. In most cases, you’ll find their advice invaluable. At this point, if they don’t think your plan or the project is viable, it’s probably not. If they seem enthusiastic, it’s your green light to go ahead.