Why do 70% of projects fail to deliver?

This article below is the consolidation of a three part series we wrote in 2016 with Piematrix CEO, Paul Dandurand. I felt we needed to consolidate this for a single article and expand a little on the last 12 months of real client experiences that we can now share.

In late 2016, we hosted an ITMPI webinar titled "70% OF YOUR PROJETS ARE LIKELY TO FAIL" to spearhead the conversation in our combined communities around what we keep doing wrong. In this article, we would like to engage you in the discussion and ask you how your organization does with project success versus failure rates.

Before answering, let's consider our simplified definition of project success and failure.

Success – A project delivers expected business value such as measurable improvement to revenue, profits or net income, automation to improve productivity, new product release, reduce inventory costs or some other targeted outcome. 

Failure – A project that did not meet or exceed expected business value.

Our view of project success is relatively straightforward. If you do what you say you're going to do, then you should be on-time and on-budget. If you deliver what you say you're going to deliver, then you should achieve or exceed the business value promised. 

Now we'll be blunt: Executives don't care about PowerPoints, Excel spreadsheets, Gantt charts, task lists, stoplight reports, or SharePoint files. Executives care only about the positive financial impact of the project. If that is achieved, the company’s bottom line should improve. It doesn't matter if the project is an IT project, a new building, a new product, an inventory rationalization effort, or any other effort. The reason executives seem to care about the other documents is because projects rarely succeed, so leaders feel they need to engage to help improve the chance of project success.


The Standish Group 2015 CHAOS Report* showed that out of all 50,000 projects in the study, 71% failed to meet these three criteria: on time, on budget, and with satisfactory results. The problem is even higher for big projects. Medium-sized projects failed at 91% and large projects at 94%. That's scary since PwC reported** that capital projects and infrastructure spending between 2014 and 2020 could reach $29 trillion! Does this mean that $27 trillion is at some risk? That's crazy! Are we doing anything about this? This 71% failure rate reflects the expected outcome of all project including small, medium, and large.

Note: The Chaos Report has three criteria for project states: Success, Challenged, and Fail. Our view is that in the business world, you either succeed or you fail. If you're challenged, you have yet to succeed. 

The sad part of this story is that we are NOT getting better!

  • 2013 - 31% of projects successful
  • 2014 - 28% of projects successful
  • 2015 - 29% of projects successful

So, where does your organization fit based on the above success definition? Do you find your success rate to be similar to the averages above? Do you see any improvement trends? What is your company doing differently to improve project success?



An article in InfoQ explains the Standish Group CHAOS survey results. It shows that project failures come from the following five (5) areas:

  • Lack of executive support. Financial and emotional backing is missing.
  • Missing emotional maturity. Behaviors of how people work together is weak.
  • Poor user involvement. Decision-making and information-gathering process is not there.
  • No optimization. Structured means of improving business effectiveness is not executed.
  • Not enough skilled staff. Highly proficient people are promoted or retire.

If we look at where most of the effort has been with project management training and technology enablement over the past 30 years, we should agree that it's around:

  • Task management
  • Metrics
  • Resource allocation
  • Time and budget management

After reviewing the Standish Group’s findings, we asked ourselves if previous training and technology enablement efforts have been the right ones to focus on given hindsight. Are we missing something more fundamental? Are we skipping the real root cause and focusing only on the symptoms? 

The high failure rate tells us our past understanding and approaches to improvements are not valid and hence, not working. We believe there are a few important reasons:

  • Checking off a task as 'done' doesn't mean it was done right. 
  • Knowing what happened doesn't provide insight on what to do to make the outcome better the next time. 
  • Knowing who's available and doing the work doesn't help us understand if they're doing the work right. 
  • Getting it done on time and on budget doesn't mean it created real business value.  

Our approach spun the research on its head and asked two different questions.

  1. What is common for all the successful projects? 
  2. What is the pattern of success? 

The Standish Group highlighted what they concluded; however, we boiled it down to a simple common thread for success ---- people experience.


