why most it projects fail
DESCRIPTION
My presentation at the ComputerWorld Executive Briefings on Business Agility on January 19, 2013.TRANSCRIPT
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”Successful”–On time, on budget, all features
• ““Challenged”Challenged”–Completed but over-budget, over time estimate,
missing features
• ““Impaired”Impaired”–Canceled
Result of first study - 1994 data
SuccessfulSuccessful16%16%
ChallengedChallenged53%53%
CanceledCanceled31%31%
Reasons for Challenged/Canceled, 1994
Lack of User Involvement
Incomplete Requirements
Changing Requirements
Lack of Executive Support
Unrealistic Expectations
Unrealistic Time Frames
Lack of Planning
Project No Longer Needed
Lack of Resources
Lack of Competence with Technology Used
Reasons for Success, 1994 User InvolvementUser Involvement
Executive Management Support
Clear Statement of Requirements
Proper Planning
Realistic Expectations
Smaller Project Smaller Project MilestonesMilestones
Competent Staff
OwnershipOwnership
Clear Vision & Objectives
Hard-Working, FocusedFocused Staff
How Are Big IT Projects Run?
IT is left to ITLack of involvement by stakeholders
Matrix organizationsPeople 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 requirementsStakeholders will ask for the moon
Documentation so voluminous that often inconsistent & conflicting
• Thick documentation = false sense of confidence
Business outcomes poorly/not definedLack 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%
1994 1996 1998 2000 2002 2004 2006 2008
0%
10%
20%
30%
40%
50%
60%
Reasons for Success, '04 - '08
• User involvement
• Executive management support
• Clear businessbusiness objectives
• Optimizing scope
• Agile processAgile process
• Project manager expertise
• Financial management
• Skilled resources
• Formal methodology
• Standard tools and 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 onCustomer satisfaction
Job satisfaction
Removal of things that do not contribute to above
What is Agile?
CultureValues and attitude of people involved are just as
important as processes
Automation for Quick FeedbackAutomated tests, code quality metrics, acceptance
criteria, automated build & deployment...
Agile Adoption, Forrester 2009
AgileAgile35%35%
No Formal ProcessNo Formal Process31%31%
IterativeIterative21%21%
WaterfallWaterfall13%13%
Aspects of Software Development
• Project Management
• Engineering
• Business Analysis
• Quality Assurance
• User Experience
• Others...
- No one methodology covers all aspects
- No one methodology covers all situations
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 PracticesAgile Practices the Answer?
NO
Many organizations have adopted Agile practices with poor results
Are Agile PracticesAgile Practices the Answer?
Beware of the hypehype 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 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 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 Agile at OrangeOrange & & BronzeBronzeBeen doing Agile since its foundation in 2005Been doing Agile since its foundation in 2005
Before it became mainstreamBefore it became mainstream
We've tried different methodologies and practicesWe've tried different methodologies and practicesXP, Scrum, Kanban, Lean...XP, Scrum, Kanban, Lean...
Not all practices work in all conditionsNot all practices work in all conditions
The first to offer The first to offer training & coaching in Agiletraining & coaching in Agile methodologies and practicesmethodologies and practicesScrum, TDD, Agile Business Analysis, Agile QA, etcScrum, TDD, Agile Business Analysis, Agile QA, etc
Trainers/coaches are seasoned practitionersTrainers/coaches are seasoned practitioners
Officers & architects speak at Agile conferences Officers & architects speak at Agile conferences here and abroadhere and abroad
Some of Our ClientsSome of Our Clients
Software DevelopmentSoftware Development Training & CoachingTraining & Coaching
BothBoth