Standish Research Group 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 fewer materials and
less labor to perform the same task.“ Tom Clancy (The Sum of All Fears)
• Bridges are normally built on-time, on-budget, and do not fall down
• Software “never” comes in on-time or on-budget. It always breaks down.
• Bridge building did not always have such a stellar record – 3,000 years of
experience, failures investigated & reported.
• Computer industry failures are covered up, ignored, and/or rationalized. – mistakes
repeated over and over again.
Project Success: Type 1. The project is completed on-
time and on-budget, with all features and functions as
initially specified. (2000: 28%)
Project Challenged: Type 2. The project is completed
and operational but over-budget, over the time
estimate, and offers fewer features and functions than
originally specified. (2000: 49%)
Project Impaired: Type 3. The project is canceled at
some point during the development cycle.
(2000: 23%) (Are ALL impaired projects failures???)
One notable exception – Millenium Bridge in London.
Project Success Factors % of Responses
1. Executive Support 18%
2. User Involvement 16%
3. Experienced Project Manager 14%
4. Clear business objectives 12%
5. Minimized scope 10%
6. Standard software infrastructure 8%
7. Firm basic requirements 6%
8. Formal methodology 6%
9. Reliable estimates 5%
10. Other 5%
Project Challenged Factors % of Responses
1. Lack of User Input 12.8% Project managers were
2. Incomplete Requirements & Specifications 12.3% asked to identify the
3. Changing Requirements & Specifications 11.8% most influential
4. Lack of Executive Support 7.5%
5. Technology Incompetence 7.0% factors in both
6. Lack of Resources 6.4% successful and
7. Unrealistic Expectations 5.9% challenged projects.
8. Unclear Objectives 5.3%
9. Unrealistic Time Frames 4.3%
Materials taken from:
10. New Technology 3.7%
Case-Studies – conducted by the Standish Research Group
California DMV 1987-1993 project to revitalize their
drivers license and registration application process. By
1993, after $45 million the project was cancelled.
(No monetary payback, no IT buy in)
American Airlines 1994, a $165 million car rental and
hotel reservation system (CONFIRM) involving American
Airlines, Budget Rent-A-Car, Marriott Corp. and Hilton Hotels
collapsed in chaos. (Too many cooks!)
Hyatt Hotels Confirmation System - dial from a cellular
airplane telephone at 35,000 feet, check into your Hyatt hotel
room, schedule the courtesy bus to pick you up, and have your
keys waiting for you at the express desk – all for under $15 million.
Banco Itamarati A year after a strategic redirection, Banco
Itamarati, a privately-held Brazilian bank, produced an annual net
profit growth of 51% and moved from 47th to 15th place in the
Brazilian banking industry. Technology was a key component of
their business strategy.
Materials taken from: http://standishgroup.com
“If you don’t actively attack
the risks, they will attack
“Today no one has the luxury
of getting to know a task so
well that it holds no surprises,
and surprises mean risk”.
A little risk
management goes a
The risk may or may not
What is the impact of the
risk if it does occur?
Project risks budgetary, schedule, personnel staffing and organization, resource,
customer, and requirements problems.
Technical risks - risks that threaten the quality and timeliness of the software to
be built. (design, implementation, interfacing, verification, maintenance)
Business risks - risks that threaten the viability of the software to be built.
Calculating Risk Exposure
Risk of not delivering on time:
RE = Probability of Risk X Impact of Risk
Probability that only 70% of the software components
scheduled for reuse will in fact be integrated into the
Risk that this will mean that the software cannot be
delivered on time = 30%
RE = 70% X 30% = 21%
Don’t hide from project risk.
Face it head on!
Risk is managed in respect to a specific goal.
What is the risk in respect to the goal?
A clearly defined goal with measurable success criteria
bounds acceptable risk.
That which we do not know.
We can only be certain that the probability of a risk
occurrence is > 0% and < 100%.
Unless there is a potential for loss there is no risk.
Loss can be a bad outcome or a lost opportunity.
Time is a consumable resource. As time goes by viable
options tend to decrease. By managing risk we reduce wasted
time by using it to our advantage.
Without choice there is no risk management.
Doing something or doing nothing should be a consciencious
Make intelligent decisions:
- based on awareness, insight, and understanding of risk. Risk
management provides a process to communicate risk
information and provide visibility into software risks at all
Develop & execute a risk action plan to resolve risk.
Key is to find risk when there is still time to take action, &
knowing when to accept a risk.
Resolution of software risk prevents problems and surprises.
Risk Mitigation Plan
What are you going to do
about the risk?
Entirely remove the risk by
Reduce the probability of the
Reduce the impact if it does
A risk analysis
Risk mitigation plan.
Sample Risk Table
RMMM = Risk Mitigation, Management, and Monitoring plan
Risk Category Prob. Impact Risk Exp.
Are the best
people staff 55% catastrophic
people staff 63% critical
staff 25% marginal
Is a SW
management environment 40% negligible
1-Catastrophic, 2-Critical, 3-Marginal, 4-Negligible
Risk averse people: Risk seeking people:
I like being dependable and I’m I like action, and I act
usually punctual. impulsively at times.
I am not likely to take chances. I seek excitement for the thrill of
I am responsible and prefer to the experience.
work efficiently. I am resourceful and prefer not
I am more service oriented than to plan or prepare.
self oriented. I am more self oriented than
I value institutions and observe service oriented.
traditions. I like to anticipate another
Risk neutral people:
I trust my intuition, and I am comfortable with unknown.
I think about the future and have long-range objectives.
I am naturally curious and often ask, “Why?”
I enjoy generating new ideas.
I work best when I am inspired.
Identify risks for your project.
Rank each risk according to probability.
Rank each risk according to impact.
1-Catastrophic, 2-Critical, 3-Marginal, 4-Negligible
Order risks according to Risk Exposure.
Decide which risks you need to mitigate.
Create risk mitigation action items for each of those
Track all identified risks on your website.
During class today you may sign up for a debate topic. Each
group will then pull numbers to decide who will argue on which
side of the debate (for and against).
Each group member must make at least one comment before
anyone is allowed to make more than one comment during the
debate; if you are shy, go first and make one of the obvious points.
Once everyone has spoken once, group members may contribute
at will during the group's turn.
The "floor" will alternate between teams in short intervals,
controlled by the clock.
A good strategy is to know BOTH sides of each question so you
can be prepared not only to carry your own argument, but also
prepared to refute the arguments THEY are likely to make.
Debate # 1: Agile vs. Planned
A. Requirements should be developed upfront so that you can manage
the design of the software product and taking all stakeholders needs into
account. Changes to requirements should then be carefully managed.
B. As change is inevitable, it is a waste of time to specify all the system’s
requirements up front. Agile development which proposes no big upfront
design is much more effective.
Debate # 2: Personable vs. skilled
You have two candidates for a position that is quite critical
technically, and at the heart of a somewhat extensive project. One
person is very knowledgeable, and an outstanding coder, but does not
get along with people, is arrogant, and is not communicative. The
other person is O.K. technically, but a really a super personality
that communicates well, and makes others around her better. In this
case you should just face facts and hire the monster coder.
Debate # 3: Prototyping
Even though you will lose some time, it is better to build a prototype
running system, which is then completely discarded, before building your
final system. This way you can get a feel for both the technology, and for
how the final version should be designed, thus doing a much better job.
This is in contrast with carefully designing, and then implementing, your
system right the first time.
Debate # 4: Value of communication
The idea that excellent communication in a group is necessary is
a myth: what really matters is people getting their job done without a
lot of focus on talking about it.
Debate # 5: Bunch of coders
To get a project completed all you need is a bunch of people who
know how to write code.
Debate # 6: Hackers
Hackers that just snoop around serve a useful purpose, because they
identify weaknesses in a system without doing any permanent harm.
They should not be prosecuted.
Debate # 7: Whistleblowing
As an IT professional, my job is to build whatever software system my
boss requests me to build. If I notice a weakness in the system that could
possibly harm people (such as weak security that might enable personal
information to be exposed), it is certainly not my responsibility to be a
whistleblower. The responsibility for these decisions lies with my boss.
Debate # 8: Outsourcing
As an IT professional in the U.S. I will do everything I can to protect future
IT jobs against being outsourced.
1. Agile vs. Planned
2. Personable vs. skilled
4. Value of communication
5. Bunch of coders
7. Whistle blowers
Each person gets 5 points to ‘vote’ for the debate they want to do. Use
all the points together or spread over various topics.
Debate teams will be announced on Wednesday.