Why Projects Fail…

And what to do about it!

ODTUG Conference 2004
Co-authors
Dave Kempson, PMP
Dan Kwit, PMP
According to Scott Adams
 Top 10 ways to Guarantee the Failure
of a Systems Project
Dulcian, Inc.

1. Don’t use a specific methodology because

coding is all that is really important.
2. Create the project plan by working backwards
from a drop-dead system completion date.
3. Don’t bother with a data model. Just build
whatever tables you need.
4. Use a technical lead that has never built a
similar system.
5. Hire forty developers to make coding go faster.
 Top 10 ways to Guarantee the Failure
of a Systems Project
Dulcian, Inc.

1. Build the system in Java, even though most of the

development team still thinks Java is coffee and you
have no intention of ever deploying to the web.
2. Three months before the system goes live, assign one
junior developer to handle the data migration.
3. Skip the testing phase because the project is way
behind schedule
4. Change the system to support critical new
requirements discovered during final development.
5. Buy a commercial off-the-shelf package and customize
it…a lot.
Agenda

• Introduction
• Project Failures
– What the research shows
– Personal experience
• What we can do about it
• Wrap-up
 Nightmare Projects?

• Out of Control Project • Fiasco

• Project in Crisis • Runaway Project
• Project Roadkill • Troubled Project
• Disaster Project • Chaotic Project
• Project from Hell • Crunch Project
• Career Killer • Mission Impossible Project
• Challenged Project • Doomed Project
 Top Ten Signs
Your Project is in Crisis
1. Lack of Communication
2. Inadequate Project Planning and Management of Plan
3. Unstable Requirements
4. Lack of Training/Mentoring for Managers/Leads
5. Unachievable/Unrealistic Schedules
6. High Turnover in Project Staff
7. Inadequate Use of Outside Resources
8. Inadequate Work Environment
9. Workforce Tied to Old Technology
10. Lack of Long-term Commitments
 Top Ten Signs
Your Project is in Crisis

1. Poor Communication
2. Inadequate Project Planning and Management of Plan
3. Unstable Requirements/Lack of Change Control
4. Lack of Training/Mentoring for Managers/Leads
5. Unachievable/Unrealistic Schedules
6. High Turnover in Project Staff
7. Inadequate Use of Outside Resources
8. Excessive infighting/finger pointing
9. Workforce Tied to Old Technology/Competence Deficiency
10. Inadequate executive buy-in/Lack of Long-term Commitments
Why do Projects Fail?
 Project Failure Research

• 1994 Standish Group “CHAOS Report” Results:

• U.S. spends $250,000/yr on IT development on
approximately 175,000 projects
• 31.1% of projects canceled prior to completion
• 52.7% cost 189% of estimate
• Cost of failures and lost opportunities cost trillions of
dollars each year
• Only 16.2% of projects completed on-time & on-budget
 Project Failure Research

• 1994 CHAOS Report Results:

SMALL VS LARGE COMPANIES SUCCESS RATES

Small Large
Statistic Company Company
% %
On-time and on-budget/Successful 28% 9%
Original features and functions 74.2% 42%
Projects challenged 50.4% 61.5%
Projects impaired and subsequently cancelled 21.6% 29.5%
 Project Failure Research

• 1988 CHAOS Report

– Study of 7500 IT projects by the Standish Group
– 72% of IT projects come in late, over budget, or not at
all
• 28% of IT projects are cancelled or never implemented
• out of the rest 46% are behind schedule, over budget, or
both
 Project Failure Research

• Standish Group Top Reasons for Project Failures

• Incomplete requirements & specifications
• Lack of user input
• Lack of resources
• Unrealistic expectations
• Lack of executive support
• Changing requirements and specifications
• Technology Incompetence
• Unclear Objectives
• Unrealistic Time-frames
• New Technology
 Project Failure Research

• OASIG Study (1995)

– 8 of 10 projects fail
– Contributors
• Poor management/project management
• Poor articulation of user requirements
• Inadequate attention to business needs and goals
• Failure to involve users properly
• InformationWeek surveyed IT managers
– Top 3 Reasons for Project Failure
• Poor Planning or Poor Project Management (77%)
• Change in Business Goals During Project (75%)
• Lack of Business Management Support (73%)
 Project Failure Research

• KPMG Study (1997)

– 87% of failed projects exceeded schedule > 30%
– 56% of failed projects exceed budget > 30%
– 45% of failed projects failed to produce expected
benefits

– 3 Most Common Reasons for Project Failures

• Poor Project Planning
• Weak Business Cause
• Lack of Top Management Involvement and Support
 Project Failure Research
• Management’s Seven Deadly Sins Why Projects
Fail - Gopal Kapur, president of the Center for Project Management (CPM):
1. Mistaking half-baked ideas for viable projects
2. Dictating unrealistic project schedules
3. Assigning under-skilled project mangers to high-complexity
projects
4. Not ensuring solid business sponsorship
5. Failing to break projects into manageable “chunks”
6. Failing to institute a robust project process architecture
7. Not establishing a comprehensive project portfolio to track
progress of ongoing projects
 Personal Experience

