| Firstly, what do we mean by 'Fail'? | | | | 5. Lack of executive support 9% |
| This has several different meanings in the context | | | | 6. Changing requirements/specs 9% |
| of projects, depending on who you ask in the | | | | 7. Lack of planning 8% |
| project environment. | | | | 8. Didn't need it any longer 8% |
| Some definitions might be: | | | | 9. Lack of IT management 6% |
| - project cancellation (reasons will include budget, | | | | 10. Technology illiteracy 4% |
| delay, relevance, strategy change and so on) | | | | 11. Other 10% |
| - project did not deliver the level of benefits | | | | Are these really reasons? |
| anticipated (but system is still in use). These | | | | For example, 'lack of IT management'. Is this a |
| anticipated benefits might have included items | | | | reason for failure? No. The real reason for failure |
| such as functionality, improved customer service | | | | is that: |
| and so on, but all ultimately measurable on the | | | | - There was no effective risk analysis and risk |
| 'bottom-line'. | | | | management process which worked (there may |
| - the project cost more than anticipated (but | | | | have been some risk analysis, even a plan). |
| system is still in use) | | | | What about 'Lack of Executive Support'? Same |
| - the post-implementation running costs are higher | | | | again. |
| than anticipated (but system is still in use) | | | | - There was no effective risk analysis and risk |
| - the project was later 'going-live' than anticipated, | | | | management process which worked. |
| implying that some earlier benefits were foregone | | | | Indeed, it can be argued that all project failure is |
| (but system is still in use) | | | | due to lack of an effective working risk analysis |
| What is the scale of failure? | | | | and management plan. |
| An oft-reported source is The Chaos Report | | | | To be pedantic, a thorough Risk Analysis should |
| (1995) by the Standish Group, although quite old | | | | include risks that the Risk Analysis may be |
| now. There is no reason to suppose that the | | | | incomplete, and that the Risk Management |
| situation has improved dramatically since then. | | | | process may fail. Hopefully, the associated |
| Methodologies may have improved, but | | | | probabilities will be low. |
| technology has become more complex and | | | | What if we have an effective Risk Analysis and |
| pervasive, and the scale of systems and | | | | Risk Management Process - can we still fail? |
| networks, and their degree of interconnectedness | | | | Yes. |
| has increased dramatically; this is witnessed for | | | | Consider a situation where an unexpected event |
| example by the scale of failure of highly visible | | | | occurs. For example, company financial issues |
| Government IT projects in the UK. | | | | necessitate a budget cut. The only way that the |
| The research showed that 31% of projects | | | | project can be successfully delivered is that the |
| would eventually be cancelled | | | | scope is formally reduced (infrastructure, |
| - 34 % of respondents were very "satisfied." | | | | functionality, organisational scope and so on), |
| - 58 % of respondents were "somewhat | | | | assuming that efficiency cannot be increased to |
| satisfied," | | | | cover the shortfall (and if the project manager |
| - 8 % of respondents were unhappy with what | | | | says that efficiency can be improved, then why |
| they got. | | | | was it not being done already)? This might still be |
| - 40 % of projects failed to achieve their | | | | seen as failure by some parts of the business if |
| business case within one year of cutover to live | | | | they don't get their bells and whistles. |
| operation. | | | | Why do projects REALLY fail then? |
| - The companies that did gain benefits from the | | | | The main reasons are |
| projects said that benefits realisation took six | | | | - Inadequate Risk Analysis (anticipation) and |
| months longer than expected (tough to accurately | | | | Control (execution) |
| put a number to, as benefits realisation is a flow). | | | | - Lack of visible high level sponsorship and |
| - Implementation costs were said to average 25 | | | | governance |
| % over budget, | | | | - Imprecise Objectives |
| - Supports costs were underestimated for the | | | | - Poor Planning |
| year following implementation by an average of | | | | - Poor Communication |
| 20 %. | | | | - Poor Requirements Gathering and Change |
| - Further results indicated 53% of projects would | | | | Control |
| cost over 189% of their original estimates (but it | | | | - Poor Project Management (includes methodology |
| is unclear whether this is a whole life net cost). | | | | choice, estimating, budgeting, recruitment, |
| Reasons for Failure/Response Rate | | | | monitoring, testing) |
| | | | In summary, these reasons are nothing more |
| 1. Incomplete requirements 13% | | | | than a failure to apply best practice using |
| 2. Lack of user involvement 12% | | | | experienced and qualified practitioners. |
| 3. Lack of resources 11% | | | | Survey data (c) 1995 The Standish Group. All |
| 4. Unrealistic expectations 10% | | | | other material (c) Phil Marks 2010. |