Your SlideShare is downloading. ×
0
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Why Most IT Projects Fail
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Why Most IT Projects Fail

106

Published on

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

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

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
106
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Why Most IT Projects Fail
  • 2. How Projects Really Work
  • 3. How the customer explained it
  • 4. How the project leader understood it
  • 5. How the analyst designed it
  • 6. How the programmer wrote 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 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. 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, 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. 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 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. 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. The Problem with “Waterfall”Mistakes are hard to find in early stagesChange 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 processesAutomation 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 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. 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. Are Agile Practices the Answer? NOMany 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 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. 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. Some of Our ClientsSoftware Development Training & Coaching Both

×