Risk Management for Dummies – A Case Study

RISK MANAGEMENT FOR DUMMIES ? A CASE STUDY

Marie-Louise Barry Project Manager Radar, CSIR, Defencetek, P O Box 392, Pretoria, 0001, mlbarry@csir.co.za

INTRODUCTION

The first question that someone uninitiated in the joys of project management might ask is, "What is risk management and why is it required on projects?"

The major task of any project manager is to ensure that a project finishes within the original budget, with the required scope of work and within the required timescales, and to ensure that throughout this process all the stakeholders, especially the client, are satisfied with the project results.

Project risks can thus be defined as events which prevent the project from being completed within the original budget, scope and timescales or that make the stakeholders displeased.

Some projects that did not meet the original budget, timescales or project scope are shown in Table 1.

Table 1: Examples of failed projects [1].

Project Description Construction of the Opera House Vienna General hospital

Sydney

Mossgas

Trans Alaska Pipeline system

Spacecraft challenger

Original plan Original budget: $ 6 million

Original budget: $ 317 million Scheduled completion: 1968 Original budget: R 3 Billion

Original budget: $ 900 million

Successful trip to the moon with civilian on board

Final result Final cost: $ 100 million which is 16 times the bid price Final cost: $ 4 Billion Final completion: 1986 ? 16 years late Final cost: "R14 Billion" which is 4,67 X the original estimate. Final cost: $ 8 billion +; $1,5 billion of which was lost in fraud and mismanagement. Explosion 73.213 seconds into launch killing six astronauts and one school teacher

From the above it is clear that projects are a risky business to be in as a lot can go wrong, go wrong....

OVERVIEW

The purpose of this paper is to examine a risk management process that was applied to a portion of project work done at CSIR, Defencetek (Defencetek). A very extensive process was followed. The paper will examine which of the steps followed added the most value, and will in conclusion suggest a very simple risk management process that can be used to identify and manage risks when a more detailed process is not required.

A brief background will be given of the project. The approach followed will then be discussed, after which the Pareto principle will be used and the 20% of the process that added 80% of the value will be discussed.

Paper presented at African Rhythm Project Management Conference Hosted by: Project Management Institute of South Africa (PMISA): .za

22 ? 24 April 2002, Johannesburg, South Africa ISBN Number: 0-620-28853-1

BACKGROUND TO THE ROOFSAR

The project of this case study is the development of an experimental Synthetic Aperture Radar (SAR) currently in process at Defencetek. Due to the prohibitive costs of test flights, the synthetic aperture is obtained by operating the radar on a rail on Defencetek's roof.

The project has been running at Defencetek over a number of years. The objective for 2001 was to obtain the first images. At the point that the risk management process was started, the outstanding work for the year, that was considered risky, was as follows:

Final integration. System performance analysis. System calibration. Target imaging experiments.

The work breakdown structure of this work is shown in Table 2.

Table 2: Work Breakdown Structure (WBS) of the RoofSAR work included in the risk process.

22.1.1.1.1 FFininaal lininteteggraratitoionn

22.1.1 RRoooofSfSAARR22000011

22.1.1.2.2 PPeerfroformrmaanncceeaannaalylyssisis

22.1.1.3.3 CCaalilbibraratitoionn

22.1.1.4.4 EExxppeerirmimeenntsts

2.1.1.1 Roof integration

Mechanical System test Generate image Client demo

2.1.1.2 Characterization

2.1.2.1 Generate images

2.1.2.2 Analyze images

2.1.2.3 Generate report

2.1.3.1 Arrange targets

2.1.3.2 Perform experiments

2.1.3.3 Data analysis

2.1.3.4 Generate report

2.1.4.1 Generate images

2.1.4.2 Analyze images

2.1.4.3 Generate report

2.1.4.4 Generate report

RISK MANAGEMENT PROCESS FOLLOWED

The risk management process advocated in Chapman et al [2] was followed. The main aspects of the process are shown in Table 3.

Table 3: Risk Management process followed [2].

DDeeffininee FFooccuuss IIddeenntitfifyy SStrtruucctuturree OOwwnneerrsshhipip EEsstitmimaatete EEvvaaluluaatete PPlalann MMaannaaggee

Define phase This phase involved the definition of project stakeholders, documenting project objectives, documenting of the design as well as the updating of the WBS and schedule. As the project had been in existence for a time most of this information was in existence and was now consolidated into the risk management plan.

The WBS for the portion of the work that remained for the year was updated and used for the risk management process (See Table 2).

Focus phase This phase involved the identification of the risk management stakeholders and also documented the risk management process to be followed, which is the process described in this paper. The corporate level risks were also identified as well as the resources and schedule for the risk management process.

Identify phase The risk identification was carried out with the help of the project system engineer and the project engineer. Risks were identified per WBS item. The approach in PM Network, August 2001, page 18 [4] was followed. This involves writing down each risk identified per WBS item on a Post-it.

The first ten risks identified per WBS item are shown in Table 4. Only ten risks will be used for illustration purposes although 26 risks in all were identified.

Table 4: Risks identified per WBS item.

WBS No 2.1.1 2.1.1.8, 2.1.1.9, 2.1.5 2.1.1.8.1 2.1.1.8.1 2.1.1.8.1 2.1.1.8.1 2.1.1.8.1 2.1.1.8.2 2.1.1.8.2 2.1.1.8.2

Risk No 1 2 3 4 5 6 7 8 9 10

