PAPERS72 September 2009 ■ Project Management.docx

P
A
P
E
R
S
72 September 2009 ■ Project Management Journal ■ DOI:
10.1002/pmj
INTRODUCTION ■
A
ccording to the United Kingdom’s Royal Academy of
Engineering, bil-
lions of pounds are wasted every year on new information
technology
(IT) systems. Troubled public-sector IT projects such as the
National
Health Service (NHS) National Programme for IT, the Child
Support
Agency systems, and HM Revenue and Customs’ Tax Credits IT
system have
attracted considerable negative press. They have overrun, cost
millions of
pounds more than was budgeted, and, in some cases, have been
cancelled
before their costs spiral even further out of control. Terms such
as “nightmare”

and “disaster” tend to be attached to such projects. IT projects
(the provision
of a service to implement systems and solutions, including a
variety of hard-
ware and software products; (Howard, 2001) seem to be more
problematic
than other types of projects, with a particularly high rate of
failure (McGrew &
Bilotta, 2000; The Standish Group International, 2007;
Whittaker, 1999).
Despite well-established best practice project management
processes, project
managers appear to be ineffective in the light of such failure.
Organizations such as the Project Management Institute (PMI)
and the
United Kingdom’s Association for Project Management (APM)
promote best-
practice project management standards. As part of these
standards, project risk
management is defined as the systematic process of identifying,
analyzing, and
responding to risks. Risk is any project-related event, or
managerial behavior,
that is not definitely known in advance but has the potential of
adverse conse-
quences on a project objective (PMI, 2004). Project risk
management claims to
enable project managers to effectively manage risk and
minimize the adverse
influence of risk on the project outcome. However, we have
found that IT proj-
ect managers often do not apply a process to manage risks. The
reasons for this
vary. Nevertheless, the evidence behind this phenomenon is
very scarce, often

descriptive, and inchoate. The purpose of this study was to
investigate whether
best practice standards are applied, and if they are not, what
reasons led the IT
project manager to decide not to actively approach and manage
project risks.
The results show that IT project managers primarily face the
problem of
cost justification. Facing costs and time constraints and the
uncertainty of
the success of project risk management, they often decided not
to actively
manage risks. However, with the benefit of hindsight, we see
that such a
decision often turns out to be fatal. Not surprisingly, in projects
where proj-
ect risk management is not used, a greater degree of risks
materialize than in
those projects where the IT project manager does actively
manage risks.
Project Risk Management
Risks may potentially endanger the ability of the project
manager to meet
the predefined project objectives, such as scope, time, and cost;
tasks may
The Rational Choice of Not Applying
Project Risk Management in
Information Technology Projects
Elmar Kutsch, School of Management, Cranfield University,
Cranfield, Bedfordshire,
United Kingdom
Mark Hall, Department of Management, University of Bristol,
Bristol, United Kingdom

ABSTRACT ■
The management of risk is considered a key dis-
cipline by the Project Management Institute and
the Association for Project Management.
However, knowledge of what needs to be done
frequently fails to result in action consistent
with that knowledge. The reasons for this seem
to have received little attention. This study
researched the degree of use of project risk
management and barriers that prevent IT proj-
ect managers from using risk management.
Interviews and a survey were carried out. The
results show that, in one-third of cases,
because of the problem of cost justification, no
formal project risk management process was
applied.
KEYWORDS: IT projects; risk management;
rationality
Project Management Journal, Vol. 40, No. 3, 72–81
© 2009 by the Project Management Institute
Published online in Wiley InterScience
(www.interscience.wiley.com)
DOI: 10.1002/pmj.20112
September 2009 ■ Project Management Journal ■ DOI:
10.1002/pmj 73

take longer than planned, consequent-
ly negatively influencing the project
manager’s fulfillment of the project
objectives. Equally, of course, risk can
be seen as offering previously uncon-
sidered opportunities for the project at
an operational level, or for stakeholders
at a strategic level (what is sometimes
referred to as “opportunity risk”; Ward &
Chapman, 2002)
Because of this potential of risk to
either adversely influence a project’s per-
formance or present hitherto unrecog-
nized opportunities for value enhance-
ment, the PMI, in its Guide to the Project
Management Body of Knowledge
(PMBOK® Guide)—Third edition (PMI,
2004), acknowledges the management of
risk as one of its nine key knowledge areas.
This represents, according to Pender
(2001), best practice in the area of project
management. There are a number of
other “best practice” project risk manage-
ment processes, such as that of the British
Standards Institution (2000) and the
APM’s Body of Knowledge guidance
(APM, 2005; Chapman, 1997). The basic
structure of these models is similar
(Gaulke, 2002). Table 1 gives an overview
of the key elements.
Regardless of the number of phases
and the definition of these phases, the
processes have one activity in common:

“an activity that deals with planning
actions that will be implemented in
order to reduce the exposure to risk”
(Ben-David & Raz, 2001, p. 14). Best prac-
tice project risk management processes
can be reduced to four major stages:
planning, identification, analysis, and
response. First, a project manager can
apply risk management planning to
define what activities should be taken
to approach project uncertainties.
Second, risk identification allows project
managers to single out uncertainties
that may affect the project objectives.
Third, by using risk analysis a project
manager evaluates, quantitatively or
qualitatively, the likely consequences of
risks as well as the likelihood that risks
will become real (i.e., be realized;
Raftery, 1994, p. 6). Finally, risk response
helps a project manager to develop pro-
cedures and techniques to mitigate the
defined risks and enables the project
manager to keep track of defined risks,
to identify new risks during the project
and to implement risk-response plans
(PMI, 2004).
The result of risk processes such as
those defined by PMI (2004) is a deci-
sion based on the expected utility of dif-
ferent choices (Ekenberg, Boman, &
Linnerooth-Bayer, 2001; Kahneman &
Tversky, 1979; Tversky & Kahneman,
1992). Expected utility can be defined

as “a weighted average of the utilities of
all the possible outcomes that could
flow from a particular decision, where
higher-probability outcomes count
more than lower-probability outcomes
in calculating the average” (Borge, 2001,
p. 21); the utility of decision-making
choices are weighted by their probabil-
ities and outcomes (Arrow, 1983;
Kahneman & Tversky, 1979).
Expected utility theory (EUT) has
generally been accepted in risk litera-
ture as a model of rational choice for
taking risky decisions (Anand, 1993;
Borge, 2001; Jaeger, Renn, Rosa, &
Wehler, 2001; Kahneman & Tversky,
1979) and provides the fundamental
assumptions that underline project risk
management:
• a clear and unambiguous identifica-
tion of the problem, its constituent
elements, and its causes;
• perfect information about all of the
relevant variables in terms of both
quantity and quality;
• a well-developed model of the prob-
lem that incorporates all the variables
likely to influence the decision out-
come and a perfect understanding of
the manner and scale of interaction;

• an exhaustive list of all possible solu-
tions;
• an unambiguous statement of the
objectives that is specific, quantifiable,
and internally consistent;
Major Steps in PMBOK® Guide—PMI OGC—Best Management
Practice PRAM—APM Risk
Project Risk Risk Management (Office of Government
Commerce, Management Process
Management Process (PMI, 2004) 2007) (APM, 2005)
Planning Risk management planning Context Focus
Define
Identification Risk identification Risk identification Identify
Structure
Analysis Risk analysis Risk analysis Estimate
Risk evaluation Evaluate
Response Risk response planning Risk treatment Plan
Risk (monitoring and) control Ownership
Manage
Table 1: Overview of main project risk management processes.
10.1002/pmj
The Rational Choice of Not Applying Project Risk Management
in Information Technology

P
A
P
E
R
S
• perfect knowledge of the future con-
sequences of each possible solution
and their implications for the project;
• the availability of all of the resources
and sufficiency of reliability in all of the
structures and systems necessary for
the successful implementation of the
chosen solution; and
• the presence of perfectly rational and
experienced decision makers with
unlimited analytical and cognitive
abilities (Ritchie & Marshall, 1993,
p. 129).
The assumptions have been taken
into account by PMI and APM in devis-
ing their risk management guidance and
are treated as being self-evidently cor-
rect. As Williams (2005, p. 498) argued:
Project management as set out in
this work is presented as a set of
procedures that are self-evidently
correct: following these procedures

will produce effectively managed
projects; project failure is indicative
of inadequate attention to the proj-
ect management procedures.
However, despite the existence of a
self-evidently correct process to man-
age project risk, some evidence suggests
that project managers feel restricted in
applying such an “optimal” process to
manage risks. For example, Lyons and
Skitmore (2004) investigated factors
limiting the implementation of risk
management in Australian construction
projects. Similar findings about the bar-
riers of using risk management in three
Hong Kong industries were found in a
further prominent study by Tummala,
Leung, Burchett, and Leung (1997). The
most dominant factors for constraining
the use of project risk management are
the lack of time, the problem of justify-
ing the effort into project risk manage-
ment, and the lack of information
required to quantify/qualify risk esti-
mates.
As can be seen, the findings of this
study reveal a similar picture. In two
out of three industries, the lack of time
was the major influence constraining
the use of risk management. A review of
existing literature has revealed several
factors that reduce the likelihood that
formal project risk management will be

used. These are:
1. The problem of hindsight
2. The problem of ownership
3. The problem of cost justification
4. Lack of expertise
5. The problem of anxiety
We discuss each of these in turn.
If the purpose of project risk man-
agement is to manage risk in advance—
that is to say, to respond to risks that
may have a future adverse (or, of
course, beneficial) impact on project
outcomes, risk management is reliant
on hindsight as a predicator for future
risks. The problem of hindsight relates
to the degree of uncertainty that is
inherited in a project (Young, 1998). In
comparison to other project areas such
as in construction, IT-related projects
appear to include a relatively high
degree of uncertainty (Graham, 1999;
Wirth, 1996). Whereas projects in other
industries (for example, pharmaceuti-
cals, notebook development, and earth
moving) resemble “variation” projects,
with cost, time, and performance levels
varying randomly but within a pre-
dictable range, the development of
software services can be regarded as
“chaotic” projects, varying to such a
large degree and in such an erratic
manner as to defy any prediction
(Meyer, Loch, & Pich, 2002).

The problem arising from the lack
of hindsight in projects is that project
managers may not feel able to rely on
the validity of probabilistic conclusions
about future risk based on historical
data (Frosdick, 1997; Pender, 2001). In
this respect, Shakle (1952, p. 5) states:
The theory of probability, in the
form which has been given to it by
mathematicians and actuaries, is
adapted to discovering the tenden-
cies of a given system under indefi-
nitely repeated trials or experiments.
In any set of such trials, each trial is,
for the purpose of discovering such
a tendency, given equal weight with
all the others. No individual trial is
considered to have any importance
in itself for its own sake, and any
tendency which may be inductively
discovered or predicted a priori for
the system, tells us nothing about
any single individual trial which we
may propose to make the future.
Frosdick (1997, p. 176) further adds:
The techniques of risk estimation
are largely quantitatively based and
make claims to scientific objectivity,
which are undermined on several
fronts. There are question marks
about the extent to which event and
reliability data can itself be relied on

for accuracy. In the absence of
adequate data, the assignment of
probabilities is a subjective process
dependent on the assigner’s own
bias.
The degree of uncertainty implies
that learning from past experience may
not take place, with the consequence
being that risks remain hidden until
they ultimately materialize (Douglas &
Wildavsky, 1982). Hence, this may
explain why project managers do not
apply any project risk management—
they are unaware of the existence of
risks due to the project’s unique nature.
The second problem we have iden-
tified is that of the problem of owner-
ship. As part of the process stage of risk-
response planning, risk owners are
defined as those who should get
involved in developing risk-response
actions. However, the perception of
ownership of risks may lead to difficul-
ties in developing responses to risks.
Ward and Chapman (1991) argue that
risk actors may not feel responsible for
risks because they are perceived to be
owned by someone else; no clear allo-
cation of responsibility would mean
that actually no risk owners are defined.
The perception by risk actors that they
are not the owner of a risk may be
caused by their reluctance to be blamed

10.1002/pmj 75
in case the response fails to help miti-
gate the risk (Hall, 1975). As a result, no
risk process is applied because risks are
expected to be managed by other par-
ties or no responsibility for managing
risks is taken in order to avoid being
blamed for materializing risks.
A problem that has received much
attention in risk management literature
is the problem of cost justification. The
application of project risk management
requires the commitment of resources
such as manpower. Time and money
need to be invested to carry out the
process of managing risks. However, the
costs are often difficult to justify. The ben-
efits of project risk management are not
quantifiable in advance. Resources are
committed to the identification, analysis,
and response to risks that are not certain
to occur. The client owner or sponsor
may not spend money and energy on a
management process without knowing it
has definite benefits (Lanza, 2000; Royer,
2000; Ward & Chapman, 1991). Raz and
Michael (2001, p. 14) mention:
One of the reasons we included this
part is that we met many project
managers who claimed that risk

management was an unnecessary
activity, and that the resources it
required could be put to better use
elsewhere in the project.
Consequently, during the phase of
risk management planning, stakehold-
ers may decide not to implement proj-
ect risk management at all. As Akintoye
and MacLeod (1997, p. 37) state:
It is unsurprising that some of the
respondents have identified project
time constraints as one of the major
reasons for not using risk analysis
and management techniques.
Therefore, the justification of time
and, ultimately, the costs involved in
carrying out project risk management
may pose a problem for project man-
agers in actively managing risk.
Lack of expertise relates to project
managers lacking appropriate skills
and familiarity when carrying out risk
management (Akintoye & MacLeod,
1997). Project managers may not know
how to use statistical tests, or because
of their lack of skills, they may decide
not to apply the risk management
process at all.
The final issue we have identified is
the problem of what we have called

anxiety. The number of risks that could
possibly influence the project outcome
is infinite. The process of project risk
management enables the project man-
ager to expose these risks and to man-
age them. However, the exposure may
also create anxiety, and negative
thoughts may be suppressed (Frosdick,
1997). In an extreme case, the process
of explicating risks may result in the
cancellation of the project because
stakeholders take new risks into
account and decide not to go ahead
with the project, which is now per-
ceived as too risky (Royer, 2000). As a
result, project managers may limit the
degree to which they identify new risks;
risks, although legitimate, are then sup-
pressed, with the possible result that no
project risk management is carried out.
Project risk management, as
defined by, for example, PMI, is a nor-
mative, rationalist set of process stages.
However, in the context of IT projects,
the reasons why managers do not min-
imize the influence of risks have gained
little attention in the field of project
management. Existing research lacks
empirical evidence and is often
descriptive. Keil, Mixon, Saarinen, and
Tuunainen (1995, p. 77) argue:
Since the 1970s, both academics
and practitioners have written
about risks associated with manag-

ing software projects. . . .
Unfortunately, much of what has
been written on risk is based either
on anecdotal evidence or on studies
limited to a narrow portion of devel-
opment.
In this study, literature from subject
areas like that of information systems
(e.g., Keil et al., 1995; White & Leifer,
1986) insufficiently answers the
research problem of this study: What
barriers do project managers perceive to
prevent them from managing risk?
Some evidence from industries such as
construction about those risk-related
problems exists, but overall it is insuffi-
cient to address the research problem
in the context of IT projects. As a result,
this study sought to shed some light on
a problem that may ultimately deter-
mine the successful outcome of IT
projects.
Method
This study was divided into two main
phases: an exploratory phase and a
survey. The exploratory phase had the
purpose of developing an in-depth
understanding of the research problem:
that is, why IT project managers do not
apply project risk management. The
goal of the exploratory phase was to
understand the “social, or lived, reality”
of project managers and how they expe-

rienced the application of project risk
management. Therefore, a research
technique of face-to-face semistruc-
tured interviews was adopted. This pro-
vided the opportunity to obtain a rich
and detailed view from multiple cases
and to gain a deep insight as to what is
relevant from the respondent’s point of
view.
The interviews were recorded with
the consent of the interviewee. Addi-
tionally, notes were taken against a spe-
cific checklist of questions. The ration-
ale behind this was to identify impor-
tant issues in the interviews and to
receive a broad but immediate overview
of project risk management in the dis-
cussed project. The profile of the sam-
ple in the exploratory research is shown
in Table 2.
For the purpose of making sense of
the qualitative data and for generating
patterns to be tested in the explanato-
ry phase (i.e., survey phase), a tem-
plate approach (Robson, 2002) was
applied using proprietary qualitative
data analysis software (QSR NVivo).
10.1002/pmj

P
A
P
E
R
S
This took the form of generating cod-
ing from the data. This was overlaid
with a series of categories that had
already been defined based on existing
literature.
After the exploratory phase, we felt
we had formed a deeper understanding
of the research problem. This under-
standing was based on patterns that
have emerged through the analysis of
the data from the semistructured inter-
views. The purpose of the second phase
was to produce further evidence from a
wider population of project managers
as to why, and to what extent, project
managers failed to apply a project risk
management process. This was to con-
firm or refute the findings of the
exploratory phase. The method chosen
was a self-completion questionnaire (in
this study, a web-based survey). The
survey was preceded by a pilot survey of
70 participants in a single organization

to identify any structural or technical
problems with the survey, thereby
increasing reliability and validity. This
was followed by in-depth discussions
with four respondents to check the
detail of the questionnaire. As a result,
we feel we had a very valid and reliable
questionnaire.
The sample of respondents for the
survey stage was determined randomly
using a cluster sample. It was taken
from the 2,200 project managers who
are members of PMI’s Risk Manage-
ment Specific Interest Group (RiskSig)
and the specific risk interest group of
the APM. Slightly less than one-third of
these registered project managers
(approximately 750) were found to be
specialists in conducting IT projects,
and these people were invited to take
part in the survey. This sample was
asked, via e-mail, to respond to the
questionnaire, which was accessible
through a Web link. In order to increase
the response rate, the participants in
the survey had the opportunity to take
part in a prize draw. A total of 102 use-
able responses were received.
The profile of the sample is shown
in Table 3. As can be seen, the sample
consisted predominantly of IT project
managers involved in rollout projects.
These included the installation of hard-

ware and software and the migration of
data from old to new systems. The
majority of projects were in the range of
6–12 months’ duration.
Table 2: Summary of profile of exploratory sample (qualitative
evaluation of factors preventing the use of project risk
management).
Project Risk
Approx. Project Management
Interviewee Organization Position Volume (£m) Duration
(Months) Applied
Interviewee 1 Company A IT project manager 15 36 Yes
Interviewee 2 Company B IT consultant 5 18 Yes
Interviewee 3 Company C IT project manager 1 1 Yes
Interviewee 4 Company C IT project manager 10 2 Yes
Interviewee 5 Company D IT project manager 0.008 0.25 No
Interviewee 6 Company E IT project manager 18 12 No
Interviewee 7 Company F IT project manager 1 12 Yes
Interviewee 8 Company G IT project manager 30–40 18 Yes
Interviewee 9 Company H IT project manager 3 14 Yes
Interviewee 10 Company I IT project manager 7 18 Yes
Interviewee 11 Company J IT project manager 10 18 Yes

Interviewee 13 Company J IT project manager 1–2 1 No
Interviewee 16 Company J IT project manager 1,000 120 Yes
Interviewee 18 Company K IT project manager 8 36 No
10.1002/pmj 77
In order to ascertain whether a
project risk management process
was applied, the IT project managers
were asked, “Was a formal project risk man-
agement process (including risk identi-
fication, analysis, response evaluation
and monitoring and control) applied?”
Where this was not the case, the
respondents were further questioned,
using the following open-ended ques-
tion: “If a formal project risk manage-
ment process was not applied, what
were the reasons (e.g., too expensive,
low project risk) for not using it?”
Findings

In the exploratory interview stage, four
of 18 interviewees reported that no proj-
ect risk management process was
applied. In one of the cases, the problem
of cost justification arose. The IT project
manager (Interviewee 5) mentioned, “At
the beginning, we had so much to do
that no one gave a thought to tackling
risks at that point. It simply did not hap-
pen.” In this case, it appears that, due to
lack of time, the investment of scarce
resources into the management of
project risks was not justified. However,
with the benefit of hindsight, it appears
that the use of project risk management
might have been worthwhile, as the
project turned out to be a “financial dis-
aster” for the service provider.
In contrast to the problem of cost jus-
tification and its effect on preventing IT
project managers from carrying out any
kind of proactive project risk manage-
ment process, in another case the prob-
lem of hindsight became a salient issue:
It would have been nice to do it dif-
ferently but because we were quite
vulnerable in terms of software
development, and because most of
that was driven by the States, we
were never in a position to be proac-
tive. The Americans would say “We
got an update to that system and we
just released it to you,” rather than

telling us a week in advance that
something was happening. We were
never ahead enough to be able to
plan. (Interviewee 18)
The risk that update imposes on
other parts of the software could not
have been anticipated. It appears that
no prediction and no active project risk
management were possible, so project
managers ended up adapting to devel-
oping situations. Indeed, in the case of
temporal and action convergence,
project managers have been found to
improvise (Crossan, 1998; Crossan,
White, Lane, & Klus, 1996; Eisenhardt,
1997; Miner, 2001; Weick, 1998). In this
case, IT project managers were “forced”
to improvise because of materializing
uncertainty that was or could not have
been foreseen. Not carrying out a risk
management process ensured that.
The third case in which the IT project
manager had decided against carrying
out active management to risk is char-
acterized by the problem of anxiety.
The project manager argued against
undertaking a project risk management
process because he did not want to “. . .
unnerve them [the stakeholders], and
also lose the project, because there was
very strong competition from other
providers” (Interviewee 6). In this case, it
seemed that mentioning even the sub-

ject of risk would mean that the cus-
tomer would become aware of risk as an
issue, and that this awareness would
jeopardize the relationship between the
customer and the project management
team. The relationship between the
understanding and perception of risk
appeared to lead to cautiousness among
project managers in developing more
understanding about specific risks and
their implications for their particular
projects. Another interviewee elaborated
on this issue:
The question is how specific you
want to go. Pulling out a generic risk
is fine and people can see the red
flag go up, but unless an absolute
showstopper sat right in my arena
of operations, I would not necessar-
ily think it was my case to raise it.
Informally I would say it to the proj-
ect risk assessor, “You need to talk
to so-and-so because I think they
have an issue.” (Interviewee 13)
In summary, it was found that, in
some cases, project managers responsi-
ble for the management of risk acted to
Table 3: Summary of profile of explanatory sample
(quantitative testing of barriers on a wider
population of IT project managers).
Number of IT
Project Managers

Involved Percentage
Type of project
Outsourcing 16 15.7
Implementation of user help desk structures 3 2.9
Software development 24 23.5
Roll out 39 38.2
Other types of IT projects 20 19.6
Time frame
�24 months 26 25.5
12–24 months 20 19.6
6–12 months 32 31.4
�6 months 24 23.5
Project Volume
�£1,000,000 46 45.1
£100,000–£1,000,000 39 38.2
£10,000–£100,000 14 13.7
�£10,000 3 2.9
10.1002/pmj
P
A
P
E
R

S
reduce anxiety among customers and
other stakeholders by not confronting
them with uncertainties and risks. In
other words, they “concealed” or “denied
the presence” of risk. This was either
purposeful (they would make a decision
not to mention specific, project-related
risks) or unconscious (they did not dwell
on the presence of risk, thereby not hav-
ing to mention it as an issue). Their
unwillingness to mention risk relates to
the temptation to give people the
answers they want to hear, and to give
the impression of certainty or a percep-
tion of a safe and predictable world
(Beierle, 2004; Fischhoff, Lichtenstein,
Slovic, Derby, & Keeney, 1981; Slovic,
Fischhoff, & Lichtenstein, 1980).
Because stakeholders may perceive risk
management to be a gloomy and nega-
tive affair (Raftery, 1994) or because
stakeholders are more concerned with
the exposure to potential adverse exter-
nal opinion of failure than with the pos-
sible impact of uncertainties on the
project (Parker & Mobey, 2003), they
downgrade their actual perceived risk to
a desired external accepted level of risk
(Machlis & Rosa, 1990) that can be “safe-
ly” engaged through risk management
without the side effect of “dread.” Insofar
as risks that may have an influence on
the project outcome are suppressed, no

project risk management process is car-
ried out for the sake of avoiding discom-
fort among stakeholders.
The exploratory findings provided
an insight into the factors of cost
justification, anxiety, and lack of hind-
sight that IT project managers experi-
enced. This manifested itself in the
choice to not take the rational decision
to manage project risks. However, while
we were left with a richer picture of the
dynamics within projects when dealing
(or not dealing, as the case sometimes
was) with risk and its management, we
were unable to generalize from this
small sample of depth interviews.
Hence, the second phase (the survey)
was carried out to explore the research
problem in a wider population. First, IT
project managers were asked which
specific process they applied. In over
half of all cases, a PMI risk management
process was used, thus underscoring
the dominance of this best practice
standard in IT projects However, in
one-third of the 102 cases, no formal
project risk management approach was
applied. This seemed rather surprising
when the amount of money at stake in
those projects was considered. The
findings can be explained by the rea-
sons given by the respondents. IT proj-
ect managers were asked, in an open
question, about their reasons for not

applying a formal project risk manage-
ment process. Table 4 displays some of
the answers given by the respondents,
together with our interpretation of
those answers.
The most dominant reason for the
nonapplication of project risk manage-
ment appeared to be the problem of cost
justification. Active project risk manage-
ment was not carried out because project
managers and other risk actors appeared
not to consider project risk management
as worthy of pursuit, given the time and
cost constraints they were experiencing.
Regarding the application of project risk
management, the findings seem to con-
firm the tendency in the exploratory
cases that project risk management was
not applied in some cases, thus meaning
that IT project managers, and other risk
actors, had a reactive project risk man-
agement approach and/or paid no atten-
tion to actively managing project risks.
Conclusions
Little research to date has been under-
taken to establish whether project man-
agers involved in IT projects actually
apply risk management and what rea-
sons lie behind their decisions to not
pursue any active management of risk
in some cases. Rather, there would
appear to be a substantial body of liter-
ature on what project managers should
do, rather than on what they did do. As

long as no evidence is produced to
explain why IT project managers fail
to apply project risk management, the
acceptance of best-practice project risk
management standards is, in our view,
at stake.
Project management, including the
key process of project risk management,
is described as self-evidently correct
(Williams, 2005). However, it appears
that factors such as the problem of cost
justification violate fundamental
assumptions of rationality underlying
traditional project risk management.
Why is this the case? On the one hand, a
decision by an IT project manager not
to apply project risk management may
be described as irrational, at least if one
accepts the premise that the project
manager chose not to apply a “self-evi-
dently” correct process to optimally
reduce the impact of risk on the project
outcome. On the other hand, Otway
(1992) argues that a person who focuses
only on the statistical probability of
threats and their impacts and ignores
any other information would be truly
irrational. Hence, a project manager
would act sensibly by, for example, not
applying project risk management
because he or she rates the utility of not
using project risk management as high-
er than the utility of confronting stake-
holders with discomforting informa-

tion. Therefore, if people persistently
act in violation of EUT, the account of
rationality according to EUT may be
questioned (Anand, 1993), and thus the
entire exercise of project risk manage-
ment as promoted by PMI or APM.
PMI and APM claim that through the
systematic identification, analysis, and
response to risk, project managers can
achieve the planned project outcome.
However, the findings show that in more
than one-third of all projects, the
effectiveness of project risk management
is virtually nonexistent because no for-
mal project risk management process
was applied due to the problem of cost
justification. If project managers need to
be convinced about the value of project
risk management, further research could
focus on the issue of whether the costs of
applying project risk management are
compensated by mitigating the risks that
adversely influence the project outcome.
10.1002/pmj 79
As long as project managers perceive the
costs of carrying out project risk man-
agement to be greater than the benefits
of mitigated risks, the problem of cost
justification may not be overcome.

One limitation of our research
regards generality. In the sample for the
survey, we approached only a narrow
segment of project managers: those IT
project managers who were members of
a professional group of PMI. Second,
limited generalizability arises through
the use of subjective data. The IT project
manager’s “lived reality” that has been
investigated in this study may not be
transferable to other individuals. As a
consequence, tendencies that have
emerged and been tested about con-
cepts such as risk mediators cannot
be generalized beyond the chosen sam-
ple cluster. In these circumstances, the
degree of generalization is limited to
the respondents chosen in the first ex-
ploratory phase and respondents of the
survey. That is to say, these findings may
apply only to the IT project managers
who were part of the cluster sample and
not to IT project managers who are not
members of PMI or who are involved in
projects in other industries. ■
References
Akintoye, A. S., & MacLeod, M. J.
(1997). Risk analysis and management
in construction. International Journal
of Project Management, 15(1), 31–38.
Anand, P. (1993). Foundations of
rational choice under risk. Oxford, UK:
Clarendon Press.

Arrow, K. J. (1983). Behaviour under
uncertainty and its implications for
policy. In B. P. Stigum, & F. Wenstop
(Eds.), Foundations of utility and risk
theory with applications (pp. 19–32).
Dordrecht, Germany: D. Reidel
Publishing Company.
Association for Project Management
(APM). (2005). Project management
body of knowledge. London: Author.
Beierle, T. C. (2004). The benefits
and costs of disclosing information
about risks: What do we know about
right-to-know? Risk Analysis, 24,
335–346.
Ben-David, I., & Raz, T. (2001). An inte-
grated approach for risk response
development in project planning.
Journal of the Operational Research
Society, 52, 14–25.
Borge, D. (2001). The book of risk. New
York: Wiley.
Table 4: Reasons for the nonapplication of project risk
management.
Reason for Not Applying Project Risk Management Problem
“We haven’t got time left.” Problem of cost justification

“No executive call for risk measurements.” Problem of cost
justification
“Company doesn’t see the value in adding the additional cycles
to a project.” Problem of cost justification
“Upper management did not think it required it.” Problem of
cost justification
“Ignorance that such a thing existed or was necessary.” Problem
of cost justification
“Too expensive, decision made by pre-sales team.” Problem of
cost justification
“At the time, no one thought that was an important thing to do.
It was the project manager’s job to Problem of cost justification
manage all risks, by himself, without help from others. It was
what he was paid the ‘big bucks’ to do.”
“An initial risk analysis was done, but PM didn’t bother to
follow up.” Problem of cost justification
“Too many different companies had ‘ownership’ of different
elements; semiformal risk management Problem of cost
justification
to work individual packages was applied but was not really
effective, as it was not rolled up to the
highest level.”
“A single risk-identification workshop was held early in the
project before my arrival. Reason for not Problem of cost
justification
following the process was most probably the attitude of the
members of the team.”

“The principal reason why a formal project risk management
process was not applied had more to do Problem of cost
justification
with the organizational culture than anything else. The
organization is culturally focused on getting
things done. Thus, there was no ‘formal project risk
management process’ required.”
“Not enough time to prepare a plan. Accelerated implementation
was the key, not cost.” Problem of cost justification
“When the project was running, we did not have formal PM
education in terms of the process and Problem of lack of
expertise
supporting areas.”
“Too many different companies had ‘ownership’ of different
elements.” Problem of ownership
“Risk was in the customer’s court.” Problem of ownership
10.1002/pmj
P
A
P
E
R

S
British Standards Institution. (2000).
Project management—part 3: Guide to
the management of business related
project risk. London: Author.
Chapman, C. (1997). Project risk
analysis and management—PRAM
the generic process. International
Journal of Project Management, 15(5),
273–281.
Crossan, M. M. (1998). Improvisation in
action. Organisation Science, 9, 593–599.
Crossan, M. M., White, R. E., Lane, H.
W., & Klus, L. (1996). The improvising
organisation: Where planning meets
opportunity. Organizational Dynamics,
24(4), 20–35.
Douglas, M., & Wildavsky, A. (1982).
Risk and culture. Berkeley, CA:
University of California Press.
Eisenhardt, K. M. (1997). Strategic
decisions and all that jazz. Business
Strategy Review, 8(3), 1–3.
Ekenberg, L., Boman, M., &
Linnerooth-Bayer, J. (2001). General
risk constraints. Journal of Risk
Research, 4(1), 31–47.
Fischhoff, B., Lichtenstein, S., Slovic,

P., Derby, S. L., & Keeney, R. L. (1981).
Acceptable risk. Cambridge, UK:
Cambridge University Press.
Frosdick, S. (1997). The techniques of
risk analysis are insufficient in them-
selves. Disaster Prevention and
Management, 6(3), 165–177.
Gaulke, M. (2002). Risikomanagement in
IT-projekten. Wien: Oldenbourg Verlag.
Graham, R. (1999). Managing the proj-
ect management process in aerospace
and construction: A comparative
approach. International Journal of
Project Management, 17(1), 39–45.
Hall, W. K. (1975). Why risk analysis
isn’t working. Long Range Planning,
8(6), 25–29.
Howard, J. (2001). Computer services:
2001 market report. Hampton,
Middlesex, UK: Key Note Ltd.
Jaeger, C. C., Renn, O., Rosa, E. A., &
Wehler, T. (2001). Risk, certainty, and
rational action. London: Earthscan.
Kahneman, D., & Tversky, A. (1979).
Prospect theory: An analysis of decision
under risk. Econometrica, 47, 263–291.
Keil, M., Mixon, R., Saarinen, T., &
Tuunainen, V. (1995). Understanding

runaway information technology proj-
ects: Results from an international
research program based on escalation
theory. Journal of Management
Information Systems, 11(3), 65–85.
Lanza, R. B. (2000). Does your project
risk management system do the job?
Information Strategy: The Executive’s
Journal, 17(1), 6–12.
Lyons, T., & Skitmore, M. (2004). Project
risk management in the Queensland
engineering construction industry:
A survey. International Journal of
Project Management, 22, 51–61.
Machlis, G. E., & Rosa, E. A. (1990).
Desired risk: Broadening the social
amplification of risk framework. Risk
Analysis, 10(1), 161–168.
McGrew, J. F., & Bilotta, J. G. (2000).
The effectiveness of risk management:
Measuring what didn’t happen.
Management Decision, 38, 293–300.
Meyer, A. D., Loch, C. H., & Pich, M. T.
(2002). Managing project uncertainty:
From variation to chaos. IEEE
Engineering Management Review,
30(3), 91–98.
Miner, A. S. (2001). Organizational
improvisation and learning: A field
study. Administrative Science Quarterly,

46, 304–337.
Office of Government Commerce.
(2007). Management of risk: Guidance
for practitioners. London: The
Stationery Office.
Otway, H. (1992). Public wisdom,
expert fallibility: Toward a contextual
theory of risk. In S. Krimsky &
D. Golding (Eds.), Social theories of risk
(pp. 215–228). Westport, CT: Praeger.
Parker, D., & Mobey, A. (2003).
Perceptions in risk evaluation for proj-
ect management. Presented at the
EurOMA—POMS Conference, Italy.
Pender, S. (2001). Managing incomplete
knowledge: Why risk management is
not sufficient. International Journal of
Project Management, 19, 79–87.
Project Management Institute (PMI).
(2004). A guide to the project manage-
ment body of knowledge (PMBOK®
Guide)—Third edition. Newtown
Square, PA: Author.
Raftery, J. (1994). Risk analysis in project
management. London: Chapman & Hall.
Raz, T., & Michael, E. (2001). Use and
benefit of tools for project manage-

ment. International Journal of Project
Management, 19, 9–17.
Ritchie, B., & Marshall, D. (1993).
Business risk management. London:
Chapman & Hall.
Robson, C. (2002). Real world research:
A resource for social scientists and
practitioner—researchers (2nd ed.).
London: Blackwell.
Royer, P. S. (2000). Risk management:
The undiscovered dimension of proj-
ect management. Project Management
Journal, 31(1), 6–13.
Shakle, G. (1952). Expectation in eco-
nomics (2nd ed.). Cambridge, UK:
Cambridge University Press.
Slovic, P., Fischhoff, B., & Lichtenstein,
S. (1980). Facts and fears: Understanding
perceived risk. In R. C. Schwing & W. A.
Albers (Eds.), Societal risk assessment
(pp. 181–214). New York: Plenum Press.
The Standish Group International.
(2007). Chaos (application project and
failure). West Yarmouth, MA: Author.
Tummala Rao, V. M., Leung, H. M.,
Burchett, J. F., & Leung, Y. H. (1997).
Practices, barriers and benefits of
using risk management approaches in
selected Hong Kong industries.

International Journal of Project
Tversky, A., & Kahneman, D. (1992).
Advances in prospect theory:
Cumulative representation of uncer-
tainty. Journal of Risk and Uncertainty,
5, 297–323.
Ward, S., & Chapman, C. (1991).
Extending the use of risk analysis in
project management. Project
Management Journal, 9, 117–123.
10.1002/pmj 81
Ward, S., & Chapman, C. (2002).
Transforming project risk management
into project uncertainty management.
Weick, K. E. (1998). Improvisation as a
mindset for organisational analysis.
Organisation Science, 9, 543–555.
White, B., & Leifer, R. (1986,
September). Information systems
development success: Perspective
from project team participants. MIS
Quarterly, 10, 215–223.
Whittaker, B. (1999). What went

wrong? Unsuccessful information
technology projects. Information
Management & Computer Security,
7(1), 23–29.
Williams, T. M. (2005). Assessing and
moving on from the dominant project
management discourse in the light of
project overruns. IEEE Transactions
on Engineering Management, 52,
497–508.
Wirth, I. (1996). How generic and how
industry-specific is the project
management profession?
Management, 14(1), 7–11.
Young, T. L. (1998). The handbook of
project management. London: Kogan
Page Ltd.
Elmar Kutsch, PhD, is a lecturer in the School of
Management at Cranfield University, where he is
involved in the International Centre for Programme
Management (ICPM). His main interests are risk
and crisis management and dynamic complexi-
ties in projects and programs.
Mark Hall is a senior lecturer in the Department
of Management at the University of Bristol,
United Kingdom. His research interests are in
operations and project management generally,
with particular interests in the role of cultural
theory in project activities and the effect of

performance measurement on operational
effectiveness.

PAPERS72 September 2009 ■ Project Management.docx

Recommandé

Recommandé

Contenu connexe

Similaire à PAPERS72 September 2009 ■ Project Management.docx

Similaire à PAPERS72 September 2009 ■ Project Management.docx (20)

Plus de herbertwilson5999

Plus de herbertwilson5999 (20)

Dernier

Dernier (20)

PAPERS72 September 2009 ■ Project Management.docx