Project failure: troubleshooting guide

In this post we’re going to walk through why project failure occurs and how to troubleshoot it. It would be nice to think that projects always succeed and deliver good quality output, however we all know that the reality is very different. Unrealistic expectations, inadequate resource and poor control are just a few things that can lead to failure. However, it’s not all doom and gloom… taking time to troubleshoot a project that isn’t going as well as expected can save the day. It’s an opportunity to make necessary changes, energise the team and get the project back on track.

Today’s world is pressurised, fast-paced and unforgiving. Delivering projects, regardless of whether they are small or large, requires a competent project manager with the experience to steer the ship when the going gets tough. Aside from the obvious qualifications, we tenacity and courage are characteristics that a project manager often needs to be successful.

The top 12

When Easyprojecthub troubleshoot a project failure as well as checking there is a good project manager in place we review 12 aspects of the project:

  1. Are there any known issues?
  2. Are the project drivers clear?
  3. Is the right team in place?
  4. Are there clear project objectives?
  5. Is the scope clearly defined?
  6. Is there a change control process in place?
  7. Is there a budget and is it under control?
  8. Is there a project plan?
  9. Are the risks, assumptions, issues and dependencies being managed?
  10. Has everyone agreed what success looks like?
  11. Quality: are objectives, requirements and success criteria quantifiable and measurable?
  12. Is effective communication happening?

We’ve covered each of these in detail in the rest of the post.

#1 Are there any known issues?

Firstly it’s good to ask if there are any known issues. Asking the stakeholders, sponsor, project manager and team what the issues are will give you a good feel for where the project failure is occuring. At the very least it will give you an indication of team morale and perception of the project from the stakeholder point of view, which are good to take into account as you review the other aspects of the project.

It might even be that the project can be turned around just by understanding everyone’s issues and frustrations and taking action to rectify them.

Project failure help

#2 Are the project drivers clear?

The project drivers identify the need for the project. Without a need there isn’t a project. You can also think of this as the project background. Understanding and being clear about the project drivers, or need for the project, ensures that the project is valid and has focus.

The project could have come about for any number or reasons. When troubleshooting a project we would ask what the project drivers or the need for the project is, and whether the drivers have been signed off by all stakeholders.

If there are not not clear project drivers that are agreed across all stakeholders we can already see that there is an issue. Without understanding the problem the organisation is trying to solve it is not possible to adequately plan a project and project failure is a likelihood.

Examples of project drivers could be

  • Problems with the way things are working e.g. existing IT systems don’t work / business processes are not efficient / there is too much data and it is not being managed well
  • Something new that means the current way of working needs to change e.g. expanding business that carries out new functions / change in personnel / rationalisation of business
  • Regulatory or other external changes being imposed on your business

#3 Is the right team in place?

Having the right people on the team will ultimately make the difference between project success and project failure.

As we mentioned in the introduction, the project manager is often the lynch pin of the project.

In addition there are some other critical roles that help a project run smoothly:

  • Project sponsor (overall accountability for the project, responsible for the business case)
  • Stakeholders (interested parties)

There will then be any number of other roles specific to the project that are equally essential, such as:

  • Business analyst (interfaces between the business and project)
  • Technical lead (responsible for technical tasks)
  • Third party lead (if you have a third party organisation involved)
  • Marketing
  • Communications
  • Business representatives
  • End users

If a project is failing it’s useful to ask the following questions:

  • Is the team made up of the right people?
  • Are all members of the team qualified and experienced enough to do their role?
  • Are any team members overloaded?
  • Is it clear who the project is being delivered for?
  • Are all the stakeholders (interested and impacted parties) identified?
  • Is it clear who needs to sign off budget, requirements and the final product?
  • Have the right people been consulted about the project? For example, are there SMEs who need to input, or requirements from multiple business functions that need to be included?

If you can’t answer all of these questions then it is likely the team is not set up for success.

In addition it is worth considering whether there are known conflicts on the team that need to be addressed and whether the team is motivated in general.

