Software Projects Failure 1

Nightmare on Project X
Restoring Projects in Crisis
Deb Jacobs
Project E“helping
ngineering Technologies
companies help themselves” Project Engineering Technologies
2
Nightmare Projects
A LETTER FROM CAMP
Written by: Allan Sherman and Lou Busch - © 1963
Popularized by: Allan Sherman
Hello Muddah, hello Faddah, Take me home, oh Muddah, Faddah,
Here I am at camp Grenada. Take me home, I hate Grenada.
Camp is very entertaining, Don't leave me out in the forest where,
And they say we'll have some fun if it stops raining. I might get eaten by a bear.
I went hiking with Joe Spivey, Take me home,

He developed poison ivy. I promise I will not make noise,
You remember Leonard Skinner, or mess the house with other boys,
He got Ptomaine poisoning last night after dinner. Oh please don't make me stay,
I've been here one whole day.
All the counselors hate the waiters,
And the lake has alligators. Dearest Faddah, Darling Muddah,
And the head coach wants no sissies, How's my precious little bruddah?
So he reads to us from something called Ulysses. Let me come home if you miss me,
I would even let Aunt Bertha hug and kiss me!
Now I don't want this should scare ya',
But my bunkmate has Malaria. Wait a minute, it's stopped hailing,
You remember Jeffery Hardy, Guys are swimming, Guys are sailing!
They're about to organize a searching party. Playing baseball, gee that's bettah,
Muddah, Faddah kindly disregard this letter!!!
Project E“helping
companies help themselves”
3
Nightmare Projects?
◆ Out of Control Project ◆ IT Fiasco
◆ Project in Crisis ◆ Runaway Systems Project
◆ Project Roadkill ◆ Troubled Project
◆ Disaster Project ◆ Chaotic Project
◆ Project from Hell ◆ Crunch Project
◆ Death March ◆ Mission Impossible Project
◆ Challenged Project
Project E“helping
4
Agenda
Timeline
Why Projects Fail?
Top Ten Signs Your Project is in Crisis
The Road to Project Restoration
Beyond the Nightmare
Process Models
Project Management
Project E“helping
5
Timeline
SOFTWARE ENGINEERING SOFTWARE PROJECT FAILURE AWARENESS TIMELINE
1960’s 1975 1981 1984 1989
Software Engineering
IBMs Fred Brooks, Capers Jones, Institute (SEI) established
Watts Humphrey,
OS/360 The Mythical Man-Month, Programming by Congress to address
software written about the IBMs Productivity -- Issues Managing the
software engineering
Software Process
project OS/360 software project for the Eighties unpredictability and high
failure rate
1991 1995 1997 1997 1998
Initial Standish Group KPMG Survey of

Initial Software Ed Yourdon, Updated Standish
CHAOS Report, Research Unsuccessful Information
Capability Maturity Death March Group CHAOS Report
Paper Regarding Software Technology Projects
Model published
Project failures
Before 1935, the word computer meant a person who

Project E“helping
companies help themselves” calculated in surveying or other related fields.
6
Timeline:
The Mythical Man-Month by Fred Brooks
◆ Written 30 years ago about SW project management
– based on IBMs OS/360 SW project accomplished in the 1960’s
▼ “… software managers often lack the courteous stubbornness of
Antoine's chef.”
– “Good cooking takes time. If you are made to wait, it is to serve you
better, and to please you.” Menu of Restaurant Antoine, New Orleans
▼ “Schedule progress is poorly monitored. Techniques proven and
routine in other engineering disciplines are considered radical
innovations in software engineering.”
▼ “… the man-month as a unit for measuring the size of a job is a
dangerous and deceptive myth. It implies that men and months are
interchangeable.”
◆ Today, we still make the same mistakes
Project E“helping
7
Timeline:
Programming Productivity--Issues for the Eighties
by Capers Jones
◆ 40 articles from the 1970's through 1986 era on
software productivity and quality
◆ “If you can prevent defects or detect and remove
them early, you can realize a significant schedule
benefit. Studies have found that reworking defective
requirements, design, and code typically consumes
40 to 50 percent of the total cost of software
development. “
"If you don’t have time to do the job right,

