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

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 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