The Internet Encyclopedia (Volume 3)

P1: IML/FFX P2: IML/FFX QC: IML/FFX T1: IML

Management WL040/Bidgoli-Vol III-Ch-19 June 23, 2003 16:22 Char Count= 0

STRATEGIES FORRISKMANAGEMENT 233

weaknesses into account. In this chapter, the two most

popular methods are described. Charette (1989) describes

other methods that might be used.

The Checklist

When managers lack a sufficiently broad experience with

project management, they do not fully trust their own

recognition of potential risks. In such case, a checklist of

potential risks is essential. The checklist is useful for expe-

rienced managers as well, because it serves as a memory

aid. Checklists are often compiled from “lessons learned”

gleaned from analysis at project closeout. One problem

with such checklists is cultural blindness to issues that

may threaten a project. Schmidt et al. (2001) suggested

that a more comprehensive checklist can help overcome

cultural biases that may hinder the recognition of key

risks.

There are two problems with the checklist approach.

First, such a list may not be complete. Second, some risks

on the list may have been overcome by events, making the

list outdated. In the first case, the manager might overlook

important risk factors, and in the second case the manager

might spend valuable time preparing for a contingency

that is not a risk at all.

For some years, Boehm’s (1989) top 10 list was used as

a starting point for risk analysis. By the mid-1990s, sev-

eral independently compiled checklists were available. An

examination of those checklists combined produces 33

distinct risk factors. A study that unified and expanded

the existing checklists presented a list of 53 risk factors

(Schmidt et al., 2001). Table 1 lists the 11 software project

risks deemed most important by the international panel

of experienced project managers polled in that study. Con-

sidering the currency of this unified list, it is not likely to

suffer from the second weakness discussed here, but this

list was compiled based on the experiences of project man-

agers with traditional software projects. For that reason,

it suffers from incompleteness when considering Internet-

based project risk.

Table 1Top Eleven Risks

RANK RISKS

1 Lack of top management commitment to the

project

2 Failure to gain user commitment

2 Misunderstanding the requirements

4 Lack of adequate user involvement

5 Lack of required knowledge or skills in

project personnel

6 Lack of frozen requirements

7 Changing scope or objectives

8 Introduction of new technology

9 Failure to manage end user expectations

10 Insufficient or inappropriate staffing

11 Conflict between user departments

From “Identifying software project risks: An international Delphi

study,” by R. Schmidt, K. Lyytinen, M. Keil, and P. Cule, 2001,

Journal of Management Information Systems, 17, 5–36. Copyright©c

M. E. Sharpe, Inc., 2001. Reprinted by permission.

The discussion of Internet-based project risks in the

preceding section suggests several new risks that should

be added to any checklist a project manager might use.

It also suggests that the likelihood of some previously

known risks’ occurrence should be increased. There is no

guarantee that all eventualities have been taken into ac-

count, however. The project manager needs more than just

a checklist to prepare for risk management.

Brainstorming

The other major approach to risk identification is brain-

storming. This method allows for the recognition of new

and unusual risks that might be uniquely associated with

a given project. Groupware provides an electronic forum

in which brainstorming can be conducted across a wide

group of participants regardless of their geographic or

temporal separation. Special tools are available for cap-

turing, classifying, and winnowing suggested risks to ob-

tain as comprehensive a list as possible.

This method relies completely on the combined expe-

rience of the participants in the brainstorming session. If

the participants lack sufficient experience, it is not likely

that they will have encountered all the common risk fac-

tors, let alone less common risks that might apply to the

project at hand. This is especially true for Internet-based

projects, because most project managers have not had any

experience with this form of project management, and

even the seasoned Internet managers’ expertise cannot

compare with the long experience of traditional project

managers.

General Principles

Thus, it is not likely that a single method of risk iden-

tification will suffice for any given project. The recom-

mended approach is to supplement the checklist with a

brainstorming session to identify potential risks not found

on the checklist. The evaluation period immediately after

brainstorming can help identify listed risk factors that are

not pertinent as well.

After identifying the risks, the project manager must

evaluate each risk in terms of its likely impact on the

project, as well as the likelihood of its occurrence. This

evaluation should be done in coordination with all the

stakeholders in the project. These stakeholders will have

a better appreciation of the expected outcomes for some

risk factors. For others, the project manager should re-

view the records of past projects of a similar nature in

the organization. With this information in hand, the man-

ager can assess the relative expected outcomes of the var-

ious risks. Once this is done, the more serious threats to

the project will have been identified. Next, the manager

will be ready to consider countermeasures for these risks

and prioritization of action based on the relative expected

outcomes.

Planning for Risk Countermeasures

Controlling risks is not a simple matter. Most managers

would like to manage risks through elimination of the risk.

This can be done by removing or countering any factors

that might threaten the project. An examination of the lists

of risk factors given by Schmidt et al. (2001) and found