Every once in a while we read of articles with titles such as “why do projects fail?”  Several organizations have conducted studies to determine the reason for failure, some within the IT industry and others more general.  For example, the Standish group listed several reasons in one study a few years ago and showed how poorly defined user requirements was by far the highest causes of failure.

One this that I have learned however over the years is that often failure is caused by a combination of actions and circumstances which together create a certain environment that makes it difficult for the project to succeed.  Various causes become contributors rather than the only source of failure.

In many instances the seeds of failure are planted early in the project lifecycle.  During initiation there may be conditions that are either ignored or not addressed appropriately.  Within planning, elements might be underestimated or overlooked.  By the time you reach the execution stage of these project the team finds itself in a pit with very little chance of getting out.

However it seems that many of these failing projects are not brought to a close to allow the organization to cut its losses or the team to save face.  These projects tend to drag on and on until the drain on the organization is so large that it explodes causing all sorts of problems.  Worse still in some instances, the project moves to its ultimate demise very slowly with individual team members being pulled out one at a time and the remainder staying behind.  It is as if those left behind are like the family members of a comatose person who are sitting in the room watching the person they love slip away slowly until finally they give up their life.

To attempt to understand the type of actions that project managers, teams, and organizations must take to succeed, we have to develop a basic understanding of why projects fail.  If we are fortunate enough, we will have learned our lessons from other people’s experiences, however, most of us learn our lessons the hard way, from failing on projects and hoping to avoid that failure in the future.

As I mentioned earlier, I believe that failure on projects is often caused by a combination of issues rather than one single problem.  These issues are associated with a key stakeholder group’s action (or lack thereof) to ensure that a risk is mitigated early on or an issue is addressed before the point of no return.  I’ve listed below some of the causes that I’ve both observed and experienced and grouped them within various stakeholder groups:

Project Manager

  • Not acting proactively to ensure that problems are identified and addressed quickly
  • Lack of urgency is addressing key elements in planning and constant monitoring during execution
  • Limited knowledge of project management basics and poor understanding of how to apply these PM processes
  • Not understanding the parameters of the product/service being delivered
  • Poor knowledge of the industry that the project is working within which results in not knowing the type of questions to ask in planning
  • Limited experience in leading teams in developing plans and delivering which likely means that they have no experience using tools such as the WBS among many.

Executive Sponsor and/or Senior Management

  • Limited focus or interest in the project
  • Not understanding their expected role on the project
  • Limited scope of authority to support and champion the project
  • Changing business drivers
  • Unrealistic expectations which result in setting the wrong constraints such as a limited budget or a timeline that is too tight

Project Team

  • Conflicting priorities and shifting focus areas
  • Inexperience in working on activities of a similar nature to that of the current project
  • Poor technical ability in whatever field the project happens to be in
  • Ineffective communications which result in constant blindsiding of the team and of the PM
  • Lack of focus on the project due to multiple project assignments
  • Not being involved in planning and estimating

Customers and/or Users (if the project is an external project)

  • Inability to explain their requirements
  • Constantly changing priorities and not having enough time to dedicate to support the project
  • Conflicts among user or customer groups which result in confusing the project team
  • Poor teamwork and communication with the project manager
  • Lack of involvement in concept definition, design, product acceptance, etc…
  • Unwillingness to own the product/service being delivered by the project team

Sales (if the project is an external project)

  • Promising anything just to get the sale from the customer which results in poor expectation setting
  • Lack of involvement in transitioning to the project manager and team

The above mentioned stakeholder groups and contributing factors to failure are certainly not a complete list nor is it a scientific study.  The list is merely observations that I’ve seen or encountered on projects.  What always amazes me though within project management is our (humans) tendency to act in two diametrically opposed ways at the same time.  We tend to over complicate simple concepts and under estimate complicated elements of the project.  It may be perhaps due to the fact that we pay attention to the wrong things during various phases.  Ultimately the different between failure and success is perception.  Does the team, organization, or the customer view the project as a failure?  If the answer is yes, it is hard to change that perception even if the team delivered on time, within budget, and according to scope.