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
230 RISKMANAGEMENT ININTERNET-BASEDSOFTWAREPROJECTSits magnitude must be accounted for. The product of the
magnitude and probability is calledexpected outcome.The
first alternative promises a positive expected outcome of
$150,000 ($1 million×15%), or a negative expected out-
come of $42,500 ($50,000×85%). The second alternative
could lead to a positive expected outcome of $495,000 or
a negative expected outcome of only $30,000. So despite
appearances, the second alternative is less risky.
For this reason, risk is evaluated based on the prod-
uct of the magnitude of an outcome and its probability
of occurrence. A risk factor is any event that embodies
risk. Risky alternatives have both positive and negative
expected outcomes, and both must be considered when
evaluating the risk. This approach to evaluating software
project risk is strongly advocated by Charette (1989). Sur-
prisingly, practicing managers often overlook these facts.Risk as Viewed by Practicing Managers
There are two important biases affecting risk evalua-
tion that have been observed among practicing managers.
First, managers act as if they are evaluating only the mag-
nitude of a loss, without considering the probability of
the loss. Their focus is on the loss, not the potential gain,
because risk carries a negative connotation to them. As
a result, their ranking of alternatives is often out of line
with expected outcomes (March & Shapira, 1987).
Second, managers do not attend to all potential risks.
Regardless of magnitude or expected outcome, if a risk
factor appears to be outside their direct control, managers
assign them to a category that might be called “Acts of
God.” They make no attempt to ameliorate these risk fac-
tors, even if the expected outcome could be shutdown of
a project (Schmidt, Keil, Lyytinen, & Cule, 2001).Information Technology (IT) Project Risk
IT project risk factors have been defined as any factors
that could affect the success of IT projects (Schmidt et
al., 2001). Numerous studies have sought to catalog IT
project risk factors. A thorough review of risk factors and
a ranking of the most important risk factors are presented
by Keil, Cule, Lyytinen, and Schmidt (1998) and Schmidt
et al. (2001). All 53 of the risk factors discussed in these
two papers apply to both traditional IT projects and
Internet-based projects. There are significant differences
between them, however. As a result, additional risk factors
are associated with those differences. In the following sec-
tion, some of those additional risk factors are examined.INTERNET-BASED PROJECT RISKS
In recent years, the management of software projects,
as well as other types of projects, has met with a new
venue, the Internet. By taking advantage of the flexi-
ble, ubiquitous communications afforded by the Internet,
project managers have been able to extend team member-
ship to analysts and programmers who would not have
worked on the project because of distance and time fac-
tors. Using groupware (both integrated commercial pack-
ages and stand-alone tools), Internet-based project teams
can become larger, with more diverse interests and tal-
ents. Workflow management software allows project man-agers to track tasks and monitor team member contribu-
tions. Whether these new tools are better than traditional
techniques is not well established. Even teams that share
the same geographic location are attempting to benefit
from the new Internet-based project management tools
through the use of intranets (Benett, 1998).How Internet-Based Projects Differ
From Other IT Projects
Geographic dispersion of team members and the locus of
project management are just two of the important risk fac-
tors affecting Internet-based projects. Project managers
must also deal with the problem of being separated from
their users, both geographically and temporally, which
complicates the process of verifying work and seeking ad-
vice. Outsourced projects are likely to become Internet-
based for convenience of the outsourcing company and
the contractors. Even the software to support Internet-
based project management might be outsourced from
firms like iVenturi, a joint venture between Dow Chem-
ical and Accenture (Gilbert, 2000). With such outsourced
project management applications, the user interface of
the support software becomes an important issue as well.
Finally, security of project data is in jeopardy both during
transmission and in storage at dispersed sites.Locus of Project Management
An important decision that must be made at the outset of
an Internet-based project is the physical location of the
project manager. From the standpoint of the project man-
ager, preference would be given to remaining in his or her
current location. In the case of outsourced projects, how-
ever, the project manager might be a significant distance
from the client, greatly complicating coordination during
the project. The client might prefer that the project man-
ager be located close to them, but then the manager would
be separated from the bulk of the project team members,
again causing coordination and supervision problems.
Even in the case of in-house projects, the project man-
ager and team members may be working at different loca-
tions. The emphasis is on fast development, so geographic
separation demands reliable, fast communications.
Ken van Heel, a business manager in Dow Chemical’s
e-business group says, “Everyone’s trying to get products
to market faster. They need fast communication about
hitting milestones and resolving problems” (Gilbert,
2000, 159).Detached Users
When the project manager and team are geographically
separated from the users, the gulf between them is even
wider than that experienced in traditional software devel-
opment projects. It becomes much more difficult to in-
volve users in the regular decisions that must be made
in the course of development, both in design and in cod-
ing. To use project support software or groupware for this
purpose requires user training, adding upfront time and
cost to the project. Users are also less likely to devote full
attention to project team requests because of their lack
of physical presence and the pressures of their day-to-day
jobs.