The risk management framework begins by trying to generate a list of all the possible risks that could affect the project. Typically the project manager pulls together, during the planning phase, a risk management team consisting of core team members and other relevant stakeholders.
- The team uses brainstorming and other problem identifying techniques to identify potential problems.
- Participants are encouraged to keep an open mind and generate as many probable risks as possible. More than one project has been bushwhacked by an event that members thought was preposterous in the beginning.
- Later during the assessment phase, participants will have a chance to analyze and filter out unreasonable risks.
One common mistake that is made early in the risk identification process is to focus on objectives and not on the events that could produce consequences.
For example, team members may identify failing to meet schedule as a major risk. What they need to focus on are the events that could cause this to happen (i.e., poor estimates, adverse weather, shipping delays, etc.).
Only by focusing on actual events can potential solutions be found.
Risk Identification Tools
Organizations use risk breakdown structures (RBSs) in conjunction with work breakdown structures (WBSs) to help management teams identify and eventually analyze risks. The figure below provides a generic example of an RBS.
[fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”]
- The focus at the beginning should be on risks that can affect the whole project as opposed to a specific section of the project or network.
- After the macro risks have been identified, specific areas can be checked. An effective tool for identifying specific risks is the work breakdown structure. Use of the RBS reduces the chance a risk event will be missed. On large projects multiple risk teams are organized around specific deliverables and submit their risk management reports to the project manager. A risk profile is another useful tool. A risk profile is a list of questions that address traditional areas of uncertainty on a project. These questions have been developed and refined from previous, similar projects. The figure below provides a partial example of a risk profile. Good risk profiles, like RBSs, are tailored to the type of project in question.
[/fusion_builder_column][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”]
For example, building an information system is different from building a new car. They are organization specific.
Risk profiles recognize the unique strengths and weaknesses of the firm. Finally, risk profiles address both technical and management risks.
For example, the profile shown in the above figure asks questions about design (Does the design depend upon unrealistic assumptions?) and work environment (Do people cooperate across functional boundaries?).
Risk profiles are generated and maintained usually by personnel from the project office. They are updated and refined during the post project audit. These profiles, when kept up to date, can be a powerful resource in the risk management process. The collective experience of the firm’s past projects resides in their questions.
Historical records complement or be used when formal risk profiles are not available. Project teams can investigate what happened on similar projects in the past to identify potential risks.
For example, a project manager can check the on time performance of selected vendors to gauge the threat of shipping delays. IT project managers can access “best practices” papers detailing other companies’ experiences converting software systems. Inquiries should not be limited to recorded data.
Sawy project managers tap the wisdom of others by seeking the advice of veteran project managers.
Risk Identification Limits
The risk identification process should not be limited to just the core team. Input from customers, sponsors, subcontractors, vendors, and other stakeholders should be solicited.
Relevant stakeholders can be formally interviewed or included on the risk management team. Not only do these players have a valuable perspective, but by involving them in the risk management process they also become more committed to project success.
One of the keys to success in risk identification is attitude. While a “can do” attitude is essential during implementation, project managers have to encourage critical thinking when it comes to risk identification. The goal is to find potential problems before they happen.
The RBS and risk profiles are useful tools for making sure no stones are left unturned. At the same time, when done well the number of risks identified be overwhelming and a bit discouraging. Initial optimism can be replaced with griping and cries of “what have we gotten ourselves into?”
It is important that project managers set the right tone and complete the risk management process so members regain confidence in themselves and the project.