Risk Management for Dummies – A Case Study

1 Paper presented at African Rhythm Project Management Conference 22 24 April 2002, Johannesburg, South Africa Hosted by: Project Management Institute of South Africa (PMISA): ISBN Number: 0-620-28853-1 RISK Management FOR Dummies A CASE Study Marie-Louise Barry Project Manager Radar, CSIR, Defencetek, P O Box 392, Pretoria, 0001, 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.

2 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 Original plan Final result Construction of the Sydney Opera House Original budget: $ 6 million Final cost: $ 100 million which is 16 times the bid price Vienna General hospital Original budget: $ 317 million Final cost: $ 4 Billion Scheduled completion: 1968 Final completion: 1986 16 years late Mossgas Original budget: R 3 Billion Final cost: R14 Billion which is 4,67 X the original estimate. Trans Alaska Pipeline system Original budget: $ 900 million Final cost: $ 8 billion +; $1,5 billion of which was lost in fraud and mismanagement. Spacecraft challenger Successful trip to the moon with civilian on board Explosion 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 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).

3 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. 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.

4 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: 8 Final integration. 8 System performance analysis. 8 System calibration. 8 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. 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. reportMechanicalSystem testGenerate imageClient reportMechanicalSystem testGenerate imageClient reportMechanicalSystem testGenerate imageClient reportMechanicalSystem testGenerate imageClient demoTable 3: Risk Management process followed [2].

5 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.

6 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 Risk No risks identified 1 Availability of System Engineer , , 2 Adverse Weather 3 Compact PCI failure 4 Antenna feed misalignment 5 Box too small to contain all equipment 6 Reflectors for the MMTU missing 7 Cabling faulty 8 Power supply failure 9 IDE hard-disk crash 10 MMTU no longer operational DefineDefineFocusFocusIdentifyIdentifySt ructureStructureOwnershipOwnershipEstima teEstimateEvaluateEvaluatePlanPlanManage ManageDefineDefineFocusFocusIdentifyIden tifyStructureStructureOwnershipOwnership EstimateEstimateEvaluateEvaluatePlanPlan ManageManageFor each identified risk a risk response was decided upon, written on another Post-it and attached to the risk identified.

7 Examples of the risk responses developed are shown in Table 5. Table 5: Risk responses. WBS No Risk No risks identified Detailed risk response 1 Availability of System Engineer 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. 13 SCSI disk crash Check on the availability of SCSI drives. Purchase a spare SCSI drive if cost effective. 15 Resolution > 1 metre and side-lobes not in the order of 30dB. 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.

8 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. 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.

9 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. Equipment:13. SCSI disk crash19. Transport 2ndMast20. Compressor 2ndMastEquipment:13. SCSI disk crash19. Transport 2ndMast20. Compressor 2ndMastResources:1. Availability of SEResources:1. Availability of SETechnical:15. ResolutionTechnical:15. ResolutionSchedule and Budget:23. Time for experiments longer24. Time to answer longer26. Time and budget limitations for this yearSchedule and Budget:23. Time for experiments longer24. Time to answer longer26. Time and budget limitations for this yearCustomer satisfactionCustomer satisfactionEquipment:13.

10 SCSI disk crash19. Transport 2ndMast20. Compressor 2ndMastEquipment:13. SCSI disk crash19. Transport 2ndMast20. Compressor 2ndMastResources:1. Availability of SEResources:1. Availability of SETechnical:15. ResolutionTechnical:15. ResolutionSchedule and Budget:23. Time for experiments longer24. Time to answer longer26. Time and budget limitations for this yearSchedule and Budget:23. Time for experiments longer24. Time to answer longer26. Time and budget limitations for this yearCustomer satisfactionCustomer satisfactionEstimate 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 MH MS CH CS D **Composite likelihood factor (CLF) Integration on the Roof System Characterisation System performance analysis System Calibration Target Imaging Experiments ** CLF = W1*MH + W2*MS + W3*CH + W4*CS + W5*D where W1+W2+W3+W4+W5 = 1 and W1=W2=W3=W4=W5= Table 8: Likelihood of risk determination table [3].