Statistics indicate that 68% of all IT projects are bound to failure!

The PMI’s definition of a high-performing organisation, is a company that completes 80% or more projects on time, on budget, and meeting original goals. In a low-performing organization, only 60% or fewer projects hit the same marks.

Projects fail for all kinds of reasons:

• Stakeholders can change their objectives
• Key team members can leave for other companies
• Budgets can disappear
• Materials/Vendors can be delayed
• Priorities can go un-managed
• Running out of time
• …and others

In this post:

> How to prevent project failure (with some statistics)

> How to recover a failing project

How to prevent project failure

Prevention is the best cure, so what can you do to prevent projects from failing? Here is some statistics…

• Organisations that invest in proven project management practices waste 28 times less money because more of their strategic initiatives are completed successfully.
  Source: PMI’s Pulse of the Profession Survey, 2017.
• 77% of high-performing organizations have actively-engaged project sponsors, while only 44% of low-performing organizations do.
  Source: PMI’s Pulse of the Profession Survey, 2017.
• 46% of CIOs say that one of the main reasons IT projects fail is weak ownership.
  Source: The Harvey Nash/KPMG CIO Survey, 2017.
• 33% of IT projects fail because senior management doesn’t get involved and requirements/scope change mid-way through the project.
  Source: A Replicated Survey of IT Software Project Failures by Khaled El Emam and A. Güneş Koru, 2008.
• 78% of respondents feel that business is out of sync with project requirements and business stakeholders need to be more involved in the requirements process.
  Source: Doomed from the Start Industry Survey by Geneca, 2011.
• 45% of the managers surveyed say business objectives are unclear to them.
  Source: Doomed from the Start Industry Survey by Geneca, 2011.
• Companies that align their enterprise-wide PMO (project management office) to strategyhad 38% more projects meet original goals than those that did not. They also had 33% fewer projects deemed failures.
  Source: PMI’s Pulse of the Profession Survey, 2017.
• 40% of CIOs say that some of the main reasons IT projects fail is an overly optimistic approach and unclear objectives.
  Souce: The Harvey Nash/KPMG CIO Survey, 2017.
• Poor estimation during the planning phase continues to be the largest (32%) contributor to IT project failures.
  Source: PwC 15th Annual Global CEO Survey, 2012.
• Projects with effective communication are almost twice as likely to successfully deliver project scope and meet quality standards than projects without effective communication (68% vs 32% and 66% vs 33%, respectively.)
  Source: PwC 15th Annual Global CEO Survey, 2012.

How to recover a failing project

These statistics show that the odds are not in your favour. It is inevitable that you will have to deal with a failing project or two, some time within your career… You could turn the odds in your favour by taking action in recovering failing projects.

Here are four steps you can use that could 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

Step 1 – Big action items:

• Issue a “stop work” order
• Talk with everyone

Metrics/Indicators: The right project Management Information (MI) should give you the needed early warning signs when things are not going according to plan and heading to failure. These signs should drive you to action, as rescuing a failing a project is not a task to be sneezed at. It takes planning, and the process can consume weeks of key resources time and effort.

People: To help ease the pain of stopping a project, work with the team members’ managers (resource owners) to identify and assign interim work. As people are your most important asset, it is important to keep them productively engaged while you are evaluating and re-planning your project recovery.

Project artefacts/deliverables: Make sure all the project artefacts and deliverables are safely stored where it cannot be tampered with for the interim period.

Communicate: (clear, concise, and concrete) – Communicate to your team why their project is on hold. Spend the needed time to learn as much as you can about each team member’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. See blog posts “Management Communication Plan” and  “Effective Leadership Communication”

Project/Delivery Manager (You):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.

Step 2: Why your project is failing – Root causes

Step 2 – Big action items:

• Establish allowable solutions for project rescue (including project termination)
• Identify root causes of the problem
• Identify risks to project continuation

Determine the root causes: Most times the cause of project problems is not immediately obvious. Even the best project managers — those with excellent project plans, appropriate budgets, and fantastic scope control — also struggle, on occasion, with project failure.

You’ll only get to the bottom of it by doing a Route Cause Analysis (RCA) and the “5 Why’s” technique can help with that. See “The 5 Whys for route cause analysis”

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 softwareor methodology, their unclear objectives or their stakeholders’ lack of involvement. All of these problems are so generic that they don’t provide enough insight to create real solutions.

Apply the “5 Whys” and be specific when answering these questions… i.e.

• Why are objectives unclear?
• Why aren’t users getting involved?
• Why are the estimates wrong?

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 – the most common causes of project failure.

• Complexity
• External
• Financial
• Operational
• Organizational
• Schedule
• Technology

Risk Assessment:What are the risks when trying to salvage the project? Are those risks worth it? Is the project salvageable? Answer these questions before moving on.

Step 3: War Room

Step 3 – Big action items:

• Set up the war room
• Re-engage stakeholders
• Create a tentative plan to move forward

Okay, General!

Assemble the 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 focussed to figure out what to do with your project.

The “war room” will be intense – all members need to be prepared and the right mindset  of problem solving!

The decision-making process could take two hours or several days. All key decision makers must be present. As this is not always possible some executives may prefer to be called in as the meeting is nearing its end, where team members can present prepared options.

To get the most out of the workshop, conduct the meeting face to face (take the meeting offline). Try to limit the meeting to ten people, including the most important stakeholders (like the sponsors), project manager, senior team members including technical representative to give insight to plan feasibility.

The war room is serious business –  prepare for it. Create an agenda to go over findings, from quantitative reporting to team member interviews. Encourage pre-war-room collaboration (covering the outcomes of steps 1 and 2) toward the ideal shared result.

When you start the war room meeting, all project material should be readily available. That’s your fact base driving factual data driven assumptions and decisions.

Using the facts, the purpose of the war room, in essence, is to answer 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 drivers (i.e. business need/value, budget, schedule, scope, or quality). Ideally, there should only be one driver that controls the outcome of the project – this is usually the business need for the project’s deliverables.

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.

Least case scenario: Clearly articulate the primary goal. Then identify 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.

Project termination considerations: If the primary goal cannot be achieved, prepare a recommendation to terminate the project… but not without scrutiny. Several variables must be considered and thoroughly addressed in the war room.

• Consider trade-offs that could make the worst-case scenario more possible than originally thought.
• 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.

Alternatives: Should the least-case scenario makes sense, explore more alternatives. Are there alternative options that can deliver more of the project’s objectives, and consider how adding those solutions to your plan can create additional potential scenarios — positive or negative.

New project charter: Write down the main points of your plan in a revised project charter.

Replacement project option: 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 the decision is to completely start over, abandon project rescue altogether. Justify the replacement project on its own merit (a new scope, budget, resource plan, etc.)

Step 4: Set your project in motion

Step 4 – Big action items:

• Finalise how your project will move forward
• Confirm responsibilities
• Reset organizational expectations.

Following your war room meeting, your next steps are all about follow-up. The real project rescue starts here and is the most challenging part of project rescue.

Re-engage stakeholders around the contents of the new project plan and complete the detail with precise commitments for each team member. Plans should be finalised within two days.

Be careful as hesitation and procrastination can limit team commitment and lower morale. You’re the general; get your troops ready to re-engage and to stay committed and focussed!

Reconfirm all project metrics: Validate all project aspects especially resources, as people has been allocation to productive work while you were reworking your rescue plan.

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.

Make sure all communication is clear. Confirm that stakeholders accept their new responsibilities to the project.