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.
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
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 . Consequently, companies do not capitalise upon operational sta\u0080's
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.
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.
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)  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.
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.
place to stop the threat or problem from arising, or to prevent it from having any impact on the project or business;
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  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.
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  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
The CCTA's  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  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  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.
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  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  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  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  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  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  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  describe methods of probability assessment that will improve the estimates made above, these include frac- tile, relative likelihood and probability distribution functions.
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  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  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.
Now bringing you back...
Does that email address look wrong? Try again with a different email.