Risk is defined as:
- An uncertain event or condition that if it occurs, has a positive or negative effect on a Project’s Objectives (PMBOK).
- The effect of uncertainty on objectives (ISO 31000).
- The possibility that something bad or unpleasant will happen (Miriam-Webster)
Risk planning is the process of identifying, prioritizing, and managing risk.
Every project or initiative has objectives, that is, goals that it seeks to accomplish. These are often called Critical Success Factors (CSF).
Risk events threaten the successful completion of these critical success factors. Thus, risk planning involves identifying the most important risk events in advance, prioritizing them, and developing the appropriate risk response plans. There are three steps to risk planning:
- Identifying Risks
- Prioritizing Risks
- Determining Response Plans
Identifying Risks
A strong risk identification process is important to the successful completion of the critical success factors. This is particularly true for large or inherently risky projects, like nuclear power plants. But if it’s beneficial for large projects, an appropriately sized risk planning process will benefit small projects too. A Risk Management Plan is prepared which includes items such as:
- Risk Register
- Risk Breakdown Structure
- Risk Analysis
The risk register is the itemized listing of most important risks and it becomes the cornerstone of the Risk Management Plan. It requires careful consideration of the project risks and what could affect the project’s critical success factors. Here are a few ideas to ensure that each risk is identified:
- Use a Risk Breakdown Structure. Dividing risks into categories is intuitive and allows for better organization. Since many risks are unrelated to each other (the wrong chemical is delivered vs. the forklift operator quits), the systematic categorization of risks helps to ensure strong identification.
- Develop a checklist. Every business is different, and you are best suited to develop a checklist for yours. That being said, we have developed a generic one.
- Look at Assumptions. Every project operates under a set of assumptions. The business climate, client willingness, customer attitudes, etc. which, together, result in the creation of the project. What are the assumptions, and what happens if they change mid-project?
- Previous Project Experience. Many project based organizations have similar projects in their past history. What types of issues did they experience? On a related note, if there is no lessons learned database within the organization, maybe it’s time to start one.
- Expert judgment. Although I left this one for last, it can’t be understated. A subject matter expert will be able to identify most of the risks and know what to do about them.
Obviously, it is not possible to list all project risks. Although you should endeavor to identify the most important ones, you cannot predict everything and your stakeholders do not expect you to. Sometimes the project manager must react to unexpected events during the execution of a project – this cannot be eliminated. But I can assure you the stakeholders of your project will appreciate the time and effort given to the identification of risks.
On the other hand, you can go overboard and list too many risks. This is easy to do once you get going and start brainstorming about airplanes crashing into your office. I suggest that you should stick to risks that have a 5-10% (1 in 20-ish) chance of happening. If it’s lower than that, you might have too big of a list.
Prioritizing Risks
Identifying risks to a project’s success is a great first step that would benefit most projects that I’ve seen. But to create a strong risk management plan, those risks must be analyzed and prioritized to determine which require the project manager’s time and attention, how often, and what resources are required.
Stakeholders can be pretty sensitive to issues the project manager considers minor. Some stakeholders seem to demand excessive communication requirements. Prioritizing risks ensures that stakeholders recognize the importance placed on their areas of concern which goes a long ways toward placating them.
Since risk has two components:
Risk = Probability x Impact
Each of these factors should be prioritized. The scale is not important, but it is often 1-10, low-medium-high, or a similar scale.
If your risk register is a table with the risks listed vertically (in rows), you would add two columns labelled probability and impact. Each risk gets a ranking of 1-10, or whatever scale you choose.
After the initial ranking, an overall prioritization is often helpful to stakeholders. You would multiply the probability and impact to get a risk level, and then sort the table from highest to lowest. Clearly you will be able to see which risks to focus your attention on.
Even better, the risk register, together with its prioritizations, can be shared with stakeholders which will put each of their issues into perspective, keeping the stakeholders in line when problems arise.
After a risk event occurs, it becomes an issue. Issues require a response from the project manager or some other project member.
In order to quickly and decisively know when a risk becomes an issue, each risk should have an identifying risk trigger. This is an important part of risk analysis and it allows for effective monitoring to quickly recognize when a risk has occurred and take mitigative action.
Throughout the project, risks change in importance. Many will become obsolete at various stages of the project. Because of this, the risk register is an evolving document. It must be monitored and updated on a regular basis.
Identifying risk triggers allows you to make sure you are looking for the right factors which, if they occur at any regular monitoring/control point, allow you to change a risk’s status to an issue and take the appropriate action.
Taking early action is often one of the easiest way to mitigate an issue. Quick action by the project manager or a team member is one of the best remedies to mitigate the outfall of a risk event. It gives the affected stakeholder an impression of being on top of the issue and establishes the project manager as a strong leader.
An example risk register might look like this:
| Risk | Probability | Impact | Priority | Trigger | Response Plan |
|---|---|---|---|---|---|
| Miss completion date due to inclement weather | 3 | 6 | 18 | Site foreman to decide | See below |
| Deficient materials arrive at site | 1 | 8 | 8 | Site foreman inspects material upon arrival and decides | Send material back for full refund |
Determine Risk Response Plans
The final piece of information that completes the risk register is a risk response plan. Now that you’ve identified the triggers that allow you to quickly identify when a risk has occurred (or is occurring), the response plan gives you a head start in the response. Some responses occur at the beginning of the project (when the risk planning process is taking place) and others occur when the risk event occurs. Still other occur at any applicable time during the project.
They must contain an appropriate level of detail. For major risks a good action plan is necessary in advance and could warrant its own write up. For medium risks a small action plan could be placed within the risk register, and for small risks there could be no action plan at all. It isn’t a necessity for all risks, but it is important to have one for the most important ones.
There are four possible responses to risk events:
- Avoid. Eliminate the threat. For example, change the scope of the project, spin off a certain business unit, or change the objectives that the risk event is threatening.
- Transfer. Off-load the risk to a third party. For example, buy insurance, issue a performance bond, or change the contract from a lump sum to a unit price (or vice versa).
- Mitigate. Reduce the probability or impact of the risk event. For example, cover the project area to prevent work stoppages due to inclement weather, or purchase materials in advance to ensure they can be returned without threatening the project completion date.
- Accept. Sometimes there is no other alternative than to proceed with the project and accept the risk. But producing documentation, holding meetings, and communicating the risk with stakeholders can go a long ways toward minimizing the damage.
Risk is an Integral Part of Project Management
Risk is inherent in all projects because projects, by definition, improve or build on an operational process. As a minimum, there is the risk that the project does not accomplish its objectives. Since a project is a “capital” expenditure (as opposed to an ongoing “operational” one) risks are always present and need to be managed.
There is usually some sort of primary risk factor under which the project was defined, such as market risk for the development of a new product, or technical risk for an assembly line improvement project (will it speed up the line, etc?). After that, a host of secondary risks present themselves which, if ignored, can trip up a project.
The more risk planning you do, the safer your projects. For that reason risk management is joined at the hip to project management. Of course, a project manager’s time is valuable too, and since many have other technical duties to attend to, it is important to arrive at the correct amount of risk planning.
