PROJECT RISK MANAGEMENT: PART 1
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
Risk management is the closest thing to having magic powers in project management; you are looking into the future. When accounting for risk, you are planning for uncertainty. Will you be able to identify all potential hazards of your project? Will you be prepared to act if any of these scenarios were to happen? How much will it cost you to control risks? Or worse yet, how much will it cost you if you don't?
 | |
Figure 1. "Sword of Omens, give me sight beyond sight!"
Note: Risk in this context has a negative connotation; but risks with positive impact are opportunities. The approach to identifying and assessing risks and opportunities is similar. This article will focus on risks as threats.
Project Risk Management: Part 1
1. PLAN RISK MANAGEMENT
Every project is unique: each project differs in people and scope. What is the risk tolerance of the stakeholders? What is the general risk attitude of your organization? When you think about it, if risk management means being prepared against harmful events, can we really afford not planning for it?
It is hard to answer "yes, forget about risk management" to this last question. But, if the team is inexperienced and without the proper processes in place, they can end up wasting unaccounted resources chasing irrelevant risks or developing mitigation strategies that will never be used. Project team members need to understand the basics.
The planning phase is where the team decides:
a. If the project is going to account for risk. Many risks are internal to the organization and are controllable by rules. These risks are usually prevented by following company policies or processes. For example, if we do not use a Requirements Scope Matrix, then we might miss important scope in new projects. These types of preventable risks are identified and managed with a best practice approach and should not be the focus of risk planning in every new project.
b. Which are the key parameters of the project. Just to name a few:
- SCHEDULE. Better understood in projects where the client has a non-negotiable deadline. i.e., a school renovation that must happen during the summer, when students are on vacation.
- COST. Some projects work under a GMC Guaranteed Maximum Cost contract, where the project is established not to exceed a specific value as any surplus will not be paid.
- QUALITY. The client is expecting strict performance parameters from the product, or they will not accept it.
c. How risk will be assessed.
- IMPACT. We can measure risk by the harm it may cause if the issue arises in a project. It is a project manager's choice to determine the different levels of impact or consequence of risks in a project: are low, medium, and high impact levels enough? Establishing values for the key parameters helps all project team members be on the same page. If needed, you can add levels (like very low, and very high).
- LIKELIHOOD. Risk is always linked to frequency or probability. It should follow the same levels chosen for impact (i.e., very low, low, medium, high, and very high likelihood). The project team will set some thresholds (for example, is a 50% chance of an event happening considered medium? This will depend on a specific industry and risk attitude of the company).
- PRIORITY. This is also known as Risk Score. A risk with a high impact and high likelihood will rank higher in score or priority than a risk with high impact but low likelihood.
- CONTROLS. These are the strategies devised by the team members to approach risks. The most commons strategies are: (Becker, 2004)
- MITIGATE. This is where the team develops a plan to lessen the impact and/or likelihood of risks.
- Risk Example #1: Product design complies with client requirements, but it is not feasible to assemble.
- Mitigate Strategy Example: Establish an agile approach (small increments). The design team should present design updates to assembly team to give feedback periodically.
- ACCEPT. Usually when any mitigation strategy is too costly or more complex than the issue itself.
- Risk Example #2: The client is making a payment from an international European bank to your U.S company bank account later than the submitted proposal; the exchange rate might affect the project value negatively.
- Accept Strategy Example: No action. Unless there is unforeseen political turmoil or natural disaster, the euro / dollar exchange rate is usually stable in lower time frames.
- AVOID. This strategy is used to circumvent the problem completely.
- Risk Example #3: In a construction project, freezing temperatures will affect concrete as it sets, finishing drywall, and hydrostatic tests to the sprinkler system.
- Avoid Strategy Example: Preclude all winter construction work.
- TRANSFER. Usually with a contract, the organization transfers risk to another party. This is very easily understood with the concept of insurance.
- Risk Example #4: A building official will inspect the construction project that your company is managing for all penetrations of fire rated assemblies (fire rated walls and floors affected by conduit, pipes and ducts running though them). An inspection will fail if penetrations are not treated with appropriate firestop system and may delay the project delivery.
- Transfer Strategy Example: Your company will subcontract the firestopping activities to a specialized firestop company. The contract will include an indemnification clause.
- QUALITATIVE or QUANTITATIVE risk analysis. Why not both? Most projects' risk approach ends after a qualitative analysis (identifying, assessing, and prioritizing risk). Although people tend to think of qualitative as "subjective," the qualitative approach may be based on specific values (i.e., "50% likelihood"). But the quantitative approach is the natural evolution of having performed qualitative analysis. Once you have determined a high score risk, you may want to further understand how it will affect your project key parameters or objectives. Using simulation tools, a quantitative analysis will give you information about the dollar or time value a specific event -realized risk- will cost the project.
d. Which tools will be used. The most common tool is a Risk Register. This template comes in very handy specially for qualitative analysis. If quantitative analysis is required, software, like PERMASTER or ACUMEN, will need to be determined here. In Part 2, I recommend the use of a RAID log.
2. IDENTIFY RISKS
Believe it or not, the planning phase was the easy one! This is where most project managers fail: identifying risks. Probably because they have not finished their magician's course! How else are they supposed to look into the future and produce a list of events that the team should focus on for the remainder of the project?
As a fire protection engineer, I have been trained to approach harmful events as hazards. A hazard is still not a risk. It needs another key factor: frequency. This approach can help you too.
- Think about a diesel fuel tank that feeds an electrical generator.
- The hazard: a tank explosion. Extremely high impact, catastrophic adverse effects.
- The frequency: Very low frequency (Fuentes-Bargues, Gonzalez Cruz, Gonzalez Gaya, & Baixauli Perez, 2017).
- The risk: "Impact x Frequency" = Risk. Most risk score matrices will help you understand that if a catastrophic event is very unlikely to happen, then it is an incredibly low score risk. That is also the main reason we still fly in airplanes!
Other than having magical powers, project managers have two main sources to help them understand how to identify risks for their projects:
a. HISTORICAL PERFORMANCE: This is information taken from available data. It could be from your organization or provided by the industry.
- For example, if your company lived through a similar previous successful project, then it must have faced issues that were resolved. Issues from previous similar projects are automatic risks for the next. Hence why it is so important to keep an issue log and lessons learned meetings.
- By reading a published article, you understand the damage and probability of diesel tanks explosions, and you use this data in your risk analysis.
b. EXPERT JUDGEMENT: Your company may have not dealt with a specific type of project, or you may not have industry data, but an expert can put "2 and 2 together" and will give you valuable input about potential risks. For example, the expert will be the first to provide comments about a product being feasible or not, by analyzing your processes and your team members. Always a clever idea to invite experts when identifying risks.
c. Final notes on identifying risks:
- Think of risks as issues that have not happened, yet. Anything that may affect your cost, schedule, scope, quality, and even reputation (for example, fail to satisfy a customer and, if you are fortunate, your cost might not be affected, but good luck getting new business from them!)
- Risk Breakdown Structure (RBS): Another way to identify risks is to study the Work Breakdown Structure (WBS) of your project and create an RBS. If the project manager or team members understand all tasks and deliverables from each work bucket of the project, they can think about challenges that will stop them from bringing the activities to completion.
Register in our PMP Training Certification Course today and develop a strong foundation in the project risk management.
Phew! That was a lot to start, but these first two sections are the foundation of Project Risk Management. Please see part 2 to continue learning about:
3. Qualitative Analysis
4. Quantitative Analysis
5. Plan Risk Responses
6. Implement Risk Responses
7. Monitor Risks
8. Closing tip: 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