Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Managing Project Risks

Managing Project Risks

Ratings: (0)|Views: 516 |Likes:
Published by api-3707091

More info:

Published by: api-3707091 on Oct 14, 2008
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





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

We examine the project risk management practices in a British utility, which manages its information systems and business change projects using the Prince2TMmethod. 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\u0080ect 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

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\u0080. The majority are a mix of both. With signi\u00aecant strategic change being implemented by these programmes, project and programme management is becoming increasingly important to the companies' survival, and much e\u0080ort 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 \u00aelter down into every level of a company [1]. Consequently, companies do not capitalise upon operational sta\u0080's

detailed knowledge of business processes, and it is likely
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 \u00afotation and the dereg- ulation of their businesses, the Utility has diversi\u00aeed 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\u0080 level, dominated the Utility's senior management. This encouraged a culture in which small multi-skilled teams e\u0080ected 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 anad hoc basis. Risk management consisted of over- engineering the infrastructure (using high speci\u00aecation components where lesser ones would have su\u0081ced) to e\u0080ectively 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
0263-7863/01/$20.00# 2001 Elsevier Science Ltd and IPMA. All rights reserved.
PII: S0263-7863(00)00034-X
International Journal of Project Management 20 (2002) 49\u00b157
* Corresponding author. Tel.: +44-1233-766592; fax: +44-1223-
E-mail address:c.smallman@jims.cam.ac.uk (C. Smallman).

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 \u00afair for directing project work. Not surprisingly, many `projects' that incorporated business change failed to deliver the bene\u00aets 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\u00aec programmes, and to use projects under that programme structure. This improved the control and overall direction of the business changes, and more bene\u00aets 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\u0080 available and that training in Programme Management for senior sta\u0080 was provided. As part of this training, it was realised that the Project Manager level of sta\u0080 in the programmes were key to the success of each project and therefore the programme, and that this level of sta\u0080 must also receive formal training and quali\u00aecations 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\u0080 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\u0080ers advice to the rest of the company.

3. Risk management in projects
In Prince2, risk is categorised into two types.Project
riskis de\u00aened as threats directly to the project, such as

supplier issues, organisational issues and resource issues.Business risks are those that may a\u0080ect the delivery of the bene\u00aets 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 withrisk analy-
sis, which is designed to pick up and gain detail on both
business and project risks, and consists of:
.risk identi\u00aecation 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;
.contingency, where actions are planned and orga-
nised to come into force as and when the risk
Risk managementis the second phase of the Prince2

management of risk framework. Its objective is to inte- grate the risks identi\u00aeed in the risk analysis stage into the project management. This is achieved through: planning the countermeasures identi\u00aeed 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\u0080ect on the risks; and controlling to ensure that the planned events actually happen.

Other methods identi\u00aeed 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\u00aecation of all sources of risk, objective analysis of their signi\u00aecance, planning appropriate responses and the management of those responses.

3.1. Risk identi\u00aecation

Risk identi\u00aecation 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\u00aecation 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\u00aecation is both important and di\u0081cult, and that it calls for `some creativity and imagination'. The identi\u00aecation process can be made more e\u0081cient 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\u00b157
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\u0080er users the right information or the whole picture, and does not mention the imagination or creativity necessary for e\u0080ective risk identi\u00aecation. 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\u00aecant 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\u00aene 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 \u00aenancial risk, where vast statistical databases instruct probability. Project managers operating outside of \u00aenance, facing operational risks, constantly try to decide the chances of an identi\u00aeed 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\u0080ers no advice to project managers on risk estimation. However, it appears to recognise the di\u0081- 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\u00aees 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\u0080er up any methods by which to do it. The `consequences' section does, however, introduce the notions of time-delimited risks and time-expiring risks.

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\u00aeed 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\u00aecation 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\u00aene 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\u0080ectively the \u00aerst 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 \u00aenal order of priority and cross- reference to the identi\u00aeed risk reduction options. The \u00aenal 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\u00aees four speci\u00aec 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.

P. Elkington, C. Smallman / International Journal of Project Management 20 (2002) 49\u00b157

Activity (23)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
Kaustubhthedon liked this
danydanyely liked this
shak10088596 liked this
Anil_MBA liked this
hamedmr liked this
shewal liked this
bnravi liked this
denagany liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->