• Projects fail because no one did anything to

prevent it!
• Natural tendency to hide bad news.
• Good, open communication must be present.
• Project management is essential and proven PM
methodologies should be followed to minimize
failure.
Project Management
Morgan W. McCall, Jr., Ph.D. - PM Flaws
that Bring Career’s to Screeching Halt:
The 10 Killer Flaws:
1. Insensitivity
2. Acting aloof
3. Betraying trusts
4. Overmanaging
5. Being overly ambitious
6. Inability to think long term
7. Inability to adapt to a new manager
8. Overdependency on a mentor
9. Making poor staffing decisions
10. Inability to deal with department's performance problems
 Cost of Correcting an Error
Oracle Corp.

Project Life Cycle

Strategy 1x
Analysis 5x
Design 50x
Build 100x
Transition 500x
Production 1000x
Source: Oracle Corporation
What to do about it?
 PMI Process Groups

• Projects commonly fail at different stages for

different reasons. The Project Management
Institute defines 5 major process groups that
constitute a typical project.
– Initiating
– Planning
– Executing
– Controlling
– Closing
 Initiation Phase

Initiation is recognizing that a project should begin and

committing to do so
 Initiation Phase

• Executive buy-in
– Buy-in and involvement crucial especially for projects that cross
organizational boundaries
– Must be prepared for setbacks to respond and demonstrate support.
– Must buy-in to methodology and encourage it to become part of the
organizations culture
• Organizational Culture (Tom Mochal 7/2/03)
– Process Orientation
– Governance
– Training
• Business Driven
– Not IT driven
– Should support vision and mission
– Portfolio Management system to allocate resources based upon business
priorities
 Initiation Phase

• Overall Vision
– Big picture of how one project relates to another
– Architectural vision
– Clear communication of the vision
• Limited Scope
– Compromise of wants and needs matched against capability.
– Manageable chunks
• Technical and Business Requirements
– In accordance with scope
– Agreed upon and formally accepted by both business units and
IT
– No deviations without formal change management.
– Use manual or automated tools for documenting and managing
 Planning Phase

Planning is devising and maintaining a workable

scheme to accomplish the business need that the
project was undertaken to address
 Planning Phase

• Well defined roles

– Project manger, team members, and stakeholders
• Project org structure
– Who is accountable to who?
– Recommend creating an org chart for the project
– Remove ambiguity with regards to communication,
responsibility and information flow.
• Team member competencies
– Make sure the right people are assign to the right
tasks
 Planning Phase

• Understanding of data quality issues and

constraints
– Often overlooked & underestimated.
– Often the most complex and resource intensive
project deliverable
• Methodologies, standards and processes
– Critical for repeatable success
– PMBOK, SEI CMM
 Execution and Control Phases

Executing is coordinating people and other resources to carry out

the plan

Controlling is ensuring that the project objectives are met by

monitoring and measuring progress and taking corrective actions
when necessary.
 Execution and Control Phases

• Communication
– Poor communication is one of the most common root causes of
failure
– Must be evident at all levels and directions
– False assumptions are common
– Executive sponsors must be seen and heard and ask the right
questions.
– Avoid a “no news is good news” mentality
– Project leaders should be the communications hub
– Style is important (positive and upbeat)
– Don’t hide bad news, present it as a challenge to the team
– Remain honest in reporting
– Have a plan!
– Utilize tools (Tracking logs, dashboards, regular reports, etc)
 Execution and Control Phases

• Clear process for change management

– Avoid “Gold Plating”
– Change has a cost and must be managed (not frozen)
– Involve all stakeholders
– Have a well documented process for change control
• Performance measures
– Measure and publish to encourage excellence
– Measure performance against baseline cost and schedule
– Measurement helps identify early warning signs
– Improves morale by reinforcing accomplishments
– Helps establish confidence and trust in the team
 Closure Phase

Closing is formalizing acceptance of the project or

phase and bringing it to an orderly end.
 Closure Phase

• Customer support strategy

– Why capitalize a project if you aren’t going to
operationally fund it?
• Training
• Support
• Maintenance
• Enhancements
– Be careful not to outsource your corporate knowledge
– Hot Wash/Lessons Learned (non retribution)
 Wrap Up

• Most successful projects:

– Concise Scope
• < six month timeframe
• < six people
• < $750,000 cost
– User involvement
– Well defined processes/methodologies
– Executive Support and Commitment
– Experienced Project Management
– Competent Team Members
– Clear Business Objectives & Vision
– Good Communications
Questions?

David J Kempson
Chief Information Officer
Arizona Department of Environmental Quality

djk@ev.state.az.us
602-771-4810