A highly experienced project manager...

  • Knows how to gain and maintain executive support;
  • Has a high level of emotional maturity;
  • Actively engages user involvement with sharing ideas, helping others, and asking for help;
  • Understands the importance of repeatable processes and frameworks;
  • Knows how to optimize the project and its future process with lessons learned;
  • Maintains the structure given the dynamics of the company’s internal and external influences; and,
  • People are pattern learning organisms and can assert patterns of positive outcomes, or negative outcomes, from complex non-linear efforts*** with enough experience.

We found that as good project managers tend to move on, with job promotions, different companies, or retirement, they're replaced with less experienced project leads. These new project leads tend to deal with trial-by-fire or, figuring it out on their own. In addition, the problem is increased by cultures that push only deadlines or budgets, leaving little room for cooperation, idea sharing, and problem-solving. Also, this issue is compounded by the fact that the number of complex projects are increasing and more people are working remotely, further complicating the communications needed for successful execution of complex non-linear projects***.


Given our hypothesis that people experience leads to the project success or failure, we thought about the underlying reasons that might be the case of the 70% project failure rate.

Missing the Learning Process. The process of project execution is missing the “how-to” content. This lack of real-time information prevents the novice project manager from learning how to succeed from previous lessons learned. It also makes it harder with real-time team collaboration and cooperation since there's no foundation to build upon and discuss when working on important tasks. If the project execution process is limited to just task labels, the only thing to do is to check it 'done' or 'not'. There's no opportunity to learn about the right or better ways to get it done well. There's little chance for team idea sharing.

Inconsistency of Execution. We applaud PMI and others for their efforts in creating standard project management guidelines (i.e., PMBOK) and training, but we have witnessed that their approach is often a one-and-done view of the world. Business projects come in flavors. Whether a monolithic or a light agile approach, there's a lack of good execution consistency for each specific need. Each company has a different culture and they require different techniques and levels of engagement. Also, each project type requires different framework combinations that could never be covered by standard project management guidelines, such as PMBOK. These nuances are not baked into processes that are ready to execute and re-execute as flexible frameworks made specifically for the organization. As a result, execution becomes as varied as the project managers' skills and experiences and many of these projects rely on the remake of a list of tasks from other projects regardless of success. Consider the varying quality and cost impacts of this approach for manufacturing a product - task lists to build something without a process in mind. Why should building business value, i.e., executing a project, be any different from building a product?

Lack of Continuous Improvement. If “how-to” process content and practices are not well documented, ongoing improvement is impossible. If the project process is not designed with a learning process in mind, and it's not established as frameworks for constancy, then what are we improving? How many times have we sat in a meeting after discussing lessons learned from serious issues and risks and then have no place to really document the improvements we need to make for the future? How will the future project leaders and project managers get updated on the better ways to get the work done? How will they continue to learn?

Poor Scalability. Without a repeatable and improving library of frameworks, processes, and best practices, scaling is not possible. As your numbers of projects grow and as you add more junior project managers, it will be impossible to scale the knowledge that inexperienced people will need to succeed. 

No Smart Flexibility. Since project managers cannot access project execution process options for best-case needs, they miss opportunities to pick and choose the right framework or guideline to help with their immediate objectives. They are forced to stick with a top-down list of tasks that someone once threw into a folder and named it “Project Management Template”.



In your work history, you may have heard or talked about the three pillars of people, process, and technology. Large consulting firms, such as Accenture, IBM, PwC, KPMG, Deloitte and Ernst & Young have been consulting with strategies around these three pillars for decades.

We outlined five failures pointed above from the Standish Group CHAOS survey results. This includes lack of executive support, missing emotional maturity, poor user involvement, no optimization, and not enough skilled staff. 

We then identified that people experience was really a problem in all of these five failure points. Below we highlight a few ideas on a solution using people, process, and technology as cornerstones to a repeatable approach to program and project management and continuous improvement of success over time.


