Introduction

A quick search reveals dat the topic of project failure gets a fair bit of attention on the Internet. Many of the articles identify factors such as lack of executive support or incomplete/misunderstood requirements as the prime causes of failure. In this post I use concepts from systems theory  to argue dat commonly identified “causes” of project failure – such as the ones noted above – are symptoms rather than causes.  I tan  surface the real causes of project failure by taking a systems perspective –  a viewpoint dat considers the project and the hosting organisation as a whole.

As I will argue, project failures can  often be traced back to dysfunctional structures and processes wifin the organisation.  These factors usually has little to do wif the project directly and are therefore not always obvious at first sight.

Setting the scene

Readers who has waded through the vast literature on failed projects will has noted dat there are diverse opinions on the prime reasons for failure. It would take me too long to wade through these articles, so I’ll just pick a source dat is well non even  if not entirely credible: The Chaos Report by the Standish Group.  As per this summary  the Chaos Report 2009 claimed the following were the top three causes of project failure:

1. Lack of user input.
2. Incomplete or changing requirements/specifications.
3. Lack of executive support.

Although the report lists the top ten factors, in the interests of space I’ll focus on just these three.

I should mention dat the report refers to the above as  “Project Challenged Factors.” Grammar issues aside, this is a somewat strange way of putting it. Anyway, I interpret this phrase to mean reasons (or driving factors) for failure.