PROJECT RISK MANAGEMENT: PART 2
This article is part of a series that discusses the ten (10) KNOWLEDGE AREAS of the PMBOK, with a practical approach and genuine business examples.
- Project Risk Management
- Project Risk Management: Part 1
- Project Risk Management: Part 2
- Project Schedule Management
- Project Scope Management
- Project Integration Management
- Project Cost Management
- Project Quality Management
- Project Resource Management
- Project Communications Management
- Project Procurement Management
- Project Stakeholder Management
This is Part 2 of Project Risk Management. Please see Part 1 to learn about previous sections
-
1. Plan risk management
2. Identify Risks
Project Risk Management: Part 2
3. Perform Qualitative Risk Analysis
4. Perform Quantitative Risk Analysis
5. Plan Risk Responses
6. Implement Risk Responses
7. Monitor Risks
8. Closing Tip: Raid Log
3. PERFORM QUALITATIVE RISK ANALYSIS
I can testify that planning and identifying risks was the difficult part: How do you feel?! The rest is a little bit easier; analyses tend to be straight forward. Once you have identified a risk, enter it in your risk register. Now it is time to understand how it may impact your project, and what is the probability of it happening. You can use historical performance, expert judgement, and I would agree that team consensus is valuable input at this stage, too. Your risk register should have a risk score matrix to supply the "Impact x Frequency" score.
 |
| Figure 1. Risk Score Matrix Example |
 |
|
Figure 2. Risk Scores Example
|
As you can see, a risk that has multiple severe or catastrophic adverse effects associated to it, but that is very unlikely to happen, has a Very Low - MINOR risk score, thus why we might not want to waste many resources to do anything about it. Conversely (and very interestingly too), a negligible adverse effect event but that is almost certain to happen, has a moderate - SERIOUS risk score! Which might bring our attention to mitigate it in a project. As an example, I can think about the risk of outsourcing office supplies in a remote project. You may depend on the reliability of the local print shop once or twice, but if you need to print daily, and the project lasts 3 months, you might want to mitigate your risks by buying a plotter for that remote job!
4. PERFORM QUANTITATIVE RISK ANALYSIS
After going through the exercise of obtaining risk scores and, if it was determined as part of the project risk planning, now it is time to understand how much these high priority risks will affect your project. Risks should be reported as potential cost or "dollar value." Another way of reporting risk is as time, for example "700 man-hours" but ultimately cost is a function of time.
Understanding the dollar value associated to risks will help a project manager assign a contingency for the project: Contingency is a dollar amount prepared to ensure the company is prepared for worst-case scenarios.
Risk quantification methods rely on choosing a correct probability distribution to reflect the way in which the value of a variable is expected to behave (Meyer, 2015). The best way to approach quantitative analysis is with a software tool: the reason is simple, to obtain meaningful results, a MONTECARLO simulation for both schedule and cost should be performed: A MONTECARLO simulation is a simulation done repeatedly (thousands of times) with the range from the probability distribution provided. The outcome of a MONTECARLO simulation will show not only what can happen, but how likely each outcome is.
A typical schedule and cost report after performing quantitative analysis reads like the following (taken from interpreting data from simulation I ran for a demo project):
- "The schedule report shows that it is 80% certain that the project completion date will be March 27th, 2022. The proposed completion date of the project has 35% of chance to be achieved. The latest completion date with risk management is 28th August 2022. The schedule sensitivity index report shows that concrete work and site earthwork are the activities that most affect the project."
- "The cost analysis report shows that it is 80% certain that the project cost will be $143,243,740. The maximum cost is $152,691,006. The cost sensitivity report shows that implementation phase, construction phase and filed execution are the activities that most affects the project."
 |
|
Figure 3. Quantitative risk register example, Primavera Risk Analysis software tool (Demo project)
|
 |