Risks identified Availability of System Engineer Adverse Weather Compact PCI failure Antenna feed misalignment Box too small to contain all equipment Reflectors for the MMTU missing Cabling faulty Power supply failure IDE hard-disk crash MMTU no longer operational

For each identified risk a risk response was decided upon, written on another Post-it and attached to the risk identified. Examples of the risk responses developed are shown in Table 5.

Table 5: Risk responses.

WBS No 2.1.1

2.1.1.8.2 2.1.1.8.3

Risk No 1

13 15

Risks identified Availability of System Engineer

SCSI disk crash Resolution > 1 metre and side-lobes not in the order of 30dB.

Detailed risk response Ensure that SE is available by making arrangements with his centre manager. Develop a knowledge management plan for the project to ensure that the correct knowledge is captured. Ensure that project engineer is properly trained on the RoofSAR. Check on the availability of SCSI drives. Purchase a spare SCSI drive if cost effective. Do calibration next instead of target imaging experiments This means that the client demo will most probably not be possible this financial year. The loss of face to the SANDF must be carefully managed.

Structure phase During the structure phase a risk distribution matrix was drawn on a whiteboard. Each risk was then allocated a place on the matrix. A risk prioritisation table was compiled using this matrix. A more detailed risk response was then developed for risks with a priority of 1. The risk related links were explored using a block diagram in terms of the effect of each risk on customer satisfaction.

The links between the risks with the highest priority are shown in Table 6. For purposes of drawing up the diagram, the risks were divided into resource, technical, equipment and schedule and budget risks.

Table 6: Links between risks with the highest priority.

EEqquuipipmmeennt:t: 1133. .SSCCSSIIddisikskccrarashsh 1199. .TTrarannspspoortrt22ndndMMaastst 2200. .CCoommppreresssosorr22ndndMMaastst

SScchheedduuleleaannddBBuuddggeet:t: 2233. .TTimimeefoforreexxppeerirmimeenntsts

lolonnggeer r 2244. .TTimimeetotoaannswsweerrlolonnggeerr 2266. .TTimimeeaannddbbuuddggeet t

lilmimitiatatitoionnssfofor rththisisyyeeaar r

CCuustsotommeer rsasatitsifsafacctitoionn

RReesosouurcrcees:s: 11. .AAvvaailialabbiliiltiytyooffSSEE

TTeecchhnnicicaal:l: 1155. .RReesosolulutitoionn

Ownership phase The purpose of this project was to create in-house knowledge at Defencetek, and for this reason all risks had to be handled internally and could not be sub-contracted.

During this phase the name of the person responsible for the risk was written on the Post-it detailing each risk. This was used to complete the risk responsibility allocation table. The project system engineer and the project engineer thus accepted the risks allocated to them because they were involved with the process. The risks were then discussed with the project technician to ensure that he also accepted responsibility for the risks allocated to him. The responsibilities allocated are shown in Table 15.

Estimate phase The estimate process was carried out in two ways. The likelihood and impact of the high-level WBS tasks were estimated as follows:

For each of the high-level WBS items the likelihood of failure was determined as shown in Table 7 using Table 8.

Table 7: Task level risk likelihood determination.

WBS No Description 2.1.1.8 Integration on the Roof

MH MS CH CS D **Composite likelihood factor (CLF) 0.5 0.7 0.7 0.5 0.9 0.66

2.1.1.9 System Characterisation

0.5 0.9 0.7 0.5 0.9 0.70

2.1.3 System performance analysis 0.7 0.9 0.9 0.9 0.9 0.86

2.1.4 System Calibration

0.7 0.9 0.9 0.9 0.9 0.86

2.1.5 Target Imaging Experiments 0.7 0.9 0.9 0.7 0.9 0.82

** CLF = W1*MH + W2*MS + W3*CH + W4*CS + W5*D where W1+W2+W3+W4+W5 = 1 and W1=W2=W3=W4=W5=0.2

Table 8: Likelihood of risk determination table [3].

Likelihood 0,1 (low) 0,3 (minor)

MH Existing

Minor redesign

MS Existing

Minor redesign

CH Simple design

Minor complexity

0,5

Major

change Major

(moderate) feasible

feasible

change Moderate complexity

0,7

Complex design New, but similar to Significant

(significant) technology exists existing software complexity

0,9 (high)

State of the art; State of the art; Extreme

some research done never done

complexity

Where: MH is the failure likelihood due to immaturity of hardware MS is the failure likelihood due to immaturity of software CH is the failure likelihood due to complexity of hardware CS is the failure likelihood due to complexity of software D is the failure likelihood due to dependency on external factors

CS Simple design

D Independent

Minor complexity

Moderate complexity

Significant complexity

Extreme complexity

Schedule dependent on existing system Performance dependent on existing system Schedule dependent on new system Performance dependant on new system

For each high-level WBS item the impact of risk was determined as shown in Table 9 using Table 10.

Table 9: Task level risk impact determination.

WBS No Description

Technical Impact Cost Impact Schedule

2.1.1.8 Integration on the Roof

0.9

2.1.1.9 System Characterisation

0.9

2.1.3 System performance analysis 0.7

2.1.4 System Calibration

0.9

2.1.5 Target Imaging Experiments 0.7

**CIF = W1*TI + W2*CI+W3*SI

0.1

0.1

0.1

0.1

0.9

0.9

0.9

0.9

0.1

0.1

** Composite Factor (CIF)

0.37 0.37 0.83 0.90 0.30

Impact

 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download