RISK MANAGEMENT FOR DUMMIES – A CASE STUDY
Marie-Louise Barry
Project Manager Radar, CSIR, Defencetek, P O Box 392, Pretoria, 0001, [email protected]
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 Sydney
Opera House
Vienna General hospital
Original plan
Original budget: $ 6 million
Mossgas
Original budget: $ 317 million
Scheduled completion: 1968
Original budget: R 3 Billion
Trans Alaska Pipeline system
Original budget: $ 900 million
Spacecraft challenger
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): www.pmisa.org.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.
2.1
2.1
RoofSAR2001
2001
RoofSAR
2.1.1
2.1.1
Finalintegration
integration
Final
2.1.1.1
Roof integration
2.1.2
2.1.2
Performanceanalysis
analysis
Performance
2.1.3
2.1.3
Calibration
Calibration
2.1.4
2.1.4
Experiments
Experiments
2.1.2.1
Generate images
2.1.3.1
Arrange targets
2.1.4.1
Generate images
2.1.2.2
Analyze images
2.1.3.2
Perform experiments
2.1.4.2
Analyze images
2.1.2.3
Generate report
2.1.3.3
Data analysis
2.1.4.3
Generate report
2.1.3.4
Generate report
2.1.4.4
Generate report
Mechanical
System test
Generate image
Client demo
2.1.1.2
Characterization
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].
Define
Define
Focus
Focus
Identify
Identify
Structure
Structure
Ownership
Ownership
Estimate
Estimate
Evaluate
Evaluate
Plan
Plan
Manage
Manage
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
Risk No
1
Risks identified
Availability of
Engineer
2.1.1.8.2
13
SCSI disk crash
2.1.1.8.3
15
Resolution > 1 metre and
side-lobes not in the order
of 30dB.
System
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.
Equipment:
Equipment:
13.SCSI
SCSIdisk
diskcrash
crash
13.
nd Mast
19.
Transport
2
nd
19. Transport 2 Mast
nd Mast
20.
Compressor
20. Compressor 22nd Mast
Scheduleand
andBudget:
Budget:
Schedule
23.
Time
for
experiments
23. Time for experiments
longer
longer
24.
Timetotoanswer
answerlonger
longer
24. Time
26.Time
Timeand
andbudget
budget
26.
limitationsfor
forthis
thisyear
year
limitations
Customersatisfaction
satisfaction
Customer
Resources:
Resources:
Availabilityofof SE
SE
1.1.Availability
Technical:
Technical:
15.
Resolution
15. Resolution
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
MH MS
CH
CS
D
**Composite likelihood factor (CLF)
2.1.1.8 Integration on the Roof
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
MS
Existing
CH
Simple design
CS
Simple design
D
Independent
Minor redesign
Minor redesign
Minor
complexity
Minor complexity
0,5
(moderate)
Major
feasible
Major
feasible
change
Moderate
complexity
Moderate
complexity
0,7
(significant)
Complex
design
technology exists
New, but similar to
existing software
Significant
complexity
Significant
complexity
0,9
(high)
State of the art;
some research done
State of the art;
never done
Extreme
complexity
Extreme
complexity
Schedule
dependent
on
existing system
Performance
dependent
on
existing system
Schedule
dependent
on
new system
Performance
dependant
on
new system
change
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
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
2.1.1.9 System Characterisation
2.1.3
System performance analysis
2.1.4
System Calibration
2.1.5
Target Imaging Experiments
**CIF = W1*TI + W2*CI+W3*SI
0.9
0.9
0.7
0.9
0.7
0.1
0.1
0.9
0.9
0.1
0.1
0.1
0.9
0.9
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
Risks identified
Likelihd Impact
Availability of Willie Nel
0.8
0.8
Adverse Weather
0.3
0.5
Compact PCI failure
0.4
1.0
Antenna feed misalignment
0.6
0.3
Box too small to contain all 0.8
0.2
equipment
Reflectors for the MMTU missing
0.9
0.2
Cabling faulty
0.2
0.2
Power supply failure
0.1
1.0
IDE hard-disk crash
0.1
0.9
MMTU no longer operational
0.1
0.3
Jan Tait
Likelihd
0.5
0.5
0.1
0.25
0.25
0.1
0.1
0.1
Impact
0.9
0.5
0.9
0.1
0.5
0.3
0.9
0.8
ML Barry
Likelihd Impact
0.9
0.9
0.6
0.7
0.4
0.9
0.4
0.2
0.8
0.1
Average
Likelihd
0.73
0.47
0.30
0.42
0.62
Impact
0.87
0.57
0.93
0.20
0.27
0.6
0.3
0.3
0.3
0.4
0.75
0.20
0.17
0.17
0.25
0.15
0.27
0.93
0.83
0.35
0.1
0.3
0.9
0.8
0.4
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
2.1.1.8
2.1.1.9
2.1.3
2.1.4
2.1.5
Description
Integration on the Roof
System Characterisation
System performance analysis
System Calibration
Target Imaging Experiments
CLF
0.66
0.7
0.86
0.86
0.82
CIF
0.37
0.37
0.83
0.90
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
Availability of Willie Nel
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
Average
Likelihood
0.73
0.47
0.30
0.42
0.62
0.75
0.20
0.17
0.17
0.25
Impact
Risk
0.87
0.57
0.93
0.20
0.27
0.15
0.27
0.93
0.83
0.35
0.64
0.26
0.28
0.08
0.16
0.11
0.05
0.16
0.14
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
2.1.1
Risk No Risks identified
1
Availability of SE
2.1.1.8,
2.1.1.9
2.1.1.8.1
2.1.1.8.1
2.1.1.8.1
2
2.1.1.8.1
6
2.1.1.8.1
2.1.1.8.2
2.1.1.8.2
2.1.1.8.2
2.1.1
7
8
9
10
27
Status
Actions
Resp person
In progress Monthly meetings with the center ML Barry
manager to ensure availability of SE
Adverse Weather
3
4
5
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.
Evaluation of value added by each step of the Risk Management process followed
An evaluation of the risk management process followed is given in Table 16.
Table 16: Value added by each step of Risk management process.
Risk management phase
Define phase
Focus phase
Identify phase
Structure phase
Ownership phase
Estimate phase
Evaluate phase
Plan phase
Manage phase
Value added
The define phase did not add much value to this specific project as the information
required for this phase was mostly in existence. This phase is very important if the
information has not been previously generated.
The focus phase was very important as this determined what process would be followed.
In future this process will be more tailored as described below.
The risk identification phase was one of the phases that added the most value to the
project. The reason for this is that it helped the project team better understand the risks
inherent in the project.
The structure phase was important in that a perception of what the magnitute of each risk
is. The responses developed also helped the project team to draw up a plan of action.
The ownership phase was very important because each member of the project team took
ownership of the risks allocated. This made the management of the risks easier.
The matrix drawn on the board during the structure phase added a lot more value than the
detailed estimations for each task. The impact and likelihood of each task is very
subjective. It is more important to have a perception for what the risk is. The task level
estimates completed were never used during risk management.
The same comment as for the estimate phase applies.
Some valuable adjustments were made to the original project plan.
The manage phase added a lot of value to the project. Not only did it ensure that the risks
identified were managed, but new risks were added to the list of risks during this phase.
RISK MANAGEMENT FOR DUMMIES
Before the project risks can be defined the following minimum elements of project planning need to
be in place:
Work breakdown structure. The work must be broken down to a level that will facilitate
control.
Project schedule. The schedule must contain task durations, task dependencies and
resources allocated.
Project budget. The budget must contain the human resources as well as material costs.
Methods for determining the above are beyond the scope of this paper.
Once the basic project planning is in place, convene a risk-planning meeting with the project team
and/or the relevant line managers. Before the meeting, the above planning must be distributed to all
the attendees especially if they were not involved in the original planning sessions.
At the meeting risks are then identified per WBS item. Project risks are those events that, should
they happen, cause the project to be late, overrun the budget, make it impossible to meet technical
performance requirements or cause the client to be displeased at the conclusion of the project.
As the risk is identified, write it down with the WBS item it refers to on a post-it and stick it on the
wall for all to see. Continue identifying risks until all WBS items have been addressed.
The project manager then draws the matrix shown in Table 17 on the board or on a large piece of
paper. Each risk is then discussed and the post-it with the risk written on placed on the matrix. A
risk has high impact if the consequences of the risk materializing are very serious. A risk has high
probability if the chances of the risk materializing are high.
For large projects or when many risks have been identified it may be necessary to repeat the process
a few times as all the post-it notes might not fit on one matrix.
The severity of each risk can then be identified to be high, medium or low risk as shown in
Table 18. This matrix is adapted from [2] in that risks with a high impact but low probability are
considered high risk. It is felt that if a risk has a high impact it must be closely monitored and thus
it becomes a high risk.
Table 17: Risk allocation matrix.
Impact
High
Medium
Low
Low
Medium
High
Probability
Impact
Table 18: Risk severity determination.
High
High
risk
High
risk
High
risk
Medium
Low
risk
Medium
risk
High
risk
Low
risk
Low
risk
Medium
risk
Low
Low
Medium
High
Probability
The attendees of the meeting must then decide which risks will be explored further and monitored.
These will depend on the risk profile of the team, the size of the project, the number of risks
identified as well as company policy. It is the opinion of the author that it is dangerous to
completely ignore low risks, because if they materialise, they could negatively impact on the
project.
The next step is then to decide how each risk will be handled. According to [2] the following
generic risk responses exist:
Modify objectives.
Avoid.
Prevent.
Mitigate.
Develop contingency plans.
Keep options open.
Monitor.
Accept.
Remain unaware.
For each risk identified that will be explored further and monitored, write a short description of the
action to be taken regarding the risk on a smaller post-it and stick it to the risk.
The last step in the risk planning process is to identify who is to be responsible to ensure that the
action identified for a risk takes place. The initials of the responsible person can be written on each
post-it or alternatively stickers can be used where each team member has a different colour sticker,
which is then stuck on the post-it.
After the risk-planning meeting, the project manager can then compile a list of risks that can be
used to monitor the risks throughout the execution of the project at the regular project meetings.
The data can be captured in a table/spreadsheet format with headings as shown in Table 19.
Table 19: Format for list of risks.
WBS No
Risk No
Description of risk
Action identified for risk response
Responsible person
Two additional columns can be added to the table/spreadsheet that can be updated during regular
project progress meetings, viz
Status of risk.
Comments.
Once the list of risks has been drawn up, the original project plan must be updated. Actions to be
taken must be added to the plan.
During regular project meetings the above list of risks is then discussed and updated. Any new
risks identified must be added to the list. Risk management remains an iterative process and is not
completed during the intial phase of drawing up the list.
REFERENCES
1.
2.
3.
4.
MPM class notes, Examples of project failures, Prof M Köster, UP.
Chapman et al. Project Risk Management. John Wiley and Sons. 1997.
Nicholas, JM. Project Management for Business and Technology. Prentice Hall. 2001. 2nd
edition.
PM Network, August 2001, page 18.
Marie-Louise Barry
Marie-Louise Barry is an electronic engineer by training and has been working in the field of
project management for the past seven years in the military environment. She has been working in
a KITO environment for the past 3 years in the radar centre of Excellence at CSIR Defencetek. She
obtained her PMP certification in 2001 and is currently studying towards a Masters degree in
Project Management at the University of Pretoria in South Africa. She is currently active the IEEE
engineering management chapter as public relations officer.