Some definitions might be:

• project cancellation (reasons will include budget, delay, relevance, strategy change and so on)
• project did not deliver the level of benefits anticipated (but system is still in use). These anticipated benefits might have included items such as functionality, improved customer service and so on, but all ultimately measurable on the 'bottom-line'.
• the project cost more than anticipated (but system is still in use)
• the post-implementation running costs are higher than anticipated (but system is still in use)
• the project was later 'going-live' than anticipated, implying that some earlier benefits were foregone (but system is still in use)

What is the scale of failure?

An oft-reported source is The Chaos Report (1995) by the Standish Group, although quite old now.

Key Findings

• The research showed that a staggering 31.1% of projects would eventually be cancelled
• 34 % of respondents were very “satisfied.”
• 58 % of respondents were “somewhat satisfied,”
• 8 % of respondents were unhappy with what they got.
• 40 % of projects failed to achieve their business case within one year of cutover to live operation.
• The companies that did gain benefits from the projects said that benefits realisation took six months longer than expected (tough to accurately put a number to, as benefits realisation is a flow).
• Implementation costs were said to average 25 % over budget,
• Supports costs were underestimated for the year following implementation by an average of 20 %.
• Further results indicated 53% of projects would cost over 189% of their original estimates (but it is unclear whether this is a whole life net cost).

Are these really reasons?

For example, 'lack of IT management'. Is this a reason for failure? No. The real reason for failure is that:

• There was no effective risk analysis and risk management process which worked (there may have been some risk analysis, even a plan).

What about 'Lack of Executive Support'? Same again.

• There was no effective risk analysis and risk management process which worked.

Indeed, it can be argued that all project failure is due to lack of an effective working risk analysis and management plan.

To be pedantic, a thorough Risk Analysis should include risks that the Risk Analysis may be incomplete, and that the Risk Management process may fail. Hopefully, the associated probabilities will be low.

What if we have an effective Risk Analysis and Risk Management Process - can we still fail?

Yes.

Consider a situation where an unexpected event occurs. For example, company financial issues necessitate a budget cut. The only way that the project can be successfully delivered is that the scope is formally reduced (infrastructure, functionality, organisational scope and so on), assuming that efficiency cannot be increased to cover the shortfall (and if the project manager says that efficiency can be improved, then why was it not being done already)? This might still be seen as failure by some parts of the business if they don't get their bells and whistles.

Why do projects REALLY fail then?

The main reasons are

• Inadequate Risk Analysis (anticipation) and Control (execution)
• Lack of visible high level sponsorship and governance
• Poor Planning
• Poor Communication
• Poor Requirements Gathering and Change Control
• Poor Project Management (includes methodology choice, estimating, budgeting, recruitment, monitoring, testing)

In summary, it is because clients do not always use properly qualified and experienced project and programme managers, and when they do, they don't always take the advise they are given. Still, that goes with the territory when you are a consultant.... 

Survey data/results © 1995 The Standish Group.

All other material © 2010 Phil Marks
 

Back to top