Managing project risks: a case study from the utilities sector

Transcription

1 International Journal of Project Management ) 49±57 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 Prince2 TM 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 literature. 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 In the last decade, British utility water, power, and telecommunications) companies have seen an unprecedented 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 ``professionalising'' 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 evidence 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.: ; fax: address: c.smallman@jims.cam.ac.uk C. Smallman). 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 practice 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 deregulation 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 maintenance; 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 overengineering 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 /01/$20.00 # 2001 Elsevier Science Ltd and IPMA. All rights reserved. PII: S )00034-X

2 50 P. Elkington, C. Smallman / International Journal of Project Management ) 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 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 previously 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 Controlled 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 company operates. The process of managing risk begins with risk analysis, 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 likelihood 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 organised 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 integrate 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 analysis 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 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

3 P. Elkington, C. Smallman / International Journal of Project Management ) 49±57 51 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 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 likelihood, 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. The CCTA [6] take the process further by recommending 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 minimum 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 fractile, relative likelihood and probability distribution functions Risk evaluation The CCTA [6] take a three-step approach to the evaluation stage of the risk management process: 1. Assess the risks against risk indicators and determine 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 crossreference 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.

4 52 P. Elkington, C. Smallman / International Journal of Project Management ) 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, subtracted or divided, from which graphs of cumulative 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 Utility 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 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 management 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 suppliers 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 present more risk to the project. 3. Management risk measures the level of support given to the project by both the business management 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. Fig. 1. Risk related determinants of project success.

5 P. Elkington, C. Smallman / International Journal of Project Management ) 49±57 53 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 attitude 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: S ˆ c:d f t:b where S is success project delivering agreed bene ts, on schedule and to budget), c is the status of project completion, 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 The instrument The overall aim of the questionnaire 1 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 questionnaire. 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. business environment. If the project timing was in uenced 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 procurement 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 project 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 capturing 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 likelihood 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 objectives 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 cation 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 managers 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

6 54 P. Elkington, C. Smallman / International Journal of Project Management ) 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 discussion, the project managers determined that the attitude 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 completed 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 measures to determine the success, as it is possible to complete 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 project. 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 discussed 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 Sample and response A questionnaire was sent to each of the 20project managers throughout the company. From that 20, seven project managers responded that they had not completed 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 discarded, as they were not su ciently complete. Therefore, 10completed questionnaires were analysed 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 observation 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 presented 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 Findings Initial analysis of the overall results see Table 1) revealed that one project is very di erent from the others: 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

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

8 56 P. Elkington, C. Smallman / International Journal of Project Management ) 49±57 most successful projects had either high or medium amounts of e ort put into the risk management. However, the rest of the order does not have a pattern, so it appears that the initiation stage alone does not determine 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 projects 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 project, and the level of success of the project, more successful 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 project 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 relationship between the level of risk management and the level of project success may be as a result of the managers 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 undertaken 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 project 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 projects 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. However, adapting these approaches and tting them with our ndings, we have derived the following approach. 1. Risk Identi cation is mostly informal, and a checklist 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

9 P. Elkington, C. Smallman / International Journal of Project Management ) 49±57 57 each step, identify possible risks; c) identify risks that come from the actual running 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 scenarios; c) timing of the risks is important; d) consequences should be identi ed, and if possible 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. 4. Act: prevent, reduce, transfer, plan for contingencies, or accept. 5. Keep doing it. We would observe that the issue of project risk management is surely common to a greater or lesser extent in many organisations. Moving the practice of project risk management forward, therefore, is important. Furthermore, the London Stock Exchange' risk reporting requirements following the development of the Combined 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 [2] Smallman C. The risk factor. Financial Times Mastering Management Review 1999;30:42±5. [3] CCTA. Managing successful projects with Prince2. London: The Stationary O ce, [4] Page Y. No change at the top Ð world's top 40risk management survey. International Risk Management, 1998, June, 32. [5] Chapman CB, Ward SC. Project risk management, processes techniques and insights. Chichester: John Wiley and Sons Ltd, [6] CCTA. An introduction to managing project risk. London: HMSO, [7] Dembo RS, Freeman A. Seeing tomorrow, rewriting the rules of risk. New York: John Wiley and Sons, 1998.