Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Analyzing Project Failure Modes: Lessons learnt from the field

Roger Layton, MD of NIRO Project Management Consultants on the importance of learning from IT Project Failures

  • Login to see the comments

Analyzing Project Failure Modes: Lessons learnt from the field

  1. 1. Project Failure Modes: Lessons from the Field Roger Layton MD, NIRO Project Management (Pty) Ltd MD, Roger Layton Associates (Pty) Ltd
  2. 2. Basic Premises <ul><li>Failure Avoidance </li></ul><ul><ul><li>it is possible to avoid failure completely </li></ul></ul><ul><ul><li>or to minimise the impact at the earliest time </li></ul></ul><ul><ul><li>but this requires comprehensive understanding of all possible types and modes of failure </li></ul></ul><ul><ul><li>as well as best practice approaches to deal with issues and threats to success </li></ul></ul><ul><li>Learning from Other’s Mistakes </li></ul><ul><ul><li>What can we learn from large-scale failures that can help to avoid future failures </li></ul></ul><ul><ul><li>Can we all learn from the lessons of a few disasters? </li></ul></ul><ul><li>Improving our Understanding of Failure </li></ul><ul><ul><li>We need to focus more on the understanding of failure than on success </li></ul></ul><ul><ul><li>We will encounter the potential for failure every day </li></ul></ul>
  3. 3. What is Project Failure? <ul><li>Analysis of Google search on “Project Failure” identifies almost exclusively IT Project Failure! </li></ul><ul><li>Many good case studies reported – but virtually NO companies (customers) or suppliers prepared to comment on their own failures </li></ul><ul><li>Need to distinguish levels and modes of failure… </li></ul>
  4. 4. Defining “Failure” <ul><li>The inability of the project to deliver the intended benefits to the identified stakeholders </li></ul><ul><li>However – Failure is relative – there are many levels of failure from complete failure to mild failure, and each should be seen in context </li></ul>
  5. 5. Projects and Complexity <ul><li>A project is a complex arrangement of time, costs, resources, scope, benefits, risks, issues, quality and structures </li></ul><ul><li>Failure is very easy : any one part or link can cause failure – there are millions of way to fail </li></ul><ul><li>Success is very difficult : there is only ONE way to succeed – the correct balance of the project elements </li></ul>
  6. 6. Levels of Failure <ul><li>Complete Failure </li></ul><ul><ul><li>Cancelled before completion </li></ul></ul><ul><ul><li>Failure after implementation so serious that have to roll-back to previous version or manual alternative </li></ul></ul><ul><ul><li>Organisation is significantly worse off than before, and may be at risk of bankruptcy </li></ul></ul><ul><li>Serious Failure </li></ul><ul><ul><li>Continues into operation, but does not achieve full benefits </li></ul></ul><ul><ul><li>May be less effective and efficient than existing system </li></ul></ul><ul><ul><li>More costs than benefits and significant loss of brand value </li></ul></ul><ul><li>Medium Failure </li></ul><ul><ul><li>Some benefits received, but not all </li></ul></ul><ul><ul><li>Many tolerances overrun </li></ul></ul><ul><ul><li>Major fixes required to recover </li></ul></ul><ul><li>Mild Failure </li></ul><ul><ul><li>Largely meets benefits but some of the tolerances exceeded (time, cost, quality, benefits, risks, knowledge transfer, …) </li></ul></ul>
  7. 7. If it ain’t broke, don’t fix it! <ul><li>How often are organisations forced into the conservative position of not starting new projects because of a fear of failure (CYA) </li></ul><ul><li>At the same time they deny themselves the opportunities and benefits that may emerge from new projects and products. </li></ul><ul><li>Without new IT and business projects, organisations will over time become more ineffective, more inefficient and eventually will become extinct. </li></ul>
  8. 8. If it ain’t broke yet, then break it! <ul><li>How often are organisations placed into a worse position by having tried to develop and install a new system and failed. </li></ul><ul><li>We rely on IT systems more and more in our world. </li></ul><ul><li>When large systems fail to be delivered, or fail after deployed, they can impact on the lives of thousands or millions of people. </li></ul>
  9. 9. Managing Change <ul><li>All programmes and projects are a reaction to the need for change – driven by business strategy and policy </li></ul><ul><li>Programmes deliver the changes and the benefits by producing new products, processes and services </li></ul><ul><li>Projects will create these products </li></ul>
  10. 10. Change Strategy Conservative Evolutionary If it ain’t broke, don’t fix it If it ain’t broke yet, then break it Do nothing… Risk of stagnation and extinction Lose competitive advantage Lose efficiency and effectiveness OR Sit back and watch competitors fail! Risk of high costs, not meeting deadlines and not receiving any benefits Being in a worse position than before with nothing to show Bad publicity and brand damage Legal actions We are in trouble if we do, and in trouble if we don’t Do ALL large IT projects have to endure the high risk of failure?
  11. 11. Examples from the Field <ul><li>Source : Information Week, 13/16 Oct 2006, Paul McDougall </li></ul><ul><li>“ in most cases overly complex IT makeovers are doomed to fail because their success depends upon too many unpredictable variables falling nicely into place” </li></ul><ul><li>“ Some elements of success include :- </li></ul><ul><ul><li>Meticulous business case analysis </li></ul></ul><ul><ul><li>Sound strategies for change management </li></ul></ul><ul><ul><li>Workable back-up plans if the big one happens ” </li></ul></ul>
  12. 12. Selection of Field Examples <ul><li>Only using documented examples as have appeared in press </li></ul><ul><li>No local examples cited </li></ul><ul><li>Specific elements of failure extracted to serve as lessons learned </li></ul>
  13. 13. Example 1 : MacDonalds <ul><li>2001 : Intranet to connect 30,000 outlets with real-time information </li></ul><ul><li>$170 million written off </li></ul><ul><li>Early termination when estimated costs of completion reached $1 billion </li></ul><ul><li>Decided that money could be better used </li></ul><ul><li>PROBLEM : scope too broad – no possible way to construct it </li></ul><ul><li>MODE OF FAILURE: Business Case failure </li></ul><ul><li>TO THEIR CREDIT : Decided to stop before spending any more! </li></ul>
  14. 14. Example 2 : US IRS <ul><li>GOAL : Upgrade the fraud-detection system </li></ul><ul><li>Switched off old system </li></ul><ul><li>PROBLEM: System did not work – could not be deployed – and old system already switched off </li></ul><ul><li>COSTS : Estimated losses of $318 million in lost revenue/undetected fraud </li></ul><ul><li>MODE OF FAILURE: Many – classified as “maintenance upgrade” instead of new system </li></ul>
  15. 15. Example 3 : IRS infrastructure <ul><li>8 year project to revise infrastructure </li></ul><ul><li>Personnel retiring and lack of expertise </li></ul><ul><li>Failure to deploy meant rebooting the old system for 2007 tax season </li></ul><ul><li>Costs to Date : $8 billion </li></ul><ul><li>MODE OF FAILURE: Many – too large a project – too long a timeframe – solutions out of date before deployed – loss of skills </li></ul>
  16. 16. Example 4 : Neilsen Media Research <ul><li>Viewer stats in TV industry </li></ul><ul><li>Complete rewrite of the system </li></ul><ul><li>Wanted to get finished within one year </li></ul><ul><li>8 years on still no new system </li></ul><ul><li>Costs and time overrun </li></ul><ul><li>MODE OF FAILURE : Unrealistic schedules – always overdue and rushing – quality second to time, costs get lost </li></ul>
  17. 17. Example 5 : UK NHS <ul><li>Rewrite of complete national health system </li></ul><ul><li>More than 12 vendors – no compatibility in systems – squabbling among vendors </li></ul><ul><li>Users inadequately consulted </li></ul><ul><li>Contractors get no money until system delivered </li></ul><ul><li>One large contractor has pulled out at loss of $450 million </li></ul><ul><li>Costs to date = $10 billion overrun </li></ul><ul><li>Major vendor (iSoft) under threat of bankruptcy </li></ul>
  18. 18. Example 5 / contd <ul><li>MODES OF FAILURE : many </li></ul><ul><ul><li>Government contracting policy – try to reduce risk by spreading work among vendors </li></ul></ul><ul><ul><li>Government tender policies – splitting specifications from implementation over different organisations </li></ul></ul><ul><ul><li>Job too large – biting off too much </li></ul></ul>
  19. 19. Analysis of Failures <ul><li>Need a formal method for analysis of failures so that we do not have to learn same lessons over and over again </li></ul><ul><li>Need a means of reporting failure and disclosure so that maximum benefits are gained for the future </li></ul><ul><li>Need to ensure that organisations accountable for their work and cannot simply hide details in order to protect reputations </li></ul><ul><li>HOWEVER : Analysis of Failure is itself Complex </li></ul>
  20. 20. Analysis of Failure/2 <ul><li>Historical Research = What Happened? </li></ul><ul><ul><li>Many histories – many viewpoints </li></ul></ul><ul><ul><li>Can we get to the truth or are all interpretations naturally biased </li></ul></ul><ul><ul><li>Is there such a thing as an independent analysis? </li></ul></ul><ul><ul><li>Analysis can only be successful if there is a well-documented project </li></ul></ul>
  21. 21. Risks that can induce Failure <ul><li>Organisation </li></ul><ul><ul><li>Failure to constitute a Project Board properly </li></ul></ul><ul><ul><li>Lack of involvement from corporate management </li></ul></ul><ul><ul><li>Lack of involvement from customer </li></ul></ul><ul><ul><li>Lack of involvement from user </li></ul></ul><ul><ul><li>Wrong people selected to assist </li></ul></ul><ul><ul><li>Responsibilities not explicit </li></ul></ul><ul><ul><li>Some key responsibilities not allocated </li></ul></ul>
  22. 22. Risks that can induce Failure/2 <ul><li>Communication </li></ul><ul><ul><li>Lack of reporting structure </li></ul></ul><ul><ul><li>Lack of sufficient information from decision-making </li></ul></ul><ul><ul><li>Lack of usage of the information as reported – get the information but not acted on </li></ul></ul><ul><ul><li>People who receive reports do not know what they are supposed to do with them – think that someone else is acting on them </li></ul></ul>
  23. 23. Other Risks that can induce Failure <ul><li>Specification + Scope Management </li></ul><ul><li>Business Case Management + Realised Benefits </li></ul><ul><li>Quality Control </li></ul><ul><li>Change Control + Issue Management </li></ul><ul><li>Risk Analysis + Risk Management </li></ul><ul><li>Configuration Control </li></ul><ul><li>User Involvement </li></ul><ul><li>Incompetence of Personnel </li></ul><ul><li>Unsuitable Technology </li></ul>
  24. 24. Recommendations <ul><li>Recommend that all projects be divided into smaller units – easier to manage – impact of failure is reduced </li></ul><ul><ul><li>= DIVIDE AND CONQUER </li></ul></ul><ul><li>High-level Programme Management takes the long-term view – identifies evolving technologies and decides on appropriate solution structures </li></ul>
  25. 25. Recommendations/2 <ul><li>Need a Project Management Method that be used throughout the organisations </li></ul><ul><ul><li>Common Language for Projects </li></ul></ul><ul><ul><ul><li>E.g. what is an issue, what is a risk, what does “quality” imply, what is a “tolerance” </li></ul></ul></ul><ul><ul><li>Simple method that is easy to apply </li></ul></ul><ul><ul><li>Method that can be used for early detection of failure modes </li></ul></ul>