Project management failure - Why projects fail

I. Project Management Failure - Background

A whole discipline known as "Project Management" has evolved in the past fifty odd years.

Thousands of people have spent entire life-times pursuing project management as their career. Several trillions of dollars have been pumped into handling and managing projects “the professional way” in order to avoid Project Management failure. Standards, standards, galore - wherever the eyes can see.

Yet, at the end of the day, there is not much to report by way of success. Surveys after surveys have beamed gloomy pictures about the way projects end up - in the dust bin. Project Management Failure is more often than not the outcome.
The Standish Report does it quite elegantly: it categorizes project outcomes into three -

• Success: a project that gets the bouquets and champagne sprays - for it is completed on time, within budget, and has met all original specs.
• Challenged: a project that finally made to the deadline. Yet, there were cost/time overruns, and perhaps not all of original specs were met.
• Failure: A project was abandoned or cancelled due to Project Management Failure.

Consistently, since Standish began surveying companies for their project outcomes, the percentage of category 3 (Project Management Failure) has been higher. The percentage of category 1 (Success!) has been abysmally low.

II. Why projects fail: different perspectives

Standish group’s line of rationale, trying to explain the trillion-dollar question of why Project Management Failure occurs so often, makes insightful reading. According to them, projects that “succeed” do so due to the following reasons:

• The end users were apparently involved right through the development of the project.
• The project manager had full backing of the executive management. Whatever hurdles came up during the project were promptly looked into by the latter.
• Specifications were clear-cut. This was also possible due to close-level of interaction between the end-users and the project team.
• Expectations from the project were realistic. There was nothing overly optimistic about what could be achieved within the project’s constraints.
• Various interest groups

According to the Standish Reports, projects slipped behind in time, or went overboard on budget, or were unable to deliver the full functionality, due to the following reasons:

• User inputs were inadequate, or thoroughly lacking. Passive users got the chance to comment only after the project was handed over to them, neatly wrapped.
• Project specifications were incomplete. There seemed to be an inordinate rush to jump from requirements analysis to design stage.
• Specifications kept on changing over the period of the project execution. The project manager kept incorporating the changed specifications into the system, in order to appease stakeholders.
• Executive management showed little or no interest in putting out any fires that flared up during the time the project was underway.
• The project team was technically less than competent.

Finally, their reasons for why projects end up in the dustbin of history are as follows:

• Users failed to provide complete requirements.
• Users were not involved in the development process.
• The project had inadequate or no resources that were vital for its completion.
• Executive management just did not seem interested in seeing the project through.
• Specs kept on changing during the project’s tenure.
• Planning was a casualty.
• The project’s scope had become outdated due to change in business environment.
• The project team was technically incompetent.

Yet another take on the reasons why some projects succeed and a lot others fail attributes three variables whose impact on project performance is the maximum:

• Good Planning: The more forward, future-oriented and in-detail planning, the higher the chances of success. Each and every activity that is expected down the line gets due attention. Not only is this pre-planning well-documented, but also even after the project has taken off, if things don’t exactly pan out as planned, the project manager does not hesitate to re-plan, avoiding Project Management Failure, and readily incorporates the changed circumstances in their new version, so that future events are controlled.
• Clear responsibility and accountability: All team members have a clear understanding of their roles and duties. There is clear awareness of what exactly is expected from them.
• Schedule control: Project managers are constantly on their toes, recording time elapsed, milestones reached, change in people/task allotments, and the like. This helps in fine-tuning the schedule on a real-time basis.

  This gives them time to implement a fallback position and /or rearrange things so that the project is back on track.

While these analyses are general pointers, there is no universal diagnosis on why projects fail. Every project has its own unique complexities and its own set of players and circumstances. A project manager has to discern the uniqueness of the project that they have on hand, and keep crosschecking the project’s contours against what they have learnt in their class and on the internet.

III. Project Management failure - End word

Unlike other disciplines, project management as a formal discipline is just fifty years young. Perhaps a few more decades shall be required for sufficient knowledgebase to be built up, before the present failure rate can go down to a more comfortable level.

Return to Software Project Management