Risk management is one of the ten project management knowledge areas in the Project Management Body of Knowledge. In PMBOK theory, there are six main process groups within Risk Management. Five of those occur in the planning stage of a project. Thus, Risk Planning includes the following tasks:
- Identifying Risks
- Prioritizing Risks
- Determine Triggers
- Determine Action Plans
Identifying Risks
To provide a solid risk management plan upon which the project can depend, it is imperative that the most important project risks be identified and listed. This is particularly true for inherently risky projects, like nuclear power plants, but all projects will benefit. If they do it for nuclear power plants, wouldn’t it be beneficial to your small project to learn how it’s done?
The risks are listed in a risk register, which 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 if they change?
- 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.
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, probability and impact, each one 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.
Determine Triggers
After a risk 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. I’ve seen many project issues which were probably much worse than they appeared to be, but quick action by the project manager or a team member gave the affected stakeholder an impression of being on top of the issue, which smoothed it over. This is a recurring theme for me in my project management career, and thus I would consider it one of the biggest single factors for project success.
Determine Action Plans
The final piece of information that completes the risk register is an action plan. Now that you’ve identified the triggers that allow you to quickly identify when a risk has occurred (or is occurring), the action plan is the response. It is a previously thought out response plan to ensure you’re not flying off the seat of your pants when a risk occurs.
Notice that I said it must be 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.
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. Since a project is a “capital” expenditure compared to ongoing “operational” expenditure risks are natural 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 management you do, the safer your projects. 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 management.
