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
REFERENCES 235the project manager but do require skillful interfacing
with the user or customer. Effective processes for man-
aging change and ambiguity are needed. The real danger
associated with risks in this category is that project man-
agers may overestimate their own abilities or fail to real-
ize their own limitations in dealing with the risks. With
Internet-based projects, the lack of experience among
project managers is a serious problem. If project man-
agers assume the same practices they have used for tra-
ditional projects will suffice, it is likely that some of these
risk factors will not be treated properly.
For risks that have a small negative expected outcome
and fall under the direct control of the project manager,
more routine project management techniques would be
appropriate. The emphasis should be on internal and ex-
ternal reviews with the aim of keeping a project “on track.”
Considering the low threat these risks hold for the project,
it would be more likely for the manager to try to treat
these risks with a blanket approach as advocated by Cule
et al. (2000). Direct attention to each of these risks would
be disproportionate to their relative importance to the
project.
The final class of risks includes those over which the
project manager has little or no control and also have
a small negative expected outcome. The primary prob-
lem with this class of risks is that because they are not
viewed as being terribly important, the project manager
is less likely to expend any political capital in getting any-
one else to attend to the risks. Sometimes the small neg-
ative expected outcome is due to the low likelihood of
occurrence of a risk. If such a risk has a large magnitude,
then when it hits a project, its effects can be significant
and dangerous. It is extremely difficult to plan for these
risks. Because of their rare occurrence, there is a dearth
of experience in dealing with them and it is impractical to
engage in elaborate preventive measures to mitigate the
risks. Contingency planning, including concepts and tac-
tics associated with disaster planning, is the most sensible
strategy for dealing with this class of risks. Scenario build-
ing is another approach for developing plans to deal with
these risks should they occur (Phelps, Chan, & Kapsalis,
2001).CONCLUSION
In this chapter, the possibility of new risks associated with
Internet-based project management was explored. Exist-
ing knowledge about software project risk was summa-
rized, and the concept was extended to cover specific situ-
ations typical of Internet-based projects. Four important
concepts were emphasized. First, all risks can be traced
to a source, and action taken to manage risks should be
directed at the sources of risk. Second, identification of
project risks is a key process in risk management. A hy-
brid approach using checklists of known risks combined
with brainstorming to adjust the list to a specific project
provides the best approach to identifying risks. Third,
rather than classify risks according to source, the risks
can be classified using a 2×2 grid that compares level
of expected outcome with degree of control over the out-
comes. Fourth, project managers can manage most risks
with some simple coping behaviors. Some risks (thosethat pose the most serious threats to the project), how-
ever, require specific, targeted treatment.GLOSSARY
Expected outcome The product of the magnitude of an
outcome and the probability of its occurrence.
Groupware Software specifically designed to support
group interaction, including brainstorming, collabora-
tive work, and consensus building.
Internet-based project Any project that is principally
or wholly managed through the use of Internet tools,
rather than through face-to-face interaction.
Risk An event with an uncertain outcome.
Risk factor Any factor that could affect the outcome of
a risk.
Workflow management The active oversight and direc-
tion of a series of tasks by any group of actors working
in concert toward a common goal.CROSS REFERENCES
SeeE-business ROI Simulations; Electronic Commerce
and Electronic Business; Prototyping; Return on Invest-
ment Analysis for E-business Projects.REFERENCES
Ahn, J., & Skudlark, A. (2002). Managing risks in a
new telecommunications service development process
through a scenario planning approach.Journal of In-
formation Technology 17,103–118.
Arrow, K. (1965).Aspects of the theory of risk-bearing.
Helsinki: Yrj ̈o Jahnssonin s ̈a ̈atio.
Ash, T. (1998). Seven reasons why Internet projects fail.
UNIX Review’s Performance Computing, 16,15–16.
Barki, H., Rivard, S., & Talbot, J. (1993). Toward an assess-
ment of software development risk.Journal of Manage-
ment Information Systems, 10,203–225.
Benett, G. (1998). Working together, apart: The Web
as project infrastructure. Retrieved October 12,
2002, from http://www.intranetjournal.com/features/
idm0398-pm1.shtml
Boehm, B. (1989). Software risk management tutorial.
Washington, DC: IEEE Computer Society Press.
Bumbo, N., & Coleman, D. (2000). Collaboration for
distributed project management. Retrieved October
17, 2002, from http://www.collaborate.com/mem/case
studies/casestudy3.php3
Charette, R. (1989).Software engineering risk analysis and
management.New York: McGraw-Hill.
Collaborative Strategies. (2000). Electronic collaboration
on the Internet and intranets. Retrieved October 17,
2002, from http://www.collaborate.com/mem/white
papers/intranet.php3
Cule, P., Schmidt, R., Lyytinen, K., & Keil, M. (2000).
Strategies for heading off IS project failures.Informa-
tion Systems Management, 17–2,65–73.
Gibbs, W. (1994). Software’s chronic crisis. Scientific
American, 271,86–95.
Gilbert, A. (2000). Online project management planned.
Informationweek, 808,159.