There are two issues with missing the learning process. First, many organizations miss the "how-to" content needed from lessons learned. If you don't integrate your lessons learned into your process, then your people will continue to struggle solving the same issues. Second, is the lack of a framework library that allow project leads and managers to pick and choose the best process for their specific projects or programs. Dr. Harold Kerzner calls this "cafeteria-style" project management. So, a lack of continuous improvement (not leveraging lessons learned) and no guiding frameworks to start from immediately inhibit a managers’ ability to jump start successful projects from the beginning. With this in mind, managers need to think about the future projects when working on today’s projects.

  1. Capture lessons learned while your projects are in progress.
  2. Turn those lessons learned into project process change as soon as you can.
  3. Build and document multiple light versions of your project execution processes for different project types. These become your project frameworks.
  4. Make your frameworks readily available to all project leads and managers to easily choose from.

A process solution is a people solution, since your processes will not execute themselves unless we're talking about automated workflow systems like ERP processing. We're not. We're talking about manual processes where your knowledge workers make the process happen.


In Part 2 we introduce a cultural challenge reflected in the lack of sharing good people experience. To ensure the process solution gets well implemented, you need a culture that proactively engages people. Many would say you need to hire the right person with the right experience, but that may not always work. Or you may just have to "play the hand you're dealt", and make the best of the people you have. 

Here are some key steps to get started on a proactive culture:

  1. Encourage people to ask for help when they feel they may need it or might want a second eye or opinion. 
  2. Reward those who help others when they see someone who needs help. 
  3. Get everyone to express new ideas no matter how simple or silly they may seem.
  4. Recognize and celebrate those who take the initiative to be more engaged with asking, helping, and innovating. 


There are three foundational problems with traditional tools used for project execution. First, they are not processed based. They are in fact list-based by design and follow the same pattern popularized by Microsoft Project.

Secondly, leveraging the more advanced features requires advanced technical skills and exponential amounts of data thus, making these tools very expensive and complex. The chase to the top is to get on Gartner's Magic Quadrant, which mainly rewards heavy feature sets, rather than simplicity of execution by all team members.

Third, since these tools focus on lists, rather than process views, they are not made for real-time process improvement. They are not designed for a-la-cart framework libraries that can be actively updated from lessons learned in real time. These failure points are critical if you are trying to advance the level of people experience.

Metrics are good, but traditional tools are not designed to change processes based on metric feedback. Feedback loops from lessons learned get trapped with the experienced person and are hard to store and share in most tools. Look for tools designed for driving consistency, efficiency, and repeatability while sharing content that flexes in real time.

Here are some ideas on what kinds of technology enablers to look for:

  1. Process based by design, not task list based. This is the only way to help junior managers get up to speed very quickly. A process tool should visually take you through your framework's phases. It should allow your team member to quickly access the how-to knowledge for a particular task making every step a learning experience. Also, look for a tool that helps you build process frameworks and provides an easy way for project managers and leads to pick and choose their preferred framework from the process library as they kick off a new project.
  2. Stupid easy or very easy to use after a short (1-2 hours) training session. People are busy learning how to do their work better. Don't let the tool get in the way! If the tool is on top of Gartner's list, but difficult to use, it will end up on top of your back office closet shelf. Also, look for tools that do a good job showing those robust features only when you need it, rather than cluttering up the window. Modern tools should also have an ample set of self-guides, such as context sensitive short tutorial videos and mouse tool tips. Access to support staff in real time coupled with embedded social collaboration for team engagement and support is also important.
  3. The tool should work well with your process improvement culture. It should allow you team members to comment on how to improve the project process as they use the tool. It should make it easy for your process owners to update the content and then to publish that change out to the projects in real time. If the tool makes it easy to share project process improvement content, then you will be on your way to helping less experienced project leads become your new stars.


Projects are still failing by 70% or higher and this trend is slowly getting worse because of more complex projects with more people working remotely and experienced managers getting promoted and moving on. We found that this high failure rate continues because we don't have enough people with practical experience, who have capacity to solve problems; and are willing to share, help, and develop the ideas needed to solve project challenges.

You can still make a difference and increase your success rate. We have found that a shift in project management style from task list micro-management to process management and improvement increases project success rate by over 30%, continuously. Over a few years, we have helped companies drive up their success rates, reduce wasted investment and improve employee performance while making it easier to deliver all aspects of projects and programs. Our customer outcomes surprised us in two ways: 1) the simplicity in which they were achieved  and 2) the improvement results in project outcomes.

