Why Most IT Projects Fail

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