Risk Management for Dummies – A Case Study

[Pages:12]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

Table 10: Impact of risk determination table [3].

Impact Value 0,1 (low) 0,3 (minor) 0,5 (moderate) 0,7 (significant) 0,9 (high)

Technical Impact Minimal Small reduction in performance Moderate reduction in performance Significant reduction in performance Technical goals might not be achievable

Cost Impact Within budget 1-10% cost increase 10-25% cost increase 25-50% cost increase Cost increase > 50%

Schedule Impact Negligible Minor slip < 1 month Moderate slip 1-3 months Significant slip > 3 months Large slip (unacceptable)

The project manager, project system engineer and project engineer were each given a list of the identified risks and asked to estimate the likelihood and impact of each risk. The average of each figure was then calculated as shown in Table 11.

Table 11: Risk likelihood and impact determination.

Willie Nel

Jan Tait

Risks identified

Likelihd Impact Likelihd Impact

Availability of Willie Nel

0.8

0.8 0.5

0.9

Adverse Weather

0.3

0.5 0.5

0.5

Compact PCI failure

0.4

1.0 0.1

0.9

Antenna feed misalignment

0.6

0.3 0.25 0.1

Box too small to contain all 0.8

0.2 0.25 0.5

equipment

Reflectors for the MMTU missing 0.9

0.2

Cabling faulty

0.2

0.2 0.1

0.3

Power supply failure

0.1

1.0 0.1

0.9

IDE hard-disk crash

0.1

0.9 0.1

0.8

MMTU no longer operational

0.1

0.3

ML Barry

Average

Likelihd Impact Likelihd Impact

0.9

0.9 0.73 0.87

0.6

0.7 0.47 0.57

0.4

0.9 0.30 0.93

0.4

0.2 0.42 0.20

0.8

0.1 0.62 0.27

0.6

0.1 0.75 0.15

0.3

0.3 0.20 0.27

0.3

0.9 0.17 0.93

0.3

0.8 0.17 0.83

0.4

0.4 0.25 0.35

Evaluate phase During the evaluate phase the likelihood and impact determined during the estimate phase were used to determine a risk value both for the high-level tasks and then at the level of each risk as follows:

Risk = Likelihood*Impact but

a qualitative risk rating will then be given to each task using Table 12, also taking into account that risks with high impact are important.

Table 12: Qualitative rating of risks.

Qualitative rating Low Medium High

Numerical Equivalent

0

- 0.2

0.21

- 0.5

0.51

- 1

For the high-level tasks the risk ratings in Table 13 were then obtained.

Table 13: High-level tasks risk ratings.

WBS No Description

CLF

CIF

2.1.1.8 Integration on the Roof

0.66

0.37

2.1.1.9 System Characterisation

0.7

0.37

2.1.3 System performance analysis 0.86

0.83

2.1.4 System Calibration

0.86

0.90

2.1.5 Target Imaging Experiments 0.82

0.30

Risk for each task Qualitative rating

0.24

Medium

0.26

Medium

0.72

High

0.77

High

0.25

Medium

Examples of the ratings obtained per identified risk are shown in Table 14.

Note that where the impact of a risk is above 0.8, the risk obtained a qualitative rating of high, whether the risk value was above 0.8 or not. This is due to the fact that risks with high impact need to be carefully managed.

Due to the fact that this is not a very large project and only 26 risks were identified in all, it was decided that all the risks would be monitored during the management phase.

Table 14: Ratings per identified risk.

Risks identified

Average Likelihood

Impact

Risk

Availability of Willie Nel

0.73

0.87

0.64

Adverse Weather

0.47

0.57

0.26

Compact PCI failure

0.30

0.93

0.28

Antenna feed misalignment

0.42

0.20

0.08

Box too small to contain all equipment 0.62

0.27

0.16

Reflectors for the MMTU missing

0.75

0.15

0.11

Cabling faulty

0.20

0.27

0.05

Power supply failure

0.17

0.93

0.16

IDE hard-disk crash

0.17

0.83

0.14

MMTU no longer operational

0.25

0.35

0.09

Qualitative rating

High Medium High Low Low Low Low High High Low

Plan phase During the plan phase the detailed risk responses developed during the structure phase were updated. Thereafter the project WBS, detailed activity level statements of work and schedule were also updated.

Manage phase All the risks identified during the risk management plan compilation were monitored in a weekly progress meeting. Each risk was assigned a status of: In process, Completed or Pending. Where a risk was in process an indication was given of what the required action was in order to overcome the risk. Where a risk was completed a completion date was indicated. Pending only applied to risks that were not expected to affect the project in the next two weeks.

The lists of risks shown in Table 15 was used to manage the risks at the weekly project progress meetings. Risk 27 is shown as an example of a risk that was not originally identified but was added to the list as the project progressed.

Table 15: Example of list of risks.

WBS No Risk No Risks identified

2.1.1

1

Availability of SE

Status Actions

Resp person

In progress Monthly meetings with the center ML Barry

manager to ensure availability of SE

2.1.1.8, 2 2.1.1.9

2.1.1.8.1 3 2.1.1.8.1 4 2.1.1.8.1 5

2.1.1.8.1 6

2.1.1.8.1 7

2.1.1.8.2 8

2.1.1.8.2 9

2.1.1.8.2 10

2.1.1

27

Adverse Weather

In progress MLB to find the SA weather bureau ML Barry website and monitor

Compact PCI failure

Pending

W Nel

Antenna feed misalignment

Completed 26/09/2001

J Tait

Box too small to contain all Completed 15/11/2001

R Mabusela

equipment

Reflectors for the MMTU missing In progress WN to show RM where to mount W Nel

the missing reflectors

Cabling faulty

Pending

W Nel

Power supply failure

Completed 2001/05/10

R Mabusela

IDE hard-disk crash

Completed 2001/08/10

W Nel

MMTU no longer operational Pending

W Nel

Jitter on the DPG

Completed 19/10/2001 - this problem cannot be W Nel completely resoved unless the SFCU is redesigned to work from the same 80 MHz clock as the rest of the digital HW

EVALUATION OF THE RISK MANAGEMENT PROCESS

Overall evaluation The risk management process added a lot of value to the RoofSAR project. The main benefit was that the project team was aware of the risks which could then be managed.

Several of the risks originally identified materialised and due to the risk analysis did not negatively affect the success of the project. Some examples are as follows:

The IDE hard-disk was identified as a risk area as the possibility of a hard-disk crash was envisioned. Ghostwriter was thus purchased and a back-up disk made. In the end the hard-disk did not crash but the disk was stolen. As the back-up was available the damage to the project was limited to a morning instead of a week. It rained almost constantly during the first week that the experiments were supposed to take place. Due to the fact that adverse weather had been identified as a risk, the project manager constantly kept the client up to date on the status. This meant that although the timescales slipped, the client was aware and not displeased. The availability of the system engineer was a major risk. The system engineer is also involved on other projects as well. Due to the fact that it was identified as a risk, the project manager constantly kept the system engineering line manager up to date on the progress of the project, and the line manager ensured that the system engineer remained available.

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

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

Google Online Preview   Download