Conflict often occurs where the project is being delivered for multiple business functions or when people do not know what they are responsible for. Being clear on who is responsible for, consulted and informed about each area of the project reduces the likelihood of conflict. You can read our post on RACI for more information on this.

If it hasn’t already been done, putting together a table or organisation chart that defines who is involved and what their role in the project is a good idea.


#4 Are there clear project objectives?

It might be that the project drivers have been defined, but not the project objectives.

The project objectives are the main outputs that are required from the project. A project needs to have specific and realistic objectives. If the objectives are not clearly defined then a project is likely to fail.

As well as ensuring that there are specific and realistic objectives in place, we would want to understand whether they have been communicated and signed-off by all the relevant stakeholders.

#5 Is the scope clearly defined?

It is important to be specific about what is in-scope and out-of-scope.

The main scope is to deliver the objectives of the project, however being more specific about scope will ensure everyone is clear on what is included in the project and, equally importantly, what is not being covered.

Having this information clearly documented and communicated manages expectations and reduces opportunity for conflict, particularly where there are multiple stakeholders.

Examples of in / out-of-scope situations might be:

  • Business split into regions geographically – are all of these in-scope?
  • Multiple functions in the business (HR, Finance, Manufacturing, IT etc) – are all of these in-scope?
  • Specific business processes that are in-scope, or closely linked processes that are not being worked on and that are out-of-scope.
  • IT systems – which ones are affected and which aren’t being changed?

You can go into more detail with scope if relevant.

A common reason for project failure is scope-creep. Defining the scope up front and baselining the project against this scope is critical. It is then important to manage the scope for the duration of the project. This is normally done via a change control process – see the next point.

If the scope is not clearly defined, this could be contributing to the failure of the project.

#6 Is there change control process in place?

Even the smallest projects can suffer from scope creep. Lack of change control and scope creep on a project is a significant reason for project failure.

If there is no process in place to control changes it is likely that the project is suffering from scope creep.

Changes during the course of a project are inevitable for two main reasons:

  • It is not possible to understand absolutely everything. There will be elements that were not planned for or don’t work as expected
  • As the project moves through requirements gathering to design and build the stakeholders gain a better understanding of what is being delivered. This can often lead to changes in requirements.

A change control process simply ensures that changes are logged, impact assessed against the project baseline to check whether they will increase time, cost or quality. All stakeholders and the sponsor will need to approve any changes. The project may need to be re-baselined.

#7 Is there a budget and is it under control?

You need to check the following:

  • Is there a signed off budget?
  • Is the project being tracked against the budget? I.e. the actual costs being matched against projected costs and any variances accounted for and signed off
  • Is the budget realistic?

The project may not be progressing due to lack of budget or disagreement over budget.

#8 Is there a project plan?

A project plan should be in place and be actively managed by the project manager. The plan will include:

  • all the tasks for delivery. The level of tasks recorded in the plan can be variable. It is generally down to the project manager and how they work.
  • resources allocated to tasks
  • dependencies between tasks

If there is no plan it is a good indication that there is no control on the project and project failure is likely.

In addition to a gantt chart or task based plan there should also be a milestone plan in place i.e. a list of all the major deliverables. Stakeholders need to understand progress against a milestone plan. It could be that the work is being done but not communicated to stakeholders.

#9 Are the risks, assumptions, issues and dependencies being managed?


The risks, assumptions, issues and dependencies, or RAIDs need actively managing throughout the project.

It might be that there were known risks at the start of the project, such as technology that the organisation is reliant on that might not work as expected. There may also have been some assumptions made or dependencies identified, such as other parts of the business being required to supply resource to the project team.

In addition, further RAIDs are likely to arise during the course of the project.

Ideally there will be a RAID log in place that is being reviewed weekly.

Unmanaged RAIDs can easily cause a project to fail.

Examples might be:

  • Dependency on supplier to deliver new equipment on time. A delay to this may impact other tasks and the overall timeline.
  • Risk that specialist (SME) resource may not be available in time: this risk may be realised which will delay the project
  • Assumption that specific IT environments will be available e.g. to test new software may prove to be incorrect adding cost and time.

Checking that there is a RAID log in place and the RAIDs are being actively managed and updated will rule out this as a reason for project failure.

#10 Has everyone agreed what success looks like?

If the sponsor, stakeholders and project team all understand what success looks like they will all know when it has been achieved. It may sound trivial, however agreeing success criteria will reduce opportunity for conflict and will provide everyone with a clear view on when the end has been reached. If the project appears to be failing because of conflicts on what is being delivered ensuring the scope, objectives and success criteria are all in place will help to ease the conflict.

Example success criteria may be:

  • Delivering the project within budget
  • Streamlining existing processes or standardising the way things are done
  • Getting rid of old and costly systems
  • Bringing the organisation up-to-date
  • Reducing headcount or increasing productivity

The next point discusses having quantifiable and measurable success criteria. This is really important to remember.

#11 Quality: are objectives, requirements and success criteria quantifiable and measurable?

Objectives, requirements and success criteria should be specific, realistic and measurable. This means that it should be possible to measure whether a project has achieved what it set out to do. This is effectively the quality criteria.

For example, there may be a requirement to build a new intranet that has a blue background. The project team builds the intranet in bright blue. Two stakeholders come back and say ‘that’s not what we wanted’. One states that they wanted it to be dark blue and the other pale blue.

A measurable requirement would be to get the stakeholders to agree on the exact shade of blue and to quote the hex number in the requirement.

Success criteria can be measured in terms of how much, how many and by when, for example increasing sales of Product A by 10% in the first quarter of 2020.

You may find that project failure is occurring because the quality criteria have not been defined and stakeholders don’t believe they are getting what they signed up for.

#12 Is effective communication happening?

Communication is king on any project. Without effective communication it is not possible to deliver a project successfully.

In a project that is failing you should ask the following questions:

  • Are there regular team meetings to ensure that the team always knows what they are expected to do? At Easyprojecthub we like the ‘scrum’ type approach where you have a daily 15 minute meeting. You can read our blog post on making a daily team meeting count
  • Are there regular update meetings with, or reports to the sponsor and stakeholders? At Easyprojecthub we like to send out a short weekly status report to the sponsor and stakeholders to ensure they are up-to-date with progress and risks.
  • Are the end users, or people impacted being communicated to early enough? Often end users need training or information on the changes being made by the project. The project may run really smoothly but if those impacted have not had clear communication they will think the project is a shambles.
  • Is the communication clear, concise, timely, directed at the right people and appropriate?

It may be that the lack of, or in some cases excess of communication is causing the project to fail or affecting the perception of the stakeholders.

A communication plan or schedule can be useful to identify the communications required, particularly if there are many stakeholders or impacted parties.

In summary

Once you’ve asked and answered all the questions listed above you will have a clear view on why the project is failing.

You can take appropriate steps to rectify the issues, which may involve re-stating the scope of the project, getting it signed off and re-planning. Whilst it can be difficult to have a conversation about project failure it should also be used as an opportunity to rebuild relationships and confidence in the project. Remember, identifying project failure and dealing with it is a positive and brave action. 

We’d love to hear about your project turnarounds in the comments below. You can find me personally on LinkedIn here.

Thanks for reading!

What is ROI?

October 11th, 2016|0 Comments

What is ROI? ROI stands for return on investment. In this blog post we’ll define ROI, explain when it’s useful, how it’s calculated and [...]

  • 7cs of communication

7cs of communication (and more)

September 4th, 2016|0 Comments

7cs of communication (and more) Effective communication is essential in every job and every organisation, and is particularly critical when delivering projects or business [...]

  • Change management

Effective change management – key to success

July 4th, 2016|0 Comments

Effective change management - key to success | In today’s fast paced world businesses are constantly adapting and reacting in order to [...]

  • Agile vs Waterfall

Agile vs Waterfall or the best of both?

June 6th, 2016|0 Comments

Agile vs Waterfall There is much debate in project management circles around Agile vs Waterfall. Some people sit firmly in one camp and are [...]