Why Most IT Projects Fail


Published on

My presentation at the ComputerWorld Executive Briefings on Business Agility on January 19, 2013.

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Why Most IT Projects Fail

  1. 1. Why Most IT Projects Fail
  2. 2. How Projects Really Work
  3. 3. How the customer explained it
  4. 4. How the project leader understood it
  5. 5. How the analyst designed it
  6. 6. How the programmer wrote it
  7. 7. How the business consultant described it
  8. 8. How the project was documented
  9. 9. How much the project cost
  10. 10. What the customer really needed
  11. 11. 1995 – The CHAOS ReportFirst comprehensive study on success and failure of software projects – Conducted by The Standish Group – Updated roughly every two yearsSurvey of IT executive managers – large and small businesses – various industries • inc. banking, securities, manufacturing, retail, wholeale, health care, insurance, services and government
  12. 12. Classifications• “Successful” – On time, on budget, all features• “Challenged” – Completed but over-budget, over time estimate, missing features• “Impaired” – Canceled
  13. 13. Result of first study - 1994 data Successful 16% Canceled 31% Challenged 53%
  14. 14. Reasons for Challenged/Canceled, 1994Lack of User Unrealistic Time Frames Involvement Lack of PlanningIncomplete Requirements Project No Longer NeededChanging Requirements Lack of ResourcesLack of Executive Support Lack of Competence with Technology UsedUnrealistic Expectations
  15. 15. Reasons for Success, 1994 User Involvement  Smaller Project Executive Milestones Management Support  Competent Staff Clear Statement of  Ownership Requirements  Clear Vision & Proper Planning Objectives Realistic Expectations  Hard-Working, Focused Staff
  16. 16. How Are Big IT Projects Run?IT is left to IT Lack of involvement by stakeholdersMatrix organizations People not dedicated & focused Accountability is to department head, not project lead Poor communication • No co-location • Simple issues take a long time to resolve
  17. 17. How Are Big IT Projects Run?Big, upfront requirements Stakeholders will ask for the moon Documentation so voluminous that often inconsistent & conflicting • Thick documentation = false sense of confidenceBusiness outcomes poorly/not defined Lack of measurable, observable criteria for success despite voluminous requirements documentation • Ex. cost reduction targets, customer satisfaction, market share, process handling time
  18. 18. The Problem with “Waterfall”Mistakes are hard to find in early stagesChange becomes more expensive in later stages
  19. 19. CHAOS Results, 94 - 08 1994 1996 1998 2000 2002 2004 2006 2008 Successful 16% 27% 26% 28% 34% 29% 35% 32% Challenged 53% 33% 46% 49% 51% 53% 46% 44% Canceled 31% 40% 28% 23% 15% 18% 19% 24% 60% 50% 40% 30% 20% 10% 0% 1994 1996 1998 2000 2002 2004 2006 2008
  20. 20. Reasons for Success, 04 - 08• User involvement • Project manager• Executive management expertise support • Financial management• Clear business • Skilled resources objectives • Formal methodology• Optimizing scope • Standard tools and• Agile process methodology
  21. 21. What is Agile?Family of methodologies that advocate “lightweight” and “human” software development processes – Extreme Programming (XP), Scrum, Kanban, Lean, Crystal, Agile Unified Process...Coined in 2001 by the creators of similar methodologies reacting to “heavyweight” methodologies – “heavyweight”: too much work that does not contribute to successful software project
  22. 22. What is Agile?Emphasis on Customer satisfaction Job satisfaction Removal of things that do not contribute to above
  23. 23. What is Agile?Culture Values and attitude of people involved are just as important as processesAutomation for Quick Feedback Automated tests, code quality metrics, acceptance criteria, automated build & deployment...
  24. 24. Agile Adoption, Forrester 2009 Waterfall 13% Agile 35% Iterative 21% No Formal Process 31%
  25. 25. Aspects of Software Development• Project - No one Management methodology covers• Engineering all aspects• Business Analysis - No one methodology covers• Quality Assurance all situations• User Experience• Others...
  26. 26. Some Agile PracticesInterdisciplinary, co-located teams Ex. Qwest Communications projectShort iterations Deliver working systems for customer feedbackTest-Driven Development Define success before you build, down to the smallest unit
  27. 27. Some Agile PracticesContinuous Integration Automatically build and deploy entire system multiple times a day, running automated tests and other quality toolsRefactoring Constantly improving code design to make it easy to accommodate changeDevOps Integrate development and operations into a seamless, automated practice
  28. 28. Are Agile Practices the Answer? NOMany organizations have adopted Agile practices with poor results
  29. 29. Are Agile Practices the Answer? Beware of the hype surrounding Agile
  30. 30. Why Agile Fails• Culture of mistrust• Performance measures not aligned towards collaboration• Capability of personnel• Agile authors and consultants that preach silver bullets & snake oil – Example... “leaderless teams”... what?
  31. 31. Improving the Success Rate• No silver bullets – Slow and steady changes – Each company is different• Changing not just practices, but also culture and performance measures – Align towards collaboration • Ex: Reward overall project success, not just specific department deliverables• Smaller project scopes, measurable outcomes
  32. 32. Improving the Success Rate• Focused, multidisciplinary, co-located teams – Avoid matrix organization – IT is too important to leave to IT!• Teams with end-to-end responsibility – Requirements definition, design, development, testing, deployment, and business results• Did I say no silver bullets? – Experienced, pragmatic coaches can help
  33. 33. The Agile ManifestoWe are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
  34. 34. Agile at Orange & BronzeBeen doing Agile since its foundation in 2005 Before it became mainstreamWeve tried different methodologies and practices XP, Scrum, Kanban, Lean... Not all practices work in all conditionsThe first to offer training & coaching in Agile methodologies and practices Scrum, TDD, Agile Business Analysis, Agile QA, etc Trainers/coaches are seasoned practitionersOfficers & architects speak at Agile conferences here and abroad
  35. 35. Some of Our ClientsSoftware Development Training & Coaching Both