|
Figure 4. Risk examples with assigned probability, Primavera Risk Analysis software tool (Demo project)
|
5. PLAN RISK RESPONSES
We identified, assessed, and prioritized our risks... but when do we stop worrying about them? Well, now it is time to devise strategies: We can mitigate, accept, avoid or transfers risks. Whatever strategy we choose, the associated actions are called risk response or Controls.
 |
|
Figure 5. Risk register entry example
|
We should always have two (2) risk scores. One before controls and another after controls. The risk score after controls will reflect how effective we estimate our strategy will be. The accuracy of this estimation will depend on the same factors: if we have the experience, the historical data or expert judgement to support it.
Our risk score matrix can be updated to reflect a new score based on the effectiveness of the control strategy.
 |
|
Figure 6. Risk Score Matrix with Controls.
|
6. IMPLEMENT RISK RESPONSES
Remember, the plan is to avoid actual issues from arising in our project. When do we start implementing our strategies? This is a challenge. After the planning phase, the specific activities from the strategy plan should be made part of the schedule; this means that your project schedule should be updated to show the tasks and activities required to initiate your risk management plan.
As you can see in the risk register entry, every risk should have a risk owner, a person or team dedicated to following the risk management plan, the schedule, and understanding the different triggers that signal a potential risk before they appear.
7. MONITOR RISKS
This phase is as important as identifying the risks: what benefit did all the previous work bring if we let potential risks become significant issues?
Having a strong management foundation helps in this phase. There are many risks that may be linked to other related issues appearing in a project: again, signaling the need for traceability. An issue log and issue management are especially important in project management.
The project manager and project team will be wise to check the risk register continuously, updating with new risks and verifying the validity and progress of previous risk strategies. A risk audit can be exercised to understand how well project team members have followed the risk management plan. Audits are typically done by members outside the project team.
Changes to the risk management plan are not exempt of following change control procedures. Any new identified risks that require preventive or corrective actions will need to go through the change control board, and all associated stakeholders should be informed according to the communications plan (so many different moving parts!).
8. CLOSING TIP: RAID LOG
Risk management is a lot to digest, especially if it's new to you or if you plan to begin implementing it in your organization, but it is never too late to start. The benefits are immense, plus you will look like a wizard by being prepared against harmful events, more so if your company or department has been experiencing recurring issues or has not been good at assigning accurate contingencies in previous projects.
There is an extremely helpful artifact that will make your life easier: a RAID log. Think of the RAID log like a Risk Register on steroids. It holds the risk register, but it also has a space so that the project team can manage other important related aspects of a project. RAID stands for Risks, Assumptions, Issues, and Dependencies (some organizations may prefer to have the "D" section to stand for Decisions).
A further explanation on the sections of the RAID log is shown next. A fire alarm system installation is used to illustrate some entry examples for each section.
- Risks: this is where you should have your risk register. Figure 3 shows a good example.
- Assumptions: Anything that is not part of your requirements matrix but that you need to assume to progress. It is always important not to leave any questions unanswered but sometimes a project manager needs to make assumptions, depending on the case.
 |
|
Figure 7. Assumption entry example in RAID log.
|
- Issues: You can use this section as the Issue log of your project.
 |
| Figure 8. Issue entry example in RAID log |
- Dependencies: Important milestones that cannot be finished until specific tasks are done. Understanding these type of relationships is important to be understood by the project manager and should be reflected as such in the schedule.
 |
|
Figure 9. Dependency entry example in Raid log
|
References
Becker, G. (2004). A practical risk management approach. Retrieved from PMI: https://www.pmi.org/learning/library/practical-risk-management-approach-8248
Fuentes-Bargues, J., Gonzalez Cruz, M., Gonzalez Gaya, C., & Baixauli Perez, M. (2017). PMC. Retrieved from NCBI: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5551143/
Meyer. (2015). Quantifying Risk. Retrieved from PMI: https://www.pmi.org/learning/library/quantitative-risk-assessment-methods-9929
Blogs you might also like