We realize there are investments required to make change happen. However, consider our opening concern in the first part of this articl. The amount of estimated cost resulting from a 29% project success rate could be in the trillions of dollars.  We believe that "...you cannot solve a problem with the same level of thinking used to create it". Shifting from a traditional approach to an approach proven in manufacturing to be transformative does not seem so large a leap and given our customer results, is proving to be worthwhile.


Project Execution Image #2.jpg

A global organization initiated a two-year, multi-billion dollar transformation effort. This effort is focused on six business areas in one of their four global groups (retail) and had more than 35 work streams with many different program management organizations and many different consulting organizations involved. Our effort that affected a global group, and hence allowed us visibility into several different program management groups and many different program and project teams. Our program was to define and deploy a global data and information management services organization.  

We performed the traditional project planning and created a very long list of tasks using MS Project. We developed MS PPT status report pages based on the direction from the work stream PMO, who in turn provided updates to the global transformation PMO. This data was then translated into a format for loading into Clarity, a traditional project management enterprise tool, to provide visibility into project spend by intergrading with the financial system.  

Our first effort was to define and then structure the program and subsequent projects and create a repeatable process where possible. We discovered that we had a global design/modeling process and then, a local country deployment process for the new organization. The way we did this work was to take the 1,000+ MS Project task list and break it into process steps and sub-steps. We did use a SaaS software product to help with this so it only took about two-three hours. Once completed we could then look for gaps in the process flow(s). Once found, we addressed that gaps, updated the MS Project task list, informed the team and moved forward on the project.  

We used the SaaS software product to work the process model on a weekly and sometimes daily basis to make sure we were not missing a step in the process. We also used the tool as a modeling and validation tool to continually confirm the program and project structures while validating the tasks were being completed in the right sub-process step and in the correct order/time frame.  

We did this for both the global modeling work and for the country deployment work. In all, over 16 months, there were 15 different projects (three global with one being 100% focused on IT engagement and 12 local) that were designed, modeled and planned. Only three were not deployed prior to the end of 2016, one year ahead of the initial plan. Our projects were under budget and only had an "Amber" status a couple times and only for one week due to client personnel falling behind on non-critical path deliverables.  

Out of the 36 other projects for which we had visibility, there was NO OTHER project that was not "RED" for an extended time.  

Our program effort was halted because of budget issues associated with the other projects as they were 15 months behind schedule.

There was not a huge retooling and training program! Nobody invested a single dollars to transform the way the client or the other consulting firms did their project management work.   If the client or other consulting firms wanted to make the improvements permanent, there is investment in helping the people think differently about project planning and project management - there is a change to the work. There is also a need for technology to support the different approach.

Side Note: After 3 different consulting firms ran the PMO organization for the business with which we were working, we witnessed the same structure and planning mistakes and the same questions from each of the firms. There was no real transition of PMO insight, lessons, processes, etc.  Each firm taking over the PMO had to "reinvent" what the PMO was doing and how it was doing it.  


  • On budget
  • On time
  • Identified performance business improvement of 20% (zero was expected from our project without added automation – we identified 20% without automation)
  • Never had a “RED” Status for our program
  • We knew of issues and impacts (Amber status) prior to impact and had mitigation plan (Risk Management Process) defined and executing prior to project turning “Amber"
  • Other projects and programs were a “RED” status for extended time frames. 
  • Global transformation program had to be redesigned due to budget overruns from other projects 

Selected references:

  1. * Posted by Shane Hastie and Stéphane Wojewoda (Oct 04, 2015). Standish Group - Chaos Report. Available: https://www.infoq.com/articles/standish-chaos-2015
  2. ** Posted by PwC - Global Infrastructure report, annual report on infrastructure outlook
  3. *** Posted by Storm Thomas (Oct. 1, 2015). How to achieve project success by Piet Joubert (Da Vinci Faculty). Available: https://www.linkedin.com/pulse/how-achieve-project-success-piet-joubert-da-vinci-faculty-thomas