Projects fail for all kinds of reasons. Stakeholders can change their objectives. Key team members can leave for other companies. Budgets can disappear, materials can be delayed, and priorities can go un-managed.
If any of this sounds painfully familiar, or if you already know that you’re struggling with project failure, you’re not alone. In fact, the United States economy loses $50-$150 billion per year due to failed IT projects alone.
Fortunately, your project doesn’t have to fail.
While Dilbert might be the most frustrated project manager on the planet, he’s not an idiot (his boss, on the other hand…). He tries to take the right steps to save his projects, even when they’re continually failing.
Below, we examine how Dilbert would save a failing project — backed up by original research from Gartner, iSixSigma, PMI Project Zone Congress, The Institution of Engineering and Technology, and Government CIO Magazine. Follow these four steps and salvage your failing project!
Step 1: Stop and evaluate
I get it, stopping a project isn’t as easy as it sounds. Rescuing a project takes planning, and the process can weeks. While project managers can easily stop purchasing software and hardware, breaking up a team is a whole ‘nother beast. Gartner asks, “Are valuable, productive reassignments available? How long will it be until the team reassembles?” Those answers aren’t easy.
To help ease the pain of stopping a project, work with the team members’ managers to identify and assign interim work. Meanwhile, take inventory of existing project collateral, like notes and designs, and store them in an area where it would be difficult for someone to tamper with them.
After that? Before doing anything else, be clear, concise, and concrete: communicate to your team why their project is on hold. This process is absolutely crucial. Take the time to learn as much as you can about the team’s opinions of the project and of each other. Learning that their project will be put on hold will inevitably create distrust. Transparency and tailored messaging is the best way to mitigate bad feelings.
Next, check your ego. Go to the major stakeholders and ask for anonymous feedback on their view of the overall project. When evaluating their responses, don’t forget to consider company culture and politics and how those factors may have played a role in forming the stakeholders’ opinions.
Big action items: Issue a “stop work” order and talk with everyone.
Step 2: Figure out why your project is failing
While Dilbert struggles with a pointy-haired boss and a company that’s functionally-challenged, sometimes the cause of project problems are not immediately obvious. Even the best project managers — those with excellent project plans, appropriate budgets, and fantastic scope control — struggle, on occasion, with project failure.
Why? Answering that question is the goal of step two.
Surface-level answers are often the temptation when project managers reach this step. They might focus on the complexity of their project, their outdated project management software, their unclear objectives or their stakeholders’ lack of involvement, but all of these problems are so generic that they don’t provide enough insight to create real solutions.
Ask why. Why are objectives unclear? Why aren’t users getting involved? Be specific when answering these questions. Consider using the lean management “five whys” technique to parse out answers to these tough questions.
Of course, some of these answers may be hard to hear, and solutions can range from the challenging to impossible. Remember: if these issues could be easily remedied, they would have been addressed and resolved. Even simple problems — like a team member leaving — can take months to fix. Ask yourself: are you using the right technology for the job? Are your dependencies so external that project control is simply out of your hands?
If you’re still struggling to figure out where the root of your project failure is, consider these seven issues. They tend to be the most common causes of project failure.
Complexity
External
Financial
Operational
Organizational
Schedule
Technology
From there, take the time to identify which risks you will face when trying to salvage the project. Are those risks worth it? Is the project salvageable? Answer these questions before moving on.
Big action items: Establish allowable solutions for project rescue (including project termination), identify root causes of the problem, and identify risks to project continuation.
Step 3: Set up the war room
Okay, general. This is your shtick. You get to assemble a team, seat them all together, and work through a rescue workshop. You’re in the mentality of “kill” or “fix—” you’re done fact finding, asking question for further research, or finding other excuses to delay the process. That should all have been done in step two. You’re ready to figure out what the heck to do with your project.
The “war room” will be intense. The decision-making process could take two hours, all day, or, rarely, all week. All key decision makers must be present. I realize that might not be possible, especially if the project is an all-day affair. Some executives may prefer to be called in as the meeting is nearing its end, where team members can present prepared options (such as “kill” versus “worst case”).
To get the most out of the workshop, take the meeting offline. If possible, conduct the entire meeting face-to-face or, if you must, over web conferencing software. Try to limit the meeting to ten people, including the most important stakeholders (like the sponsors), project manager, senior team members, and maybe a technical representative to give insight to plan feasibility.
Of course, the war room isn’t something to mess around with. Prepare for it. Create an agenda to go over findings, from quantitative reporting to team member interviews. Encourage pre-war-room collaboration toward the ideal shared result.
When you start the war room meeting, all project material should be readily available. That’s your fact base. Without it, you’ll start to make assumptions and decisions without facts to back them up.
Knowing the facts is only half the battle. The purpose of the war room boils down to answering these three deceptively complex questions:
Is the business case still valid?
If the business case is no longer valid, is there potential for a new, reimagined, justified business case?
(If so): Are the added costs for project rescue worth it?
Encourage your task force to focus on identifying the project’s primary driver that governs decision making (ex: budget, schedule, scope, or quality). Ideally, there should only be one driver that controls the outcome of the project.
Sometimes the primary driver is beyond repair. For example, if the core due date has passed and it was aligned with a market cycle (ex: Black Friday to Christmas), then the project is irremediable.
At this point, a common place to start is with identifying what the team can do with the least amount of effort. Develop a scenario that costs the company the least and gets closest to achieve the primary goal.
If that seems out of reach, prepare a recommendation to terminate the project… but not without scrutiny. While it may seem simple to kill a project, make sure you consider trade-offs that could make the worst-case scenario more possible than originally thought. Furthermore, think about the potential backlash from killing a project. How does that decision affect business strategy? Other projects? Public perceptions? Potential future clients? All these variables must be considered and thoroughly addressed in the war room.
Should the least-case scenario have legs, take the time to explore more alternatives. Try to dig up solutions that can tackle more of the project’s objectives, and consider how adding those solutions to your plan can create additional potential scenarios — positive or negative.
From there? You know how much project managers love documentation.
Write down the main points of your plan in a revised project charter.
During the war room discussion, it’s not uncommon for stakeholders to propose a replacement project instead of a rescue. That’s a totally viable option — kill the project, salvaging only essential, functional portions of the original attempt, and work to create a new plan.
If you end up deciding to completely start over, abandon project rescue altogether. Justify the replacement project on its own merit (yes, that means redoing a budget, staffing, identifying scope, and so on).
In other words, that scenario ends with the project manager terminating the project with the intent of trying again at a later date.
Big action items: Set up your war room, re-engage stakeholders, and create a tentative plan to move forward.
Step 4: Set your project in motion
Following your war room meeting, your next steps are all about follow-up — even if you and your team decided to kill your project (though that’s beyond what we’ll cover here today). The real project rescue starts here.
In many ways, this last step is the most challenging part of project rescue. Re-engage stakeholders around the contents of the new project plan. Confirm the project’s path forward with all who will be involved, in complete detail with precise commitments for each team member. You should finalize your plans quickly — less than a day or two — at this project stage.
Remember: trust is key here. Hesitation and procrastination can limit team commitment and lower morale. You’re the general; get your troops ready to re-engage!
Validate where you can, removing unknown variables (like whether preferred contractors are free or if key team members with specialized skills have been pulled to other projects). Oftentimes project managers don’t run into these difficulties, but when they do, make sure your communication is clear. Confirm that new stakeholders accept their new responsibilities to the project.
As the project rolls forward, be sure to detail the new project’s profile, scope, and size to the core team and beyond. Emphasize expected outcomes and explain how this project aligns with the company’s goals. Don’t shy away from communicating what these changes can mean on a big-picture scale. While you may receive some feedback, be direct: the project is proceeding.
Big action items: Finalize how your project will move forward, confirm responsibilities, and reset organizational expectations.
More?
I’m sure that there are recommendations that could be added to this list. What would you include? Have you ever rescued a project before? What’s your story? Let us know in the comments below!