Page 175 -

146 PART TWO MANAGING SOFTWARE PROJECTS

QUICK a set of risk information sheets is the people, the product, the process, and the proj-
LOOK produced. ect. The RMMM should be revisited as the proj-
How do I ensure that I’ve done ect proceeds to ensure that risks are kept up to
it right? The risks that are analyzed and man- date. Contingency plans for risk management
aged should be derived from thorough study of should be realistic.

Peter Drucker [DRU75] once said, "While it is futile to try to eliminate risk, and
questionable to try to minimize it, it is essential that the risks taken be the right risks."
Before we can identify the "right risks" to be taken during a software project, it is
important to identify all risks that are obvious to both managers and practitioners.

6.1 REACTIVE VS. PROACTIVE RISK STRATEGIES

Reactive risk strategies have been laughingly called the “Indiana Jones school of risk
management” [THO92]. In the movies that carried his name, Indiana Jones, when
faced with overwhelming difficulty, would invariably say, “Don’t worry, I’ll think of
something!” Never worrying about problems until they happened, Indy would react
in some heroic way.
Sadly, the average software project manager is not Indiana Jones and the mem-
bers of the software project team are not his trusty sidekicks. Yet, the majority of
“If you don't actively software teams rely solely on reactive risk strategies. At best, a reactive strategy
attack the risks, they monitors the project for likely risks. Resources are set aside to deal with them,
will actively attack
you.” should they become actual problems. More commonly, the software team does
nothing about risks until something goes wrong. Then, the team flies into action
Tom Gilb
in an attempt to correct the problem rapidly. This is often called a fire fighting mode.
When this fails, “crisis management” [CHA92] takes over and the project is in real
jeopardy.
A considerably more intelligent strategy for risk management is to be proactive.
A proactive strategy begins long before technical work is initiated. Potential risks are
identified, their probability and impact are assessed, and they are ranked by impor-
tance. Then, the software team establishes a plan for managing risk. The primary
objective is to avoid risk, but because not all risks can be avoided, the team works
to develop a contingency plan that will enable it to respond in a controlled and effec-
tive manner. Throughout the remainder of this chapter, we discuss a proactive strat-
egy for risk management.

6.2 SOFTWARE RISKS
Although there has been considerable debate about the proper definition for software
risk, there is general agreement that risk always involves two characteristics [HIG95]: