Why Do Projects Fail?

by
The standish group logo

I used to follow a company, The Standish Group, which publishes an annual report on project failure. Reading and learning from this was a big deal for my partners and me, as we made our living implementing large process/technology projects. In 2020, the Standish Group says that 83.9% of IT projects were considered a partial or complete failure (a partial failure meaning a project delivered past the due date, over budget, or lacking planned functionality.) So using my prodigious mathematical capability means that only 16.1% of projects were deemed successful as expected.

The top five factors cited by Standish responsible for unsuccessful projects were:

  1. Lack of user input
  2. Incomplete Requirements & Specifications
  3. Changing Requirements & Specifications
  4. Lack of executive support
  5. Technical incompetence

Most of us could probably guess one or two of these, but hardly anyone who has not worked in a project-delivery business environment gets all five. Many would understand #5 and some #2, but most people do not think of #4 and #1 as a significant risk. Recall the seven keys to managing successful projects from last week:

  • Stakeholders are committed.
  • Business benefits are realized.
  • Work and schedule are predictable.
  • The team is high-performing.
  • The scope is realistic and managed.
  • Risks are mitigated.
  • (if applicable) Partner organization’s benefits are realized.

Mapping the seven keys to the Standish Group's risk of project failure, I would place “lack of executive support” at the top and “stakeholders are committed” as the key to mitigating that risk. Similarly, I would minimize the risk of #1, #2, and #3 from the list of unsuccessful projects with keys “work and schedule are predictable” and “team is high performing.” Making work and schedules predictable implies that you have communicated the importance of user input, including requirements and the effort and timing required. In complex teams involving client, consultant, and perhaps technology solution personnel, communicating roles, deliverables, and dependencies are essential in ensuring that work and schedule are predictable.

The top five factors cited by Standish responsible for unsuccessful projects were:

  1. Lack of user input
  2. Incomplete Requirements & Specifications
  3. Changing Requirements & Specifications
  4. Lack of executive support
  5. Technical incompetence

Note, “technical incompetence” is not high on my list. Why? Because mitigating key risks means we’ve considered the technology risk and the team composition and have developed the plan with that in mind. I’ve experienced horrible technology issues when the solution we were sold on did not work. I know the technology business seems sexy, but when you have to get on a plane and fly halfway around the world to tell a client that the technology doesn’t work, it can make you consider an easier way to earn a living, say as an Uber driver. We’ll talk more about projects next week.

Do you need help in getting projects done on time and budget? Email and let me know, and as always, I welcome your comments and suggestions.