Chapter 10. Project Risks
10.3 Identifying Risks
10.3.1 Inputs and Tools to Identify Risks
The project team should identify negative risks (threats) and positive risks (opportunities) first in order to respond appropriately to them when they occur. During the planning stage, the team documents the individual and overall project risks. Risk identification is not a one-time event that happens during the planning. Monitoring of the risks continues throughout the project to identify new risks and modify the existing ones if necessary. When the project manager and the team discuss the risks that may affect the project activities, decisions, or outcomes, they use the components of the project management (e.g., requirements management plan, schedule management, and scope baseline), project documents such as assumption log, cost estimates, issue log, stakeholder register, and lesson learned register, agreements for the external procurement of resources, procurement documentation, enterprise environmental factors, and organizational process assets[1].
The project manager implements several tools and techniques to identify risks.
- Experts can provide their specialized knowledge of similar projects or business areas.
- The project team can brainstorm within the team and with the experts to discuss and refine the risks. The team’s past experience, project experience within the company, and industry experts can be valuable resources for identifying potential risks on a project. The team can also conduct specialized meetings, such as risk workshops.
- Some companies and industries develop risk checklists based on experience from past projects. These checklists can help identify both specific risks on the checklist and expand the team’s thinking.
- The project manager and the team members can interview experienced project participants, stakeholders, and subject matter experts.
- Data analysis techniques such as root cause analysis, assumption and constraint analysis, SWOT analysis, and document analysis can be used.
- The project manager can act as a facilitator or assign a skilled facilitator to help participants remain focused on the risk identification task, ensure clear descriptions, identify and overcome sources of bias, and resolve any possible disagreements.
- The risk breakdown structure can help the team as a guideline framework. Besides, some common strategic frameworks such as PESTLE (political, economic, social, technological, legal, environmental), TECOP (technical, environmental, commercial, operational, political), or VUCA (volatility, uncertainty, complexity, ambiguity) can be utilized.
10.3.2 Risk Register
When risks are identified, they are recorded in a risk register. It is a key tool that helps project teams keep track of the status of risks and ensure response plans are effectively implemented, and new risks are managed. The register is an output of the process of identifying project risks. The project charter can involve some of the risks, generally the overall risks. After the WBS and activity list are created, and the schedule, resources, and cost are estimated for all the activities, the project team can identify the risks more easily, particularly in the planning phase. The project team must review this register periodically by assigning each risk to a team member.
The risk register can be composed of the items below:
- Risk ID as a unique identifier
- Description (to ensure unambiguous understanding)
- Related WBS activity or activities
- Risk owner (The team member’s name who monitors the risk is recorded.)
- Risk trigger (to know when the risk is becoming an issue or has reached a point that requires action)
- Risk category (based on RBS categories)
- Probability (How likely is the risk to occur?) (see 10.4)
- Impact (How will the risk affect the project if it occurs? E.g., schedule delay, budget overrun, quality issues) (see 10.4)
- Severity (Probability-Impact) Score (see 10.4)
- Risk response strategy (see 10.5)
- Description of the response (see 10.5)
- Response owner (if different from the risk owner)
- Expected impact of the response (What result do we expect from the response?)
Table 10.2 illustrates a short version of a sample risk register for Grocery LLC’s M-Commerce Project. Only six columns have been included in this risk register.
Table 10.3.1: An Example of a Risk Register
| ID | Risk Category | Related WBS Activity | Description | Risk Owner | Risk Trigger |
| 1.0 | Financial | Overall project | Cost estimates may be exceeded, considering inflation factors and foreign exchange currency rates. Although the team has assessed cost factors and incorporated foreseeable inflation and exchange rate fluctuations into the project’s financial scope, unforeseen cost increases may still arise, potentially exceeding initial estimates. Given the comprehensive planning, no further preventative actions are possible at this stage; the team will monitor cost performance throughout the project to identify any deviations. Our previous experience shows a probability level of 15%. | Systems Analyst 1 | CPI (cost performance index) drops below 0.90. |
| 1.1 | Financial | Overall project | Given the potential for fluctuations in software licensing fees and SDK costs, there is a recognized risk that fees may increase unexpectedly, impacting the project budget. The project team monitored historical data and industry trends and set up alerts for any fee changes to assess potential impacts. However, despite the preventive actions, the probability level is evaluated as 10%. | Systems Analyst 1 | Licensing fees increase by 10%. |
| 2.2 | Management |
2.1 2.2 2.3 2.4 2.5 |
The demand for developers increased recently since the demand for online games and mobile apps has been on a sharp rise after the emergence of the COVID-19 pandemic. Although the team has reviewed market conditions and incorporated feasible hiring timelines and skill requirements for developers, the recent high demand may still lead to a shortage, potentially impacting project timelines. Given the thorough planning, no further preventative actions are possible at this stage; the team will monitor staffing levels and market availability as the project progresses to address any unexpected shortages if they occur. The probability level is based on insights from the project team’s experience, company-wide project experience, and input from industry experts, with an estimated probability of 20%. | Systems Analyst 2 | We learn that Developer 1 will not start working on the “Analysis/App Requirements” activities ten days before they start. |
| 2.5 | Technical | Development Phase | Although the team has examined potential integration issues and incorporated all foreseeable requirements into the product scope, unforeseen compatibility issues with third-party APIs may still arise during integration testing, potentially causing delays. Given the thorough planning, no further preventative actions are possible at this stage; the team will monitor the integration during testing to address any unexpected issues if they occur. Our previous experience shows a probability level of 10%. | Systems Analyst 2 | Integration testing reveals that at least 20% of the API calls fail or return errors. |
| 2.6 | Technical | Development Phase | Given the complexity of integrating new features across Android and iOS platforms, technical issues, such as compatibility challenges or bugs in SDKs (Software Development Kits), pose a potential risk to the project schedule. The project reviewed historical data and consulted experienced developers to assess common technical challenges. Although preventive steps like weekly testing and monitoring have been added to the WBS, the team determined a probability level of 20%. | Systems Analyst 2 | Weekly testing identified that at least 15% of newly integrated features fail due to compatibility issues or SDK-related bugs. |
- Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.) ↵
