Page 187 -

158 PART TWO MANAGING SOFTWARE PROJECTS

well underway and a number of people announce that they will be leaving. If the mit-
igation strategy has been followed, backup is available, information is documented,
and knowledge has been dispersed across the team. In addition, the project manager
may temporarily refocus resources (and readjust the project schedule) to those func-
tions that are fully staffed, enabling newcomers who must be added to the team to
“get up to speed.” Those individuals who are leaving are asked to stop all work and
spend their last weeks in “knowledge transfer mode.” This might include video-based
knowledge capture, the development of “commentary documents,” and/or meeting
with other team members who will remain on the project.
It is important to note that RMMM steps incur additional project cost. For exam-
ple, spending the time to "backup" every critical technologist costs money. Part of
If RE for a specific risk risk management, therefore, is to evaluate when the benefits accrued by the RMMM
is less than the cost of steps are outweighed by the costs associated with implementing them. In essence,
risk mitigation, don’t the project planner performs a classic cost/benefit analysis. If risk aversion steps for
try to mitigate the risk
but continue to high turnover will increase both project cost and duration by an estimated 15 per-
monitor it. cent, but the predominant cost factor is "backup," management may decide not to
implement this step. On the other hand, if the risk aversion steps are projected to
increase costs by 5 percent and duration by only 3 percent management will likely
put all into place.
For a large project, 30 or 40 risks may identified. If between three and seven risk
management steps are identified for each, risk management may become a project
in itself! For this reason, we adapt the Pareto 80–20 rule to software risk. Experience
indicates that 80 percent of the overall project risk (i.e., 80 percent of the potential
for project failure) can be accounted for by only 20 percent of the identified risks. The
work performed during earlier risk analysis steps will help the planner to determine
which of the risks reside in that 20 percent (e.g., risks that lead to the highest risk
exposure). For this reason, some of the risks identified, assessed, and projected may
not make it into the RMMM plan—they don't fall into the critical 20 percent (the risks
with highest project priority).

6.7 SAFETY RISKS AND HAZARDS

Risk is not limited to the software project itself. Risks can occur after the software
has been successfully developed and delivered to the customer. These risks are typ-
ically associated with the consequences of software failure in the field.
In the early days of computing, there was reluctance to use computers (and soft-
ware) to control safety critical processes such as nuclear reactors, aircraft flight con-
trol, weapons systems, and large-scale industrial processes. Although the probability
of failure of a well-engineered system was small, an undetected fault in a computer-
based control or monitoring system could result in enormous economic damage or,
worse, significant human injury or loss of life. But the cost and functional benefits of