International Journal of Project Management 20 (2002) 49±57

www.elsevier.com/locate/ijproman

Managing project risks: a case study from the utilities sector

Paul Elkington, Clive Smallman *
University of Cambridge, Trumpington Street, Cambridge CB2 1AG, UK

Received 20 January 2000; received in revised form 19 June 2000; accepted 13 July 2000

Abstract
We examine the project risk management practices in a British utility, which manages its information systems and business
change projects using the Prince2TM method. This method has greatly increased the success rate of projects run within the company,
but has little in the way of directing Project Managers in handling project risk. We review current project risk management litera-
ture. We then explore the current usage of risk management in the utility's projects, and determine the e€ect of risk management on
project success. We conclude by outlining recommendations for improving projects run in the utility and elsewhere. # 2001 Elsevier
Science Ltd and IPMA. All rights reserved.
Keywords: Project management; Risk management; Utilities; Case study

1. Introduction detailed knowledge of business processes, and it is likely

In the last decade, British utility (water, power, and
telecommunications) companies have seen an unprece-
dented change to their businesses, a direct result of their
shift from the public to the private sector. The manner
in which utilities manage such change is increasingly via
change programmes. These are either a large set of
changes to just business processes and computer systems,
or changes to company culture and the attitude of its
sta€. The majority are a mix of both. With signi®cant
strategic change being implemented by these programmes,
project and programme management is becoming
increasingly important to the companies' survival, and
much e€ort and resource are being put into ``professio-
nalising'' the project approach undertaken.
The ``less predictable'' nature of projects makes them
riskier than day to day business activities. Hence, risk
management is an integral part of project management
and most large companies put substantial resources into
the management of business risk. However, there is evi-
dence that a culture of risk management may not ®lter
down into every level of a company [1]. Consequently,
companies do not capitalise upon operational sta€'s
* Corresponding author. Tel.: +44-1233-766592; fax: +44-1223-
339701.
E-mail address: c.smallman@jims.cam.ac.uk (C. Smallman).
0263-7863/01/$20.00 # 2001 Elsevier Science Ltd and IPMA. All rights reserved.
PII: S0263-7863(00)00034-X
that many potential risks are not even noticed [2].
We present a study of project risk management prac-
tice in a British utility (henceforth `the Utility').
2. Project management practices in the Utility
Until privatisation, the Utility was the monopoly
supplier and distributor of a public good throughout a
large region of Britain. Since ¯otation and the dereg-
ulation of their businesses, the Utility has diversi®ed in
an attempt to attract new customers, whilst retaining a
strong presence in its traditional markets.
Immediately after privatisation, engineers, many of
whom had joined at sta€ level, dominated the Utility's
senior management. This encouraged a culture in which
small multi-skilled teams e€ected infrastructure main-
tenance; that is through projects. These ran using the
knowledge and experience of the engineers, rather than
formal methods of project management. Risk (usually
only technical systems risk) was considered, but mainly
on an ad hoc basis. Risk management consisted of over-
engineering the infrastructure (using high speci®cation
components where lesser ones would have suced) to
e€ectively build technical risk out, but at massively
increased costs.
The engineering side of the business utilised informal
project management; the rest did not. There were no
50 P. Elkington, C. Smallman / International Journal of Project Management 20 (2002) 49±57
formal project teams and the deliverables from the work
were not always clear. The direction of process work
was largely ad hoc, as the leader of the work usually had
to continue their other duties alongside the changed
work. Such `Project Managers' rarely had training or a
¯air for directing project work. Not surprisingly, many
`projects' that incorporated business change failed to
deliver the bene®ts that were expected.
2.1. The development of a project ethos
In the early 1990s, the Utility was advised to undertake
large business changes by using speci®c programmes, and
to use projects under that programme structure. This
improved the control and overall direction of the business
changes, and more bene®ts were realised than was pre-
viously the case.
However, following the failure of a major business
programme failed in the mid-1990s, senior management
decided that programme management in the Utility
needed to be more `professional'. The aim was to ensure
that future programmes had the best sta€ available and
that training in Programme Management for senior sta€
was provided. As part of this training, it was realised that
the Project Manager level of sta€ in the programmes
were key to the success of each project and therefore the
programme, and that this level of sta€ must also receive
formal training and quali®cations in Project Management.
The project management method, Projects in Con-
trolled Environments 2 (Prince2) [3] was chosen, as it was
a generic project management method. Nearly 100 sta€
were trained in the method, including members of the
Information Systems Division (ISD) Programme Services
section, which also recruited experienced programme
managers. The section manages some business change
programmes and o€ers advice to the rest of the company.
3. Risk management in projects
In Prince2, risk is categorised into two types. Project
risk is de®ned as threats directly to the project, such as
supplier issues, organisational issues and resource
issues. Business risks are those that may a€ect the
delivery of the bene®ts to be gained from the project, for
example the risk that the business case will become
invalid due to changes in the market in which the com-
pany operates.
The process of managing risk begins with risk analy-
sis, which is designed to pick up and gain detail on both
business and project risks, and consists of:
. risk identi®cation to determine potential risks;
. risk estimation to determine the importance of
each risk, based on its likelihood and impact; and
. risk evaluation, which decides whether the level of
risk is acceptable, and if not, what actions can be
undertaken to make the risk acceptable.
The options of which action can be taken to make the
risk acceptable are:
. prevention, where countermeasures are put in
place to stop the threat or problem from arising,
or to prevent it from having any impact on the
project or business;
. reduction, where actions either reduce the like-
lihood of the risk developing, or limit the impact
to acceptable levels;
. transfer of the risk to a third party, for example by
taking out an insurance policy or a penalty clause;
and
. contingency, where actions are planned and orga-
nised to come into force as and when the risk
occurs.
Risk management is the second phase of the Prince2
management of risk framework. Its objective is to inte-
grate the risks identi®ed in the risk analysis stage into
the project management. This is achieved through:
planning the countermeasures identi®ed in the risk ana-
lysis stage; identifying and allocating resources to carry
out the risk avoidance work; monitoring against the
plans that the actions are having the desired e€ect on
the risks; and controlling to ensure that the planned
events actually happen.
Other methods identi®ed also seem to follow the same
broad approach to risk management. Page [4] writes
that risk management should be broken into four
stages, that of comprehensive risk identi®cation of all
sources of risk, objective analysis of their signi®cance,
planning appropriate responses and the management of
those responses.
3.1. Risk identi®cation
Risk identi®cation appears to be the least mentioned of
the risk techniques. It is, however, the most important
stage of risk analysis, as no work can be done on risks
that no one has discovered. Risk identi®cation requires
divergent thinking on the part of the project manager, to
identify potential risks at each stage of the project, but
this investigation is easier if guidelines are set.
Chapman and Ward [5] state that risk identi®cation is
both important and dicult, and that it calls for `some
creativity and imagination'. The identi®cation process
can be made more ecient if the skills and experience of
others can be harnessed. They recommend directed
thinking approaches, such as interviews of individuals
or groups, brainstorming or using checklists. Overall,
they attempt to put more detail into the method of
identifying risks. However, unless it is carefully examined
 P. Elkington, C. Smallman / International Journal of Project Management 20 (2002) 49±57
and broken down as above, it appears complex, and this
is its main failing.
The CCTA's [6] approach is a more detailed version
of that in Prince2. However, the process is, again, very
technical and structured: set the proper context and
perspective for the analysis; gather information on risks;
classify risks based on their causes.
The CCTA [6] approach is procedurally precise, and
answers the question `how do I identify risk?' However, it
does not necessarily o€er users the right information or
the whole picture, and does not mention the imagination
or creativity necessary for e€ective risk identi®cation.
The process directs the project manager to use product
or activity-based planning, and then to look at the risk
of each product. The weakness is that risks may not be
based on products of the project.
Chapman and Ward [5] note that project managers
should also be aware of `positive' risks. Most experienced
project managers focus on the risk of late delivery,
overspend and poor quality in the project products, but
early delivery can also cause signi®cant problems. Even
products that are not on the critical path for the project
can cause problems if they are delivered early.
3.2. Risk estimation
Risk estimation is the Prince2 term for determining
how important the risk is, (potential impact), and what
the likelihood is of the risk occurring. The CCTA [6]
further de®ne the estimation process to be the like-
lihood, consequence and timing of the risk.
It appears that writers do not want to approach this part
of risk management. Dembo and Freeman [7] discuss the
philosophy of risks and on how to decide if a risk is worth
taking, but always seems to start by stating a probability
associated with a risk. They have the `luxury' of operating
in the world of ®nancial risk, where vast statistical
databases instruct probability. Project managers operating
outside of ®nance, facing operational risks, constantly try
to decide the chances of an identi®ed risk occurring. Some
use historical project data, and others use unwritten
past experience, but in many cases, the likelihood of a
risk occurring is derived by means of an educated guess.
Prince2 o€ers no advice to project managers on risk
estimation. However, it appears to recognise the di-
culty project managers face, as it recommends that the
risk register only has the three bands of high, medium
and low likelihood of occurrence, and does not expect
an accurate appraisal. The area of assessing the impact
of the risk on the project has even less advice, but simply
identi®es that some measure should be made.
The CCTA [6] advise that the project manager should
assess the qualitative likelihood of the risk occurring,
but does not o€er up any methods by which to do it.
The `consequences' section does, however, introduce the
notions of time-delimited risks and time-expiring risks.
51
The CCTA [6] take the process further by recom-
mending that the estimation phase is an iterative one,
and that the estimates should be clari®ed and improved
on an ongoing basis.
Again, Chapman and Ward [5] appear to have
thought through the mechanics of the assessment of the
likelihood of a risk occurring. However, as with risk
identi®cation his process is highly technical. Chapman
and Ward [5] suggest the use of incremental scenario
planning to determine both the likelihood and impact of
a risk. This means determining the maximum and mini-
mum impacts of the risk, and then using incremental
steps to decide the impact of scenarios between the
maximum and minimum impact. The same approach is
then used to assign a probability to each scenario. The
approach also encourages several passes of each stage,
to re®ne the thought process. Chapman and Ward [5]
describe methods of probability assessment that will
improve the estimates made above, these include frac-
tile, relative likelihood and probability distribution
functions.
3.3. Risk evaluation
The CCTA [6] take a three-step approach to the eva-
luation stage of the risk management process:
1. Assess the risks against risk indicators and deter-
mine the acceptability of each. This step, unlike
Prince2, suggests that risks may be `grouped' and
have their impact assessed together.
2. Generate alternative paths of action for risks that
do not meet the acceptability criteria. This step is
e€ectively the ®rst stage of the Prince2 method of
determining what action to take with the risk. This
step also recommends that the project manager
should return to the classify risk and cause step if
necessary for further information.
3. Sort risks into ®nal order of priority and cross-
reference to the identi®ed risk reduction options.
The ®nal step sets the actions that the project
manager will take to manage the risk.
Chapman and Ward [5] view the evaluation stage as
central in the risk management process. Throughout,
they emphasise that the stages should be used, as
necessary, to improve the information on a risk and its
management. Looping back into other phases of the
analysis will be necessary to clarify and reassess the
risks. This approach is more detailed than the Prince2
or the CCTA [6] methods, and identi®es four speci®c
steps to the evaluation process:
1. Select an appropriate subset of risks. This is where
risks are grouped into subsets that are appropriate
to the project.
52 P. Elkington, C. Smallman / International Journal of Project Management 20 (2002) 49±57
2. Integrate the subset of risks. For each risk identi-
®ed in the subset, the probabilities and impacts are
integrated. Depending on the risk type, the e€ects
of the risks should be added, multiplied, sub-
tracted or divided, from which graphs of cumula-
tive probability against cumulative cost are
calculated.
3. Portray the e€ect. This allows the project manager
to show the combined e€ect of the risks under study.
4. Diagnose the implications. Look again at the
accuracy and sensitivity of the risk to internal and
external in¯uences.
Chapman and Ward [5] again introduce a detailed
and well thought out method for risk evaluation, they
introduce the concept of evaluating and assessing the
risk as groups, and then determining the impact on the
project in a cumulative manner.
What can Chapman and Ward [5], the CCTA [6] and
others o€er the Utility? First we explore where the Uti-
lity is now.
4. Implementation of current risk management procedures
in the utility
4.1. Study framework
Based on the Utility's approach to project management
and on elements of the theory we derived a framework
Fig. 1. Risk related determinants of project success.
that might explain project success based on the e€ects of
risk (see Fig. 1).
Every project has di€erent risks, and indeed di€erent
levels of risk, so to measure the amount of risk man-
agement undertaken by a project manager without
®rstly examining the project risk pro®le of the project
would compromise the integrity of the results. More
speci®cally we identify the following with the risk pro®le:
1. Business risk is a measure of the risk placed on the
project by the business section or sections to which
the project was delivering.
2. Procurement risk determines the risk of the sup-
pliers that are used in the project. A supplier that
is new to the company, or one that has a variable
reputation about its delivery of projects will pre-
sent more risk to the project.
3. Management risk measures the level of support
given to the project by both the business manage-
ment and the project board management. It also
has a measure to determine the management
approach of the project manager. Higher risk
scores are given if the project is not using a formal
project management technique for example.
4. Technical risk allows a measure of the technology
used in the project, and its complexity, it also
questions the project manager's level of experience
with the technology. Either a new technology or
an inexperienced project manager will increase the
risk score.
 P. Elkington, C. Smallman / International Journal of Project Management 20 (2002) 49±57
Assessing how and when risk management was applied
during the project helps determine items such as the
formality of the risk process, the frequency of the formal
risk management processes being carried out and the
monitoring and control applied to the risk process.
More speci®cally we identify:
1. Brief risk management, which measures the level of
risk management undertaken at the Project Brief
stage.
2. Initiation risk management, which measures the
level of risk management undertaken at the Project
Initiation stage.
3. Stage risk management, which measures the level
of risk management undertaken during the ongoing
project stages.
4. General risk management, which questions the
project manger about their training in, and atti-
tude to risk management.
To determine if management of risk has an in¯uence on
the project outcome, each project must have its success level
measured. The objective was to determine the success of the
project in measurable terms. The project success calculation
was devised by a small group of project managers, in an
attempt to grade the importance of the delivery of the
project to time, on budget and delivering the agreed
bene®ts:
…c:d† ‡ f
Sˆ
t:b
where S is success (project delivering agreed bene®ts, on
schedule and to budget), c is the status of project com-
pletion, d represents level of bene®ts delivered, f is an
estimate of the project manager's satisfaction with the
conduct of the project, t represents performance against
schedule, and b represents performance against budget.
4.2. The instrument
The overall aim of the questionnaire1 was to strike the
balance between gaining the relevant information about
the project whilst not presenting the project manager
with too much work to do to complete the ques-
tionnaire.
The project risk pro®le was assessed using a simple
weighted scoring method. The higher the total risks score
the higher the project risk. The risk pro®le questions
ensure that the main Prince2 method elements were in
place. If they were not, the amount of measured project
risk was increased. The business issues section of the
pro®le determined several aspects of the project life
cycle relating to scheduling and the stability of the
1
Available from the authors.
53
business environment. If the project timing was in¯u-
enced by external factors, the project was deemed to
have more risk. If the project manager to the time scale
set was constrained, the risk score was increased. An
unstable environment is likely to generate scope changes,
and therefore the risk score is increased. The procure-
ment issues section questions the project manager on the
e€ectiveness of suppliers. The management issues section
draws out the relationship with the business and factors
such as the project resources and the project approach.
Any sign of the business or the users not fully supporting
the project increases the risk score. The ®nal section of
the project risk pro®le determines if the technology used
in the project is new, or if it is well established. New
technology is deemed to increase the project risk.
The next section of the questionnaire evaluates how
much risk management the project manager undertook.
The Prince2 method of project management has distinct
stages that the project manager must undertake, for
each of those stages, the method recommends using
certain risk management activities. The amount of risk
management used in this section is referred to as the
usage score. The higher the usage score that each pro-
ject attains, the more risk management was used. The
importance of using risk management throughout the
project life cycle varies, so throughout the questionnaire
the maximum score available in each subsection varies, to
represent this importance. The project brief sub-section
®rstly determines if the project was initiated with a
project brief, and if this stage of the project was carried
out at all. If the ``start up'' phase of the project was
used, the project manager then completes the next ®ve
questions to determine how and to what extent risk
identi®cation and risk evaluation were used. It is
important to understand the di€erence between identi-
®cation and evaluation, risk identi®cation means cap-
turing the possible risks and logging them, but no other
work is done on the risk. Risk evaluation means thinking
through the risk, and determining data such as the like-
lihood and impact of the risk occurring. To ensure that
the questionnaires were ®lled in correctly, each project
manager was given a written de®nition of these terms,
and their understanding con®rmed. The next subsection
concerns the Project Initiation Document. This contains
the business case for the project, and de®nes the objec-
tives of the project (and how they will be achieved). In
the project initiation stage, the ®rst two questions check
the conformance to the project method. The next three
questions again check the level at which risk identi®ca-
tion and evaluation were carried out.
The running of the project was examined in the next
subsection. We sought to determine how and if risk
management was used in the project. The project man-
agers felt that this subsection was a complicated one to
grade. On one hand the risk identi®cation at this stage
in the project life cycle was probably easier, as the risks
54 P. Elkington, C. Smallman / International Journal of Project Management 20 (2002) 49±57
were being highlighted by actually doing the project
work. On the other hand though, the risk evaluation
was as important here as in the project initiation stage,
but the amount of time in which to react to the risk was
probably shorter than if the risk had been seen at an
earlier stage. This led the project managers to believe
the evaluation and reaction to the risk was more
important than at the Project Initiation Stage.
The ®nal section of the questionnaire asks questions
to determine the project managers knowledge of risk
management, and their attitude to it. After much dis-
cussion, the project managers determined that the atti-
tude of the project manager towards risk in¯uenced the
e€ective use of it. The ®rst two questions determine if
the project manager is aware of any formal techniques
of risk management other than those used in Prince2.
These questions do not have high scores attached to
them, as the managers may try their best with risk
management despite not having formal training. The
next ®ve questions go some way to determining the
project managers attitude to the area of project risk
management. They highlight if the risk work done during
the project was seen as useful or just as a part of the
method that should be used.
The ®nal section investigates if the project was a success.
It is rarely the case that projects are a complete success
or failure, so this section asks the project manager to
what extent the project succeeded. This information will
be used in conjunction with the data from the previous
two sections to discover if there is a link between the
amount of risk management used and the success of the
project. The ®rst question asks if the project was com-
pleted as planned. The next ®ve questions ask the project
manager to state how well the project did against its
planned delivery. The measures here are the bene®ts, the
time and the cost. It is important to get all three mea-
sures to determine the success, as it is possible to com-
plete a project to time, and to budget, but not actually
deliver any of the expected bene®ts for the business. The
®nal question in the questionnaire asks the project
manager to summarise how they feel the project went,
this is a valuable question, as all the previous questions
determine what the results were by the end of the pro-
ject. Projects can sometimes run very badly, but in the
end they come together and the objectives are met, this
®nal question allows scope for the project manager to
summarise the feeling of the project throughout its life
cycle.
The overall success factor of the project was the most
dicult to grade. The importance of the three factors of
delivered bene®ts, cost and time will be di€erent in
every company, and to some extent also di€erent for
each project within that company. Many options to
determine the overall success of the project were dis-
cussed by the project managers, and some data were
created to attempt to create a formula which represented
the ``gut feel'' of how successful a project would be seen
as under the current business climate.
4.3. Sample and response
A questionnaire was sent to each of the 20 project
managers throughout the company. From that 20, seven
project managers responded that they had not com-
pleted a project through the entire project life cycle, and
were unable to complete the questionnaire, a further
two stated that their projects had been service projects,
and the bene®ts appraisal had not been carried out. One
project manager asked for a further questionnaire,
therefore, 12 questionnaires were completed. Upon
examining the data, two questionnaires had to be dis-
carded, as they were not suciently complete. There-
fore, 10 completed questionnaires were analysed.
4.4. Analysis
In orthodox academic research, working with so few
observations can be dicult, although in essence each
observation represents a mini-case study of project risk
management practice. However, traditional methods of
statistical analysis are largely in applicable to such small
data sets. In particular, the application of multivariate
analysis is particularly dicult in these circumstances.
Hence, we chose not to analyse the relationship between
success and risk types, and the level of risk management
undertaken. Instead, our analysis is based on observa-
tion and discussion between colleagues and ourselves.
More data would allow the use of predictive methods.
That said, we remind the reader that this work is pre-
sented as a case study of one company's experiences. We
regard this as a starting point for encouraging further
discussion on project risk management, and certainly
not ``de®nitive research''. Hence, we advise caution in
the interpretation of our ®ndings, but would also point
to the value of reporting what is essentially a feasibility
study, which breaks ground for further work.
4.5. Findings
Initial analysis of the overall results (see Table 1)
revealed that one project is very di€erent from the oth-
ers: project questionnaire number nine has a project
pro®le risk of 31, a level of risk management of 18, and
a project success score of 81. These numbers apparently
go against the trend presented by the other projects. It is
interesting that the project success score is ranked
fourth overall, with a relatively high score of 81, but the
project risk pro®le ranks the project as the second most
risky, and that the level of risk management applied is
the lowest of all the projects measured. By far the most
interesting fact is, that despite the success of the project
as measured against bene®ts, time and cost, the manager
 P. Elkington, C. Smallman / International Journal of Project Management 20 (2002) 49±57 55

of this project chose to state that only ``some parts also does not appear to have much of an in¯uence on
[were] successful'' in the project. It appears that project the outcome of the project, as medium and low risk
number nine was delivered successfully by the project projects vary in their positions of success.
manager, but it could have been more by luck than Technical risk however does present a small pattern,
judgement. Due to the nature of this project, the analy- with all of the low risk projects being more successful
sis was reworked, excluding the distortions introduced than either high or medium risk projects. The questions
by this project. asked in the technical risk section of the questionnaire
There is a weak relationship between the amount of determine how new the technology is, how complex the
project risk and the level of risk management (r=0.63). project technical architecture is, and how experienced
Comparison of risk management and project success the project manager is with that speci®c technology. It
shows a strong link (r=0.80 at the 95% con®dence appears that within the Utility projects, project man-
level). Hence, the more risk management undertaken in agers can manage business, procurement and manage-
a project, the higher the chance of project success. ment risk, but if they are not experienced in the
Comparing the amount of project risk and the level of technical elements of the project, the chance of the pro-
success shows a strong relationship (r=0.73), and this ject succeeding is reduced.
suggests that the riskier the project manager thought the The results from the questionnaire were broken into
project was at the start, the less the project succeeded. subsections for the level of risk management under-
Alternatively, due to the nature of the data gathering, taken. Table 3 shows the results, and again project nine
(all assessments were done after the completion of the has been excluded.
projects), it may be that if project managers felt they Managing risks in one stage of the project is likely to
had not done well in the project, they graded the project a€ect the management in the next stage. The amount of
riskier at inception. risk management undertaken in the Project Brief stage
Dividing the amount of project risk by level of risk of the project appears to be directly linked to the success
management corrects for any extra risk management the of the project. The order of the amount of e€ort put in
project manager put into the project, because they at this stage matches the order of the project success
thought the project was risky from the outset. Compar- score. During the initiation stage of the project, the ®ve
ing this ratio with the success rate for a project gives a
more accurate picture of the risk:success relationship.
Table 2
The result from this analysis must be approached with Risk type and project success
caution. The two measures of level of risk management
and amount of project risk are not ``scaled'' (the max- Project Business Procurement Management Technical Success
number risk risk risk risk score
imum scores are not the same, and the amount of
activity needed for a high or low score for each is likely
to be di€erent). That said there is a strong link between 3 High Medium Low Low 105
risk and the level of success (r=0.80). Hence, riskier 1 High Medium Medium Low 100
7 Medium Low Low Low 92
projects seem to do less well, even if more risk manage- 4 Medium Medium Low Low 62
ment is applied. 8 High Medium Low Medium 58
The level of business risk does not have a strong 6 High Medium Low High 44
bearing on the success of the project, with high business 2 High Medium Medium Medium 28
risk projects being both successful and unsuccessful (see 5 High Medium Low High 18
10 High High High Medium 0
Table 2). The level of procurement or management risk

Table 3
Table 1 Level of risk management undertaken
Overall results
Project Brief Initiation Project General Success
Project Risk score Management score Success score number stage stage stages score

1 26 39 100
2 26 25 28 3 High High High Medium 105
3 23 45 105 1 Medium High High Medium 100
4 19 40 62 7 Medium High Low Medium 92
5 29 33 18 4 Medium Medium Medium High 62
6 28 31 44 8 Medium Medium Medium Medium 58
7 17 32 123 6 Low High Medium High 44
8 25 32 58 2 Low Low High Low 28
9 31 18 81 5 Low High High High 18
10 38 20 0 10 Low Low Low Medium 0
56 P. Elkington, C. Smallman / International Journal of Project Management 20 (2002) 49±57
most successful projects had either high or medium
amounts of e€ort put into the risk management. How-
ever, the rest of the order does not have a pattern, so it
appears that the initiation stage alone does not deter-
mine the success of the project. The amount of project
risk management during the project stages also has no
de®nite pattern. Finally, no obvious pattern is seen in
general risk management indicating that the areas of the
project managers' attitude to risk do not overly e€ect
the success of the project.
Further analysis reveals that the success of the project
is greater. If more risk management is applied. More
particularly the greater the risk management at the early
Project Brief stage of the project, the more likely the
project is to succeed. It appears that this pattern does
not develop just due to the extra scores attained by
using risk management earlier in the project. Projects
that show high amounts of risk after the Project Brief
stage do not seem to ``catch up'' with those who start
early on in the project. This can be seen best in projects
four, eight, six and ®ve. Projects four and eight both
have medium e€ort put into risk management at the
brief stage, followed by medium e€ort in the two
remaining stages. These projects both rank above pro-
jects six and ®ve in the success score rating. Project six
has a low rating for the risk management at the Project
Brief stage, and the following stages are high and then
medium rated, project ®ve again has a low ®rst stage score,
but is followed by two high ratings for the later stages.
Hence, projects that undertake risk management at
the earliest stages of the project will have more chance
in succeeding. If the project managers that assisted in
the weightings for the level of risk management knew of
this information, they may not have stated that this
early Project Brief stage was not as important as the
ones to follow. This may in turn have shown a stronger
link between the total risk management in the project,
and the level of the projects success.
5. Conclusions
We have identi®ed that there is a strong link between
the amount of risk management undertaken in a pro-
ject, and the level of success of the project, more suc-
cessful projects use more risk management. Also the
earlier that risk management was used in a project, the
more successful it was. Furthermore, eight of the project
managers felt that they could bene®t from further
training in risk management, highlighting that the
Prince2 method is weak in this area. The structured
project management approach of Prince2 has brought
many improvements to the way in which the Utility
runs projects, but it should be seen a the latest
improvement rather than the overall answer to the pro-
ject management skills in the company.
Whilst our ®ndings point to general areas that could
bene®t from further analysis, the limitations of both the
analysis and the interpretation of the questionnaire
should be considered. The signi®cant statistical rela-
tionship between the level of risk management and the
level of project success may be as a result of the man-
agers who undertook the project. Further study into all
elements of the way in which the project were run would
have to be undertaken to determine if one element
improved the project success rate fundamentally.
The pattern that the level of risk management under-
taken at the project brief stage would in¯uence the level
of success of the project may also be due to a more
thorough approach to project management. This area of
project management could also be investigated
The level of technical risk in the project a€ecting the
results could be due the fact that all the projects were
reported after completion. Perhaps project managers,
when looking back on a dicult or unsuccessful project,
tried to justify the diculty by increasing the technical
risk. There are alternative explanations. Whilst all pro-
ject managers in the Utility are now trained in Prince2,
the method does not speci®cally teach risk management
skills. So more experienced project managers may have
developed risk management skills that make their pro-
jects more successful. Also, Prince2 states that the early
parts of the project are important, and the extra e€orts
put into risk management at the project brief stage may
increase the overall success of the project. Finally it
should be noted that methods of dealing with problems
with both business and management risk are highlighted
in Prince2, and procurement risks are dealt with by legal
departments within the Utility. Technical risk is the
only section highlighted in the questionnaire that a
project manager cannot easily get help with.
It is essential that the risks of a project be assessed at
the Project Brief stage. Risks identi®ed here will not only
help the production of the necessary project products, but
will increase the chance of overall project success. The
current process that the Utility uses for risk management
is weak and an alternative should be used. Chapman
and Ward [5] o€er some ideas, but the complexity of much
of their suggested framework may prove too complex for
any organisation where project management is not a
fully mature discipline. The CCTA [6] also o€er ideas,
but their approach su€ers from similar problems. How-
ever, adapting these approaches and ®tting them with
our ®ndings, we have derived the following approach.
1. Risk Identi®cation is mostly informal, and a check-
list of things to think about is most appropriate:
(a) identify the risks obvious to you ®rst, and write
them down;
(b) think of the who, why, what, which way,
wherewithal and when of the project, and at
 P. Elkington, C. Smallman / International Journal of Project Management 20 (2002) 49±57
each step, identify possible risks;
(c) identify risks that come from the actual run-
ning of the project cycle, such as resources and
quality;
(d) identify positive risks, such as early delivery of
products, as well as negative risks;
(e) be imaginative, it is easy to remove risks later
on in the process, but much harder to manage
ones you did not see.
(f) risk identi®cation is more easily done in small
groups or informal interviews to get others
involved.
2. Risk estimation
(a) assess the likelihood, consequences and timing
of the risks identi®ed;
(b) likelihood information can be improved by
conferring with other managers and using sce-
narios;
(c) timing of the risks is important;
(d) consequences should be identi®ed, and if pos-
sible the cost of the consequence calculated;
(e) clarify and improve the estimates.
3. Risk Evaluation. Risks should be examined both
individually and for their combined impact on the
project.
57
4. Act: prevent, reduce, transfer, plan for con-
tingencies, or accept.
5. Keep doing it.
We would observe that the issue of project risk man-
agement is surely common to a greater or lesser extent
in many organisations. Moving the practice of project
risk management forward, therefore, is important. Fur-
thermore, the London Stock Exchange' risk reporting
requirements (following the development of the Com-
bined Code on Corporate Governance [2]), means that
it is imperative for all organisations to get to grips with
risk in all of its forms.
References
[1] Perkins P. Project risk management Ð brought to fruition.
International Risk Management, 17 May 1999.
[2] Smallman C. The risk factor. Financial Times Mastering Man-
agement Review 1999;30:42±5.
[3] CCTA. Managing successful projects with Prince2. London: The
Stationary Oce, 1996.
[4] Page Y. No change at the top Ð world's top 40 risk management
survey. International Risk Management, 1998, June, 32.
[5] Chapman CB, Ward SC. Project risk management, processes tech-
niques and insights. Chichester: John Wiley and Sons Ltd, 1997.
[6] CCTA. An introduction to managing project risk. London:
HMSO, 1995.
[7] Dembo RS, Freeman A. Seeing tomorrow, rewriting the rules of
risk. New York: John Wiley and Sons, 1998.