Downloaded 17 times
Uploaded byOrange and Bronze Software Labs
Why Most IT Projects Fail
The document discusses the reasons many IT projects fail, highlighting statistics from the Standish Group's chaos report and the challenges faced in project execution, such as lack of user involvement and poor communication. It emphasizes the importance of agile methodologies as a response to traditional waterfall approaches, advocating for greater collaboration and flexible practices in software development. Additionally, it outlines factors that contribute to project success, including skilled resources, executive support, and clear objectives.
More Related Content
Similar to Why Most IT Projects Fail
Why Most IT Projects Fail
- 1. Why Most ITProjects Fail
- 2. How Projects ReallyWork 1/21/2013
- 3. How the customerexplained it 1/21/2013
- 4. How the projectleader understood it 1/21/2013
- 5. How the analystdesigned it 1/21/2013
- 6. How the programmerwrote it 1/21/2013
- 7. How the businessconsultant described it 1/21/2013
- 8. How the projectwas documented 1/21/2013
- 9. How much theproject cost 1/21/2013
- 10. What the customerreally needed 1/21/2013
- 11. 1995 – TheCHAOS 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 firststudy - 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 BigIT 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 BigIT 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. 1994 1996 1998 2000 2002 2004 2006 2008 Successful 16% 27% 26% 28% 34% 29% 35% 32% Challenge d 53% 33% 46% 49% 51% 53% 46% 44% 60% 50% 40% Canceled 30% 31% 40% 28% 23% 15% 18% 19% 24% 20% 10% 0% 1994 1996 1998 2000 2002 2004 2006 2008
- 21. Reasons for Success,'04 - '08 • User involvement • Project manager • Executive expertise management support • Financial management • Clear business • Skilled resources objectives • Formal methodology • Optimizing scope • Standard tools and • Agile process methodology
- 22. What is Agile? Familyof 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 1/21/2013
- 23. What is Agile? Emphasison Customer satisfaction Job satisfaction Removal of things that do not contribute to above 1/21/2013
- 24. 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... 1/21/2013
- 25. Agile Adoption, Forrester2009 Waterfall 13% Agile 35% Iterative 21% No Formal Process 31%
- 26. Aspects of SoftwareDevelopment • Project - No one methodology Management covers all aspects • Engineering - No one methodology • Business Analysis covers all situations • Quality Assurance • User Experience • Others...
- 27. 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
- 28. Some Agile Practices ContinuousIntegration 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
- 29. Are Agile Practicesthe Answer? NO Many organizations have adopted Agile practices with poor results
- 30. Are Agile Practicesthe Answer? Beware of the hype surrounding Agile
- 31. 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?
- 32. Improving the SuccessRate • 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
- 33. Improving the SuccessRate • 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
- 34. The Agile Manifesto Weare 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. 1/21/2013
- 35. 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 1/21/2013
- 36. Some of OurClients Software Development Training & Coaching Both