Project E“helping
where will you find the time to do it over?"
8
Timeline:
Birth of the Capability Maturity Model
◆ Software Engineering Institute was established
by the federal government at Carnegie Mellon
University in Pittsburgh, PA
– Software engineering community lacked a shared view of
the state of practice
– Agreement about what constitutes good practice
– Development activity and resulting products were
unpredictable
– Success or failure was totally dependent on the staff
assigned
Project E“helping
9
Timeline:
Birth of the Capability Maturity Model (CMM)
◆ Managing the Software Process written by
Watts Humphrey
– Introduced and discussed formalizing the maturity
framework which is the CMM we use today
◆ Watts Humphrey founded the Software Process
Program at the SEI
Project E“helping
10
Timeline:
Capability Maturity Model
◆ Capability Maturity Model (CMM): software
process framework
◆ CMM based on:
– knowledge acquired from software process assessments
– extensive feedback from industry and government
◆ Objective:
▼ help organizations achieve sufficient maturity to manage
technology introduction
Project E“helping
11
Timeline:
Initial CHAOS Report
◆ Forward in CHAOS Report:
▼ “The Roman bridges of antiquity were very inefficient structures.
By modern standards, they used too much stone, and as a result, far
too much labor to build. Over the years we have learned to build
bridges more efficiently, using few materials and less labor to
perform the same task.” Tom Clancy (The Sum of All Fears)
– CHAOS research inspired by bridge building approach
▼ where bridge builders learned from the myriad of mistakes,
software developers tend to “cover-up, ignore, and/or rationalize”
their failures
– Moral: Learn from our mistakes
Project E“helping
12
Timeline:
◆ 1995 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
“The project was two years late in development. We had thirty

Project E“helping
people on the project. We delivered an application the user didn’t
companies help themselves” need. They had stopped selling the product over a year ago.”
13
Timeline:
◆ 1995 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 42% 74.2%
Projects challenged 50.4% 61.5%
Projects impaired and subsequently cancelled 21.6% 29.5%
Project E“helping
14
Timeline:
Death March: The Complete Software Developer's Guide to
Surviving "Mission Impossible" Projects by Ed Yourdon
◆ Ed Yourdon widely known as lead developer
of structured analysis/design methods and co-
developer of OO analysis/design methods
◆ Death March
▼ Abstract: “How to survive a programming project
that seems doomed to failure, and how to tell when to
bail out.”
"The dismal track record of software projects is familiar to most

Project E“helping
IT managers, and even most senior corporate managers..."
companies help themselves” - Ed Yourdon
15
Timeline:
KPMG Survey
◆ Failure Project Statistics:

▼ 87% of failed projects exceeded schedule > 30%
▼ 56% of failed projects exceed budget > 30%
▼ 45% of failed projects failed to produce expected
benefits
Project E“helping
16
Timeline:
1998 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 E“helping
17
Why Projects Fail?
Project E“helping
18
Why Projects Fail

◆ 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
▼ Lack of planning
▼ Lack of IT management
▼ Technology illiteracy
Project E“helping
19
Why Projects Fail

◆ 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%)
“The plan is nothing; the planning is everything.”

Project E“helping
companies help themselves” Dwight D. Eisenhower
20
Why Projects Fail

◆ KPMG Study (Canadian-based International
service provider)
– 3 Most Common Reasons for Project Failures
▼ Poor Project Planning
▼ Weak Business Cause
▼ Lack of Top Management Involvement and Support
“What sometimes appears to be the end

Project E“helping
companies help themselves” is really a new beginning”
21
Why Projects Fail

◆ 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
Project E“helping
22
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
Project E“helping
23
1. Lack of Communication
◆ Communication is key to ensure that all stakeholders
understand what is expected
◆ Project Manager (PM) used as crucial interface to all
aspects of a successful project including:
– End Users/Client/Customer End
– Project Staff User
– Executive Management
PM
◆ Project Manager (PM) must be Project
Executive
empowered and possess skills to Staff
Mgt
communicate needs and decisions
Project E“helping
“That’s my story and I’m sticking with it.”
24
2. Inadequate Project
Planning and Management of Plan
◆ Lack of Planning or Inadequate Planning is the
most quoted cause for Project Failure
◆ Management of the Plan is key - planning is an
iterative process
– When plan is OBE, it must be updated
◆ Defining processes is crucial to success
◆ Risk Planning with contingency plans
▼ look for what could go wrong and figure out ways to
alleviate or reduce the impact if they do go wrong
“People don’t plan to fail, they fail to plan!”
Project E“helping
companies help themselves” Anonymous
25
3. Unstable Requirements
◆ Poorly understood and uncontrolled
“requirements creep” are a leading cause of
failure
◆ Many tools are available for managing
requirements both manually and automated
– Recommend that every project use one regardless
of size
◆ Basic Requirements Mgt tasks include:
– gathering, analyzing, documenting and managing
Project E“helping
26
4. Lack of Training/
Mentoring for Managers
◆ Taking a great technical person and putting
them in charge can cause some of the worst
problems on projects
◆ Recommend that each new software
manager be given training, mentoring, or
both in Project Management
– Best proven method is combination of training
and mentoring
When Odysseus made his epic journey across the world, he left one of his best
Project E“helping
friends, Mentor, in charge of the education of his son, Telemachus. Through writings
companies help themselves” such as Odyssey by Homer, the word Mentor has come to mean an advisor.
27
5. Unachievable/
Unrealistic Schedules
◆ Schedules are essential tools for each Project
Stakeholder (a primary tool for PM)
◆ Project’s Critical Path and dependencies must
be understood and tracked diligently
▼ Defined critical path - tell you how far you are actually
behind schedule - more than 25% lag is a good signal of
insurmountable problems
◆ Chunking or breaking large tasks into smaller
more manageable tasks
Deadline: a line or limit that must not be passed
Project E“helping
original meaning - a line drawn around a military prison, beyond which prisoners
companies help themselves” were summarily shot.
28
6. High Turnover in Project Staff

◆ High staff turnover indicative of low moral
leading to project failure
◆ Build a team that works well together
◆ Build confidence and motivation in the team
and keep them focused
– Myriad of methods for attaining that objective
◆ New staff subtract productivity from existing
staff hence keep current staff employed
Brooks' Law: Adding manpower to a late software project
Project E“helping
makes it later.
companies help themselves” Fred Brooks, The Mythical Man-Month
29
7. Inadequate Use of
Outside Resources
◆ “Running leaner than ever, most organizations lack the
technical, strategic and project management skills to
handle the benumbing rate of technological and market
change.” CIO Magazine Oct 15 1998
◆ Outsourcing can:
– provide technical and management expertise without the risk
and expense of a direct hire
– augment staff
◆ Select resources that provide a transfer of knowledge to
existing staff; don’t become too reliant upon one resource
“I want to build sand castles and leave. I don’t want to be there when it
needs to be painted. I want to hand it over and go on to the next one.”
Project E“helping
companies help themselves” Sherry Higgins , Top Gun at Lucent Technologies
30
8. Inadequate Work Environment

◆ Lack of adequate equipment can be detrimental
to a project
– Dissatisfied staff results in lower productivity
– Inability to accomplish tasks
◆ Provide thinking-oriented office space
▼ Each organization must determine most optimal work
environment based on their unique needs
▼ "Peopleware" by Tom DeMarco & Tim Lister: cubicles
hurt your productivity because it’s harder for people to
get enough peace and quiet so they can concentrate
Project E“helping
31
9. Workforce Tied to
Old Technology
◆ “Anyone who has never made a mistake has never
tried anything new.” -- Albert Einstein
◆ The New Generation Gap no longer tied to age
– If staff is too tied to the old, they will never see the benefits
of progressing
◆ Emerging technology is the basis for developing
progressive systems - the cornerstone for today’s
advancements
◆ Managers must walk a fine line between adoption of
new technology and the risk involved
“We can easily forgive a child who is afraid of the dark;
Project E“helping
ngineering Technologies the real tragedy of life is when men are afraid of the light.”
32
10. Lack of Long-term

Commitments
◆ Top Management
– Must be actively involved by providing periodic
review with the Project Manager
– Lack of Top Management Commitment:
▼ lack of adequate resources ($, people, equip,…)
▼ lack of visibility for staff
◆ Program Staff
– High staff turnover
– Low morale
Project E“helping
33
The Road to Project Restoration
Project E“helping
34
The Road to Project

Restoration: Standish Group
◆ Standish Group Top Reasons for Project
Success
– Most successful projects:
▼ > six month timeframe
▼ > six people
▼ > $750,000 cost
– User involvement
– Executive Support
– Experienced Project Management
– Clear Business Objectives
– Good Communications
Project E“helping
35
The Road to Project Restoration:

Capers Jones’ Essential Attributes
◆ “...there are myriad ways to fail when building large software systems. There
are only a very few ways to succeed. All of the paths that lead to successful
software have these twelve essential attributes…” Software Quality --
Analysis and Guidelines for Success, Capers Jones
◆ Capers Jones 12 Essential Attributes For Successful Software:
1. effective project planning 7. effective development processes
2. effective project cost estimating 8. effective communications
3. effective project measurements 9. capable project managers
4. effective project milestone tracking 10. capable technical personnel
5. effective project quality control 11. significant use of specialists
6. effective project change management 12. substantial volumes of reusable material
◆ Software project management has been one of the most demanding jobs of
the twentieth century. In the twenty-first century, there are indications that
the difficulties of project management will grow even more taxing.
Project E“helping
36
The Road to Project Restoration:

Steve McConnell’s Ten Essentials
◆ Software’s Ten Essentials (he compared
software to hikers & developed this list):
1. Product Specification - software project’s compass
2. Detailed User Interface Prototype - captures look and feel of product
3. Realistic Schedule - essential planning foundation
4. Explicit Priorities - essential features
5. Active Risk Management - prepare for and actively attack risks
6. Quality Assurance Plan - helps in correcting defects early
7. Detailed Activity Lists - schedule for comparing planned vs actuals
8. Software Configuration Management - manages code include backups
9. Software Architecture - promotes consistent design & implementation
10. Integration Plan - alleviates much of the integration nightmare
Project E“helping
37
Beyond The Nightmare:

Road to Restoration
1. Build a Task Force
2. Analyze the Issues
3. Determine the Problem
4. Fix the Problem
5. Monitor Project
6. Start Over, if needed
Project E“helping
38
Road to Restoration:
Build A Task Force
◆ Task Force = team of people charged with
determining and correcting problems
– Keep task force small
▼ Size can be one or more persons, dependent on:
– scope of project and problems
– expertise and experience of team member(s)
– Selecting right members critical to success
▼ Wrong team members can cause more problems on
the project
– give authority to make changes needed
“Too few people on a project can't solve the problems - too
Project E“helping
ngineering Technologies many create more problems than they solve.”
39
Determining What Went Wrong?
◆ Each organization is unique; however, study
after study found that each organization’s
failure projects follow a similar path
◆ Search for the “real” problems/issues
– Go below the surface
◆ Examine the mistakes
– Don’t finger point!!!
◆ Apply Lessons Learned
“How does a project get to be a year late?... One day at a time.”
Project E“helping
40
What Can you Do To Fix It?
◆ Decrease/Limit Scope of Project
◆ Use Modular, Build, Iterative, or Chunking Approach
◆ Revise Your Plan, Don’t Just Throw It Out
◆ Understand your Requirements
◆ Improve Training
◆ Get Buy-in From Staff, Users, and Executive Managers
◆ Capture/Deploy your Project’s Processes
“THE PROBLEM with doing nothing is not knowing when you’re finished. “
Project E“helping
Benjamin Franklin (1706-1790)
41
Decrease/Limit Scope of Project
◆ Project success is inversely proportional to
size (The Standish Group CHAOS 1998)
– > $750,000 = 55% success rate Project Success Based on Project Size
– $1M - $2M = 18% success rate 60
– $5M - $10M = 7% success rate 50
40
30
20
10
0
Project E“helping
> $750,000 $1M-$2M $5M-$10M
42
Use Modular, Build, Iterative, or
Chunking Approach
◆ Break the project into small workable chunks
◆ Replanning a project can have a significant positive
impact
◆ Instituting an incremental build methodology has
proven to bring projects in line
– allows for building a strong infrastructure then adding functionality
incrementally to ensure that it all works well together
Project E“helping
"If there is a better solution...Find it." -Thomas Edison
43
Revise your plan, don’t just throw it out
◆ Planning is an iterative process
◆ Schedules must be periodically updated to reflect the
current state of the project
◆ Team-involved plan - Project team must own plan
◆ Always have a contingency plan for potential risks
◆ NEVER abandon the plan when the pressure is turned
up, that’s when you need it most to keep track
– Don’t let your project fall into the code-and-fix mode
“IT IS BETTER to look ahead and prepare than to look back and regret.”
Project E“helping
JACKIE JOYNER-KERSEE, Olympic track and field champion
44
Understand your Requirements
◆ Fully understand each requirement
◆ Ensure that project staff and users agree on their
understanding of each requirement
◆ Control “requirements creep”
– Manage changes to requirements
– Obtain management approval for any added
requirements
◆ Start by documenting the requirements
I know that you believe that you understand what you think I said but I
Project E“helping
am not sure you realize that what you heard is not what I meant.
45
Improve training
◆ “We’re known for our on-the-job
training.”
◆ “Only an idiot would needs training.”
WRONG WRONG WRONG
◆ There’s always room for more training.
◆ Train your engineers, train your managers, train
your users!!!
Project E“helping
46
Project E“helping
47
Get buy-in from staff, users, and
executive managers
◆ All project stakeholders must:
Walk the Talk
◆ At critical phases, you need everyone pulling
together from the same sheet of music
◆ Project Manager is key to playing the interface in
making this happen
Project E“helping
“None of us are as strong as all of us.”
48
Capture/Deploy your Project’s Processes
◆ There are NO silver bullets
– no lose weight without exercise or magic diet
formulas
◆ Changing project’s/organization’s culture is key
◆ Allow engineers to engineer and manager’s to
manage by giving them the tools they need
◆ Start with what you do already and make it better
“WHEN PEOPLE are highly motivated, it's easy to accomplish the
Project E“helping
ngineering Technologies impossible. And when they're not, it's impossible to accomplish the easy.”
49
Process Models
◆ Several Process Models Available:
– SW-CMM
▼ Software Capability Maturity Model - developed by the Software
Engineering Institute at Carnegie Mellon University
– ISO
▼ Series of international standards used to ensure or at least enhance
the quality of all products from manufacturing of products to
development of products
– SPICE
– SIX SIGMA
– etc.
Project E“helping
50
Project Management
◆ Research shows that Project Management
is the Key to Successful Projects
– Proactive Project Management Approach
▼ Project Planning
▼ Risk Management
▼ Project Tracking and Measurement
▼ Requirements Management
▼ Communications
“Make a decision! Make a decision! People are dying all around you!”
Christopher P. Higgins (based on his Army experience),
Project E“helping
companies help themselves” Bank of America National Manager Currency Services
51
Project Management
Colin Powell's Rules of Leadership
1. It ain't as bad as you think it is. It will look better in the morning.
2. Get mad, then get over it.
3. Avoid having your ego so close to your position that, when your
position falls, your ego goes with it.
4. It can be done!
5. Be careful what you choose. You may get it.
6. Don't let adverse facts stand in the way of a good decision.
7. You can't make someone else's choices. You shouldn't let someone
else make yours.
8. Check small things.
9. Share credit.
10. Remain calm. Be kind.
11. Have a vision. Be demanding.
12. Don't take counsel of your fears or naysayers.
13. Perpetual optimism is a force multiplier.
From Leadership...with a human touch, (March 9, 1999). Copyright © 1999, The Economics Press, Inc.,
Fairfield, NJ 07004 USA. All rights reserved.
Project E“helping
52
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
Project E“helping
53
Contact Information
Questions, Comments, Suggestions, or Just Want to Talk:
Project E“hengine ering Associates

lping companies help themselves”
Deb Jacobs
Project Engineering Management
Professional Consultant
13410 South 32nd Court
Bellevue, NE 68123 www.projectengineeringtech.com
402.293.9215 debjacobs@projectengineeringtech.com
Project E“helping

Software Projects Failure 1

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Projects Failure 1

Uploaded by

Copyright:

Available Formats

Nightmare on Project X

Restoring Projects in Crisis

I went hiking with Joe Spivey, Take me home,

1991 1995 1997 1997 1998

Initial Standish Group KPMG Survey of

Before 1935, the word computer meant a person who

"If you don’t have time to do the job right,

“The project was two years late in development. We had thirty

SMALL VS LARGE COMPANIES SUCCESS RATES

"The dismal track record of software projects is familiar to most

◆ Failure Project Statistics:

Why Projects Fail?

Why Projects Fail

Why Projects Fail

“The plan is nothing; the planning is everything.”

Why Projects Fail

“What sometimes appears to be the end

Why Projects Fail

Top Ten Signs

6. High Turnover in Project Staff

8. Inadequate Work Environment

10. Lack of Long-term

The Road to Project Restoration

The Road to Project

The Road to Project Restoration:

The Road to Project Restoration:

Beyond The Nightmare:

– $5M - $10M = 7% success rate 50

Project E“hengine ering Associates

You might also like