A project failure can be considered as project that has not delivered its required expectations. In case the project can meet both the business ambitions and all stakeholder requirements, then it can be considered as a success.
However, in reality, expectations of the customers and stakeholders keep on changing constantly, inhibiting the project team to deal with issues and to achieve project goals. But the question is why do project fail? Project failure occurs if the projects are late, crossed their budget, does not deliver the business value as expected or deliver the wrong product.
A failing project is one with severe slippage in schedule, budget, or quality. The reasons for project failure refer to the lack of presence of success factors for the project. We refer hereunder to the top reasons for the project failure to answer the question why a project fails. In addition, the Catalogue of Catastrophe provides a database of samples that can serve as a platform for discussing the causes of project failure together with an official listing of 8 categories for common project failures. Afterwards we deep-dive in the different layers of project failure and as conclusion we elaborate on how to eliminate or overcome project failure.
The main project failures can be listed as follows:
1. No or Poor Project Risk Management
Poor risk and issue management are often the most important reason for project failure. By nature, project managers are project solvers and interpret small risks as easy to solve and therefore have the reaction to report/communicate when it is already too late. The best and only way to avoid project failure is prevention; the sooner you identify a problem, the bigger the change of project success will be. Therefore, monitoring and reporting on project health is critical to keeping everything on track, this way the business can course-correct and help the project become successful by adjusting components like budget, resources, or delivery expectations.
Rescue at hand:
A common way to identify or visualise project risks/issues is to set-up a risk or issue log or to make status clear in 1 view and use a Score card. Your role as a project manager is to get the right information into the right hands, at the right time (the sooner the better), in order to minimize the impact. The Scorecard leverages a traffic light system of green/yellow/red colours to help quickly determine and report on the status or health of a project. It’s a simple and logical framework: Green: On track, business as usual; all good. Yellow: Potential issues, and with corrective actions it can go back to green. Red: Serious issues and the project is at risk of failure; this is the project on fire, reactive phase. On the surface one would assume the green is where you want to be. Certainly, it is an indication that things are on track. However, if all aspects of your project are in all in green most of the time, you are probably not monitoring your project in enough detail. In this framework, yellow means something requires attention. It means you have time to make a change. It means you are still in control and have the time to tackle risks/issues proactively.
2. Ineffective Communication
Project managers should develop a good communication approach: ranging from communication plans, project status reports to regular meet-ups to keep the project stakeholders up-to-date on the project performance. The way in which you communicate will depend on your target audience. If you do not communicate enough or forget impacted stakeholders, you will lose sight of dependencies and the project will no longer evolve in a coordinated way.
Rescue at hand:
In order to keep project stakeholders involved and up-to-date on the progress of your project, the project status report provides excellent insights at a glance as it should be no longer than 1 page, send out on a weekly or bi-weekly frequency, provide a project status summarising what is on track, what may have deviated from the project plan and identify the corrective actions for areas that are off track.
3. Inadequate Project Planning
Project planning is an important part of project management and it is the responsibility of the project manager to set-up a proper plan for the project. Project planning is generally used to organize distinct parts of a project including workload, project plan, management of team(s) etc. You must have a clear vision of what you are going to do and know how to execute tasks to reach the project goal. But if the project is not planned properly then it may fail or doesn’t meet all the expectations of stakeholders and customers.
Rescue at hand:
In an Agile context, based on my professional experience, it is important to take into account the following lessons learnt:
Plan accurately plan in detail only for nearby tasks: Only plan in detail for the next 2 iterations, forecasting for next weeks, not for several months ahead.
Active involvement of people doing the work in scheduling & estimations: Project resources will be motivated to get it right, they have skills to understand the dependencies, and they need to accept the schedule, at the same time they have already done the work, so they can provide correct estimates.
Organize the project into short iterations. By working in short iterations, 1 to 4 weeks is common, and by delivering finalised user stories each iteration you provide concrete evidence that your project team is progressing.
Take a requirement-based approach. Schedule the development of requirements (user stories, features, use cases, ...) into iterations as the line items, not tasks such as design, test. For example, futures will group user stories on the same functionality, and user stories can be divided in tasks to follow up in the online JIRA board.
Remember to include training. As soon as a new tool is implemented, do not forget to include the necessary training for the future users.
Agile Metrics tips:
1. Velocity: a measure to how much work your team can tackle during a sprint; it is calculated in story points for all completed user stories.
2. Burn Down Chart: run chart of the outstanding work represented in the backlog versus the time left: it is easy to predict when all work will be finished.
4. Shortage of Resources/ Requirements
The quantity of resources needed by a project depends on the size and scope of the project. Sometimes, the project is blocked due to the shortage of resources and necessary requirements. For example, if a project requires a skilled Java programmer and the candidate appointed for the project does not have that skill then the project cannot continue until a necessary resource is provided.
When we talk about project resources, we are referring to all the resources that are required for a project, including:
People—managing ‘people’ or team management focuses on team cooperation, but also about considers the skillsets your project requires, the availability of project members and their respective workloads.
Funding—managing a budget: having a realistic idea of how much the project will cost, not exceeding that budget.
Material Assets— ‘everything else’ in projects ranging from software and hardware to equipment, machinery or temporary property.
Assuring these resources are entwined is the most difficult part in which resource allocation plays an important role comprising delivering services that match what customers wants at the lowest possible cost, having the exact number of people on hand to complete a project; or perfectly aligning the reality of project costs with expectations.
Rescue at hand:
Mastering resource allocation in project management can be modelled via famous tools such as Tempus Resource (a sophisticated resource management tool that offers real-time visibility over your projects and people, so you can plan for whatever comes your way), or from ProSymmetry, which offers modern and powerful resource allocation with modelling capabilities and what-if scenarios. Taking a single project or an entire project portfolio, users can create a resource allocation model to test the effects of changing or modifying their projects in real-time, which can help maximize their resource forecasting. This helps both project and resource managers to approach resource allocation in the most efficient and effective way possible, maximizing their resource capacity and getting their project to completion every time and to time.
5. No Proper User Engagement
Failure to user engagement in the project leads to an improper end result and non-aligned user expectations.
Rescue at hand:
Include the customer at the beginning of the project and continually involve the customer as things change so that the required adjustments can be made together. It has been observed that successful projects occur when end users (customers) and the project members work as teams in the same cubicle, although this is not always possible. Projects are less likely to fail if there are informed customers giving meaningful input during every phase of requirements elicitation, product description and implementation. The customer needs to be asking, “how are the project result used over time and what do I get out of the results?
6. Unrealistic Customer Expectations
Unrealistic deadline and expectations will drag projects down the drain. So, take into account all the factors and constraints involved that might adversely affect your project and then set a deadline.
Rescue at hand:
Foresee a buffer that gives you the liberty of completing the project without rushing through it. Having a buffer not only reduces the workload of your team member but also let them focus on each task in a better way.
In addition, the Catalogue of Catastrophe provides a database of samples that can be used as a platform for discussing the causes of project failure. The use of publicly available information helps to eliminate the personal aspects of the discussion and opens the door for participant interactions.
Classes of project failure
Classes of project failure aims at categorizing causes for project failure into 8 principal categories. The below indicated list summarizes the meaning of each category and corresponding examples:
Market and strategy failures – Projects should only be launched, if there is a real interest in what your project wants to set out. Example: Beauty brand Dove created “Real Beauty Bottles” in a limited-edition run of six different body wash bottles to illustrate the power of body diversity–ranging from curvy to tall, short to slim. However, Dove made a controversial move to reshape its shampoo bottles to reflect different body types. This promotion was comparing women’s figures to largely shapeless, abstract soap bottles eventually sent the wrong message and was met with both joking and sincere concern on platforms like Twitter.
Organizational and planning failures – On one hand if the organization is insufficient the project team can quickly lose control. On the other hand, if the controls put in place are more than are needed the project can be slowed down by unnecessary inefficiencies. Example: The story of Sony Betamax cassette is a good example of bad marketing planning because while it was innovative and hit the market before its competition did, other products proved to be cheaper and better.
Leadership and governance failures – If there is a missing project governance set-up, there will be no management of dependencies and in the end program management can lose control. Example: Silo based organisation: Projects that are organised in silos without the proper alignment governance bodies such as set-up of SCRUMs for different sub-tracks in a program without having one centralised SCRUMs of SCRUMs meeting.
Underestimation and analysis failures – The project team should analyse the complete project to understand the complexities involved. Those complexities need to be understood before commitments related to timing and budget are confirmed. If commitments are given before the full complexity has been clarified a project can easily end up making unrealistic commitments that ultimately create a pressurized environment in which the project can only fail. Example: Decommissioning Projects: these projects are often underestimated as they are categorised as basic continuous improvement and have repetitive project planning, nevertheless, also for these projects a proper estimation and planning should be made.
Quality failures – If quality checks are not included in the test planning, serious flaws can escape the project and cause issues once the deliverables have been deployed. Example: Launch of Ford Pinto: In response to competition from Japanese imports, Ford released the Pinto in 1971 – a populist car that tried to persuade consumers with its cheap price tag, however, lawsuits emerged for an alleged structural design fault. The fuel tank was understood to be in close proximity to the rear bumper and rear axle, meaning that rear-end collisions would elevate the risk of fires.
Risk failures –Without anticipation or mitigation of project risks, not only the project, but the organisation as whole can be derailed, but even the organization as a whole. Example: Merger of Fortis and ABN AMRO: This merger did not foresee a clear risk plan and derailed the complete company acquisition, hence a rollback, and selection of a different take over scenario.
Skills, knowledge and competency failures – Projects will suffer from lower productivity and higher risk of errors, if the necessary skills and competencies are lacking. Example: System implementation projects require specific technical skills to deliver expected quality.
Engagement, teamwork and communications failures – Poor stakeholder management, uneffective communication and lack of engagement between projects team members will lead to working in silos without smooth communication flows. Example: Large programs without necessary alignment bodies/governance: In order to avoid double work or loose the achievement of common program goals, a clear governance on alignment/huddles or standup meetings has to be organised.
How to Eliminate Project Failure?
The top causes of the project failure specify the importance of a proper planning to reach the project goals. The successive operation of the project tasks and the resource management also helps project managers to deliver a successful project. Efficient communication helps to build a better project flow and thus leads to the success of the project. Hence, by eliminating the above mentioned main project failures, your project is more likely to become successful.
Layers in project failure:
Understanding why projects fail will entail multiple answers with different layers. For example, project underestimation is not just to be blamed on bad estimate as cause of the failure, but a broader context or contributing layers should be looked into. To explain the different layers in project failure, the diagram is divided into different layers; the upper layer comprises symptoms of project failure such budget overruns, the middle layer consists the real causes of failure divided into two general categories: with firstly “Trigger events” (specific individual actions, mistakes leading or contributing to project failure) and secondly “Behavioural patterns” (broader governance or structural problems in project approach or management). At the same time, the failure is reflecting a dysfunctional environment as elemental or deepest layer of the failure.
The decision-making layer
These contributing factors are themselves a reflection of deeper-seated issues relating to the way decisions are made in the project or the organization as a whole. Projects are not only to be seen in terms of the activities to be performed, but as networks of interrelated decisions (See Figure The decision-making layer). Decisions are the building blocks of progress in a project and the project outcomes usually depend on the effectiveness of the decisions made.
To make this more concrete, the symptom underestimation is not only to be explained via a project resource making a bad estimate, or as an isolated action or decision, but influenced by decisions – not investing in proper training - made either directly or indirectly by the extended team such as stakeholders and sponsor or those who control the environment in which the project is operating.
Project Turnaround Steps
Determine the root cause. It can often be difficult to determine the exact root cause. Interviews with the team and a careful analysis of the situation are required to help you identify the real problem in order to successfully move forward. If you don’t determine where the issue stems from, you are likely to continue experiencing setbacks.
Reaffirm the goals of the project. A project should have been clearly defined and documented at the start of the project, but this is not always the case. Or perhaps the project requires new objectives and deliverables be agreed upon. Either way, now is the time to rectify that problem. Work with the client and team to clarify and document the goals, and make sure everyone re-commits to these goals.
Get buy-in from stakeholders on the solutions. When projects are off-track it is a very important moment to stay engaged with the stakeholders and clients. Keep them informed of the issue, propose new solutions, and get buy in before moving forward. You must maintain trust in your ability to deliver, particularly when troubleshooting.
Motivate the team. During project derailing it is hard to stay energized and excited about work, however you can use project setbacks as an opportunity to motivate the team and strengthen relationships between project team and clients. Do not allow the blame game to damage trust and relationships, and try to generate accountability and buy-in, help each team member understand how their role is critical for the success of the project.
Project success is not fixed, consequently, if a project succeeds, there are also some chances of its failure. Accordingly, the above-mentioned list of the causes of the project failure will enable a project manager to stabilize/maintain his/her project. By understanding all the factors that may lead to project failure, the project manager, and his/her team can get prepared to tackle the problems that may arise. It will, in turn, minimize the chances of project failure and maximize the possibility of the success of the project.
About the author
Sandy Everaerts, has 20 years of experience, and worked for leading companies in the Banking & Insurance sector. She has a background in both Business and IT as PMO, project manager & SCRUM Master. 4-lingual NL/ENG/FR/GER with a Master’s degree, relevant project management certifications Sandy joined Initio in 2017 as Senior Manager in charge of the Business Line Governance & Projects.