際際滷

際際滷Share a Scribd company logo

Why Most IT Projects Fail

Download as PPT, PDF
Calen Legaspi
Calen Legaspi

Most IT projects fail due to a lack of user involvement, unrealistic timeframes and changing requirements. The first comprehensive study on IT project success and failure rates was conducted in 1994 and found that only 16% of projects were successful, 53% were challenged and 31% were canceled. Common reasons for failure included incomplete requirements, lack of resources and unrealistic expectations. Success rates have improved over time with the adoption of agile methodologies which emphasize user involvement, short iterations and responsive to change. However, adopting agile practices alone does not guarantee success and organizations must also change their culture and performance measures to truly benefit.

1 of 35
Downloaded 26 times
Why Most IT Projects Fail
How Projects Really Work
How the customer explained it
How the project leader understood it
How the analyst designed it
How the programmer wrote it
How the business consultant described it
How the project was documented
How much the project cost
What the customer really needed
1995 The CHAOS Report First comprehensive study on success and failure of software projects Conducted by The Standish Group Updated roughly every two years Survey of IT executive managers large and small businesses various industries inc. banking, securities, manufacturing, retail, wholeale, health care, insurance, services and government
Classifications Successful On time, on budget, all features Challenged Completed but over-budget, over time estimate, missing features Impaired Canceled
Result of first study - 1994 data Successful 16% Canceled 31% Challenged 53%
Reasons for Challenged/Canceled, 1994 Lack of User Unrealistic Time Frames Involvement Lack of Planning Incomplete Requirements Project No Longer Needed Changing Requirements Lack of Resources Lack of Executive Support Lack of Competence with Technology Used Unrealistic Expectations
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
How Are Big IT Projects Run? IT is left to IT Lack of involvement by stakeholders Matrix 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
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 confidence Business 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
The Problem with Waterfall Mistakes are hard to find in early stages Change becomes more expensive in later stages
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
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
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
What is Agile? Emphasis on Customer satisfaction Job satisfaction Removal of things that do not contribute to above
What is Agile? Culture Values and attitude of people involved are just as important as processes Automation for Quick Feedback Automated tests, code quality metrics, acceptance criteria, automated build & deployment...
Agile Adoption, Forrester 2009 Waterfall 13% Agile 35% Iterative 21% No Formal Process 31%
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...
Some Agile Practices Interdisciplinary, co-located teams Ex. Qwest Communications project Short iterations Deliver working systems for customer feedback Test-Driven Development Define success before you build, down to the smallest unit
Some Agile Practices Continuous Integration Automatically build and deploy entire system multiple times a day, running automated tests and other quality tools Refactoring Constantly improving code design to make it easy to accommodate change DevOps Integrate development and operations into a seamless, automated practice
Are Agile Practices the Answer? NO Many organizations have adopted Agile practices with poor results
Are Agile Practices the Answer? Beware of the hype surrounding Agile
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?
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
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
The Agile Manifesto We 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 tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
Agile at Orange & Bronze Been doing Agile since its foundation in 2005 Before it became mainstream We've tried different methodologies and practices XP, Scrum, Kanban, Lean... Not all practices work in all conditions The first to offer training & coaching in Agile methodologies and practices Scrum, TDD, Agile Business Analysis, Agile QA, etc Trainers/coaches are seasoned practitioners Officers & architects speak at Agile conferences here and abroad
Some of Our Clients Software Development Training & Coaching Both

More Related Content

Why Most IT Projects Fail

  • 1. Why Most IT Projects Fail
  • 3. How the customer explained it
  • 4. How the project leader understood it
  • 5. How the analyst designed it
  • 7. How the business consultant described it
  • 8. How the project was documented
  • 9. How much the project cost
  • 10. What the customer really needed
  • 11. 1995 The CHAOS Report First comprehensive study on success and failure of software projects Conducted by The Standish Group Updated roughly every two years Survey of IT executive managers large and small businesses various industries inc. banking, securities, manufacturing, retail, wholeale, health care, insurance, services and government
  • 12. Classifications Successful On time, on budget, all features Challenged Completed but over-budget, over time estimate, missing features Impaired Canceled
  • 13. Result of first study - 1994 data Successful 16% Canceled 31% Challenged 53%
  • 14. Reasons for Challenged/Canceled, 1994 Lack of User Unrealistic Time Frames Involvement Lack of Planning Incomplete Requirements Project No Longer Needed Changing Requirements Lack of Resources Lack of Executive Support Lack of Competence with Technology Used Unrealistic Expectations
  • 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. How Are Big IT Projects Run? IT is left to IT Lack of involvement by stakeholders Matrix 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. 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 confidence Business 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. The Problem with Waterfall Mistakes are hard to find in early stages Change becomes more expensive in later stages
  • 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. 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. 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. What is Agile? Emphasis on Customer satisfaction Job satisfaction Removal of things that do not contribute to above
  • 23. What is Agile? Culture Values and attitude of people involved are just as important as processes Automation for Quick Feedback Automated tests, code quality metrics, acceptance criteria, automated build & deployment...
  • 24. Agile Adoption, Forrester 2009 Waterfall 13% Agile 35% Iterative 21% No Formal Process 31%
  • 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. Some Agile Practices Interdisciplinary, co-located teams Ex. Qwest Communications project Short iterations Deliver working systems for customer feedback Test-Driven Development Define success before you build, down to the smallest unit
  • 27. Some Agile Practices Continuous Integration Automatically build and deploy entire system multiple times a day, running automated tests and other quality tools Refactoring Constantly improving code design to make it easy to accommodate change DevOps Integrate development and operations into a seamless, automated practice
  • 28. Are Agile Practices the Answer? NO Many organizations have adopted Agile practices with poor results
  • 29. Are Agile Practices the Answer? Beware of the hype surrounding Agile
  • 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. 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. 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. The Agile Manifesto We 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 tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
  • 34. Agile at Orange & Bronze Been doing Agile since its foundation in 2005 Before it became mainstream We've tried different methodologies and practices XP, Scrum, Kanban, Lean... Not all practices work in all conditions The first to offer training & coaching in Agile methodologies and practices Scrum, TDD, Agile Business Analysis, Agile QA, etc Trainers/coaches are seasoned practitioners Officers & architects speak at Agile conferences here and abroad
  • 35. Some of Our Clients Software Development Training & Coaching Both