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
232 RISKMANAGEMENT ININTERNET-BASEDSOFTWAREPROJECTSany changes in the business or political environment will
be missed. For example, a change in upper-level leader-
ship might result in changes in business strategy or or-
ganizational culture. The project as originally designed
might not support the new strategic direction. The project
also might continue along lines that are no longer polit-
ically acceptable. Even worse, the delivered system is at
risk of poor alignment with the organizational culture, so
when it is delivered it might not be used.Technology
Technological risk is not new to software project manage-
ment. Half of Boehm’s (1989) top 10 risks were related to
technology. But over the years, as reliability of computing
technology and sophistication of the user interface have
increased, the perception of risk associated with technol-
ogy has decreased dramatically (Schmidt et al., 2001).
In Internet-based projects, however, there is an increased
risk associated with the use of technology to support the
actual development process. Most of the technology de-
signed to support Internet-based project management is
less than three years old. Although there have been many
studies of the use of groupware to support system de-
velopment, using this technology across organizations in
complex projects is not well understood. The majority of
project managers have only limited experience and train-
ing with the new software and are only just beginning
to understand the organizational dynamics of Internet-
based projects.Project Management
A different kind of project manager might be required
for Internet-based projects. Internet-based projects tend
to be more complex and under increased time pressure
(Gilbert, 2000; Highsmith, 2000). Complexity arises not
in the software development tasks, but in the coordina-
tion of activities with geographically and temporally dis-
persed team members, client management, and users.
Time pressure arises through two phenomena. First, the
users expect faster development because the use of In-
ternet technology appears speedier than other means of
communication. This is actually an unrealistic expecta-
tion (Ash, 1998). Rapidly communicating a requirement
does not mean that the code satisfying the requirement
will be written faster. Second, the startup time for an
Internet-based project is longer because of the need for a
period of training and orientation in use of the supporting
software before actual work can proceed. So team mem-
bers are under pressure to perform at a rate beyond their
capability.
The Internet-based project is not just a traditional
project on steroids. Because of the different ways of
handling relationships with users and client manage-
ment, the different supporting software, and the differ-
ent way of managing the workflow, the skills demanded
of the project manager are radically altered from those
of traditional projects. Adequate techniques for manag-
ing Internet-based projects have not been developed or
taught, and new methodologies especially designed for
Internet-based projects are still being tested. Project man-
agement still has the potential to be a significant source of
risks.Project Team
If the project manager is not well prepared, how can
the project team be prepared? Changes in personnel or
staffing levels can have a wrenching effect on traditional
projects. With Internet-based projects, such changes are
more difficult to handle because the team members are of-
ten in different locales. Thus, bringing a new team mem-
ber up to speed on the project is difficult. Also, because
team members outside the organization are utilized, key
personnel support resources may be difficult to access or
nonexistent. Team members can become disheartened or
disgruntled.
Because the project team is often pulled together us-
ing members at a distance from each other, their inter-
personal relationships are tenuous at best. They lack the
cohesiveness of a team that works together with daily
“face time.” Also, because they are remote from the project
manager, there is an increased risk that other duties and
activities may draw part of their time or attention, slowing
project execution (Ash, 1998).STRATEGIES FOR RISK MANAGEMENT
As mentioned in the introduction to this chapter, risk
management is divided into two stages: assessing risk
and controlling risk. The most difficult step in the first
stage is identifying the risks that pertain to the project at
hand. Historically, two methods have been favored for this
task. The checklist method makes use of a list of poten-
tial risks. The brainstorming method relies on interactive
input from experienced project managers and team mem-
bers.
Once the appropriate risks have been identified, the
project manager must take these risks into account when
making project plans. Countermeasures should be devised
in advance to minimize the damage of a negative outcome
or to take advantage of a favorable outcome in the event
one of the anticipated risks is triggered by events. The
choice of countermeasures depends on an understanding
of the risks in terms of a general classification. By recog-
nizing the type of risk to be dealt with, specific strategies
can be chosen that target the source of the risk. There are
two principle means of countering risk. First, the manager
may plan a project in such a way as to minimize the oc-
currence of certain risks. Second, when such planning is
not possible, the manager might prepare specific actions
to be taken in the event that a particular risk is triggered.
Another approach might be to seek ways to hedge against
particular risks that cannot be resolved by action (Kumar,
2002). For more complicated eventualities, the manager
might develop scenarios that help the team understand
what to do in the event certain circumstances occur (Ahn
& Skudlark, 2002).Recognizing Risks
To identify the risks associated with a particular project,
the project manager must first be able to recognize risks.
That is, the manager needs to know what the typical
risks are. Each of the methods for risk identification has
strengths and weaknesses in this regard. When choosing
a method, the manager must take these strengths and