Risk Identification
Risk Identification

As you meet with your subject matter experts and other stakeholders and go through the risk identification process, determine the characteristics of identified risks and categorize them by creating a Risk Breakdown Structure (RBS) which you will refer to throughout your risk management processes. Some categories may include but are not limited to Internal, External, Cultural, Unforeseeable, Suppliers, and Customers.
Discover and discuss conditions and situations that may lead to risks, analyze them and create strategies for eliminating, minimizing, and managing them. Interview and speak with people that have experience in similar projects. Review their documents and discuss lessons learned. Ignoring risks is not a strategy.
Document Reviews – In addition to the noted inputs, examine existing documents such as your scope statement, assumption log, constraints log, requirements documentation, historical records, and lessons learned from similar projects.
Brainstorming – Risks are typically identified by conducting brainstorming sessions, a popular and effective method for identifying project risks where your core team and subject matter experts discuss and document potential risks. For an effective brainstorming session, you need an impartial facilitator, scribe, and team members. The facilitator listens attentively, encourages team participation, keeps the team members focused, and the brainstorming session moving. The intent is to openly capture as many risks and ideas as possible without judgment or criticism. The more ideas captured, the better. Start your brainstorming session by creating a list of all possible risks.
The meeting scribe visually records the ideas using a shared screen, projector, flip chart, or dry marker board to minimize the submission of duplicate ideas and serves as a point of reference. Each idea is valuable. No idea is silly or bad. After listing your ideas and risks, categorize and prioritize them. Then, suggest solutions to address each risk.
Meetings & Interviews – Using past experience as a reference, conduct face-to-face, virtual or digital interviews to collect information to help determine risk probabilities and impacts.
Begin with high-level questions and continue more specifically through the interviewing process. This technique is known as funnel analysis. If a risk is determined, it is also wise to conduct a root cause analysis to look for proactive alternatives and ways to minimize the risk and develop a response plan should the risk occur.
Risk Management Plan and Register
After the initial process of risk identification, develop a risk management plan and register. Throughout the project lifecycle, monitor and update these documents as often as needed. They should include the following components:
- Roles and responsibilities of your team members and stakeholders who are responsible for monitoring, reporting, and responding to the risks if they come to pass.
- A defined and itemized budget for the risks.
- Risk triggers – signals or warning signs to alert the responsible person that the risk has or is about to occur and to take action.
For example, suppose you are responsible for creating and printing training materials and placing them in a customized binder. To ensure that you do not risk running out of paper or binders, you adhere to a “TIME TO PLACE ORDER” label on the box that will alert (trigger) you to place an order. This risk strategy is the “accept” risk handling method.
- Threshold is the amount of risk that is acceptable. For example, A risk of not more than a 10-day delay is acceptable.
- Tolerances are the various areas of risk that you are willing to take. For example, a risk that could affect the company’s 5-star reputation is unacceptable and be avoided at all costs.
Note: It’s ok to explore outside the specific requirements to understand the needs of the project and business objectives fully. Sometimes not considering things out of scope may ultimately minimize adverse risks or expose great opportunities.
Action Item! Post in our Facebook Group about a recent event that took a turn for the worse or best and explains how you would have handled things differently.
Table 7.1 illustrates possible risk factors that may arise throughout your project.
RISK FACTORS
Project Phase | Possible Factors |
---|---|
Initiation | Key information not recorded |
Initiation | Insufficient time for completing tasks, no historical data |
Initiation | Approval not received before proceeding to the next phase |
Planning | Inexperienced team members developing the plan |
Planning | Plans omitted information |
Planning | Plans not formally approved |
Execution | Requirements change |
Execution | Key team member leaves the company/reassigned |
Execution | Market demands change |
Execution | Downtime revenue lost |
Close | Approvers leave before the project is completed |

Figure 7.3 illustrates an example of a high-level RBS created by the team:
