| Version | Date | Change Information | Author | Approver |

| ------- | ---- | ------------------ | ------ | -------- |

| V1.0 | March 1, 2026 | Initial Draft | Melisha Dsouza | Pooja Thorat |

A risk is defined as an uncertain event or condition that, if it occurs, may have a positive or negative impact on a project’s objectives. Risk is inherent in all projects; therefore, it is essential for project managers to continuously identify, assess, and manage risks throughout the project lifecycle.

This document defines the procedures, roles, and responsibilities for effective Risk and Opportunity Management for the project Letscatchup, ensuring that potential risks are proactively addressed and opportunities are leveraged to achieve project objectives.

The Project Manager, in collaboration with the project team and project sponsors, shall ensure that risks are systematically identified, analyzed, planned for, monitored, and controlled throughout the lifecycle of the project.

Risks shall be identified as early as possible to minimize their potential impact on project scope, schedule, cost, and quality. The overall risk management process and its associated activities are detailed in the subsequent sections of this document.

The Project Manager (or designated authority) shall act as the Risk Manager for this project and will be responsible for maintaining the risk management activities and records.

Risk identification shall involve active participation from the project team and relevant stakeholders. The process will include the evaluation of internal and external factors such as organizational culture, environmental conditions, and elements of the project management plan, including project scope.

- Project deliverables

- Assumptions and constraints

- Work Breakdown Structure (WBS)

- Cost and effort estimates

- Resource and staffing plans

- Schedule and milestone plans

- Other key project documentation

A Risk Management Log shall be created and maintained in Jira. This log will be reviewed and updated regularly to reflect newly identified risks and changes to existing risks.

Risks may be identified across multiple dimensions of the project. The following generic categories shall be used as guidance for risk identification:

1. With respect to the **Project Team** (Skills, experience, availability, communication)

2. With respect to **Human Resources and Contractors** (Resource dependency, turnover, contractual issues)

3. With respect to the **Customer** (Availability, expectations, feedback delays)

4. With respect to **Products / Technology** (Technical complexity, tool limitations, integration issues)

5. With respect to **Project Management** (Planning accuracy, governance, decision-making)

6. With respect to **Requirements** (Clarity, completeness, stability)

7. With respect to the **Schedule** (Dependency risks, estimation errors, delays)

8. With respect to **Change Management**

- Requirement changes

- Plan or scope changes

All identified risks will be assessed to determine the range of possible project outcomes. This qualification will be used to identify high-priority risks that require response planning and lower-priority risks that may be accepted or monitored.

- The responsible stakeholder shall identify both inherent and residual risks.

- A risk that exists assuming no controls are in place and that may negatively affect the achievement of organizational or project objectives.

- The risk that remains after controls and mitigation measures are applied. Since risk cannot be completely eliminated, controls are designed to reduce the risk to an acceptable level aligned with the organization’s risk appetite.

- **Example 1** Fire in a production facility that may have catastrophic consequences represents an inherent risk. Controls such as fire extinguishers, sprinklers, and emergency evacuation plans reduce the likelihood and impact. The remaining exposure after these controls is the residual risk. Internal auditors evaluate the adequacy and effectiveness of these controls to ensure the residual risk is within acceptable limits.

- **Inherent Risk:** A key developer may leave the project, which could delay the project schedule if no backup resource or knowledge transfer exists.

- **Residual Risk:** To reduce this risk, management assigns a backup developer, maintains proper documentation, and conducts knowledge-sharing sessions. Even after these controls, there is still a possibility of temporary delays during the transition period. This remaining exposure is the residual risk.

The probability and impact of occurrence for each identified risk will be assessed by the project manager, with input from the project team using the following approach:

1. **Severe**: Business untenable.

2. **High**: Business operations severely impaired.

3. **Medium**: Some important business goals cannot be achieved.

4. **Low**: Some minor business goals are not achieved.

5. **Negligible**: Very minor business goals are not achieved

1. **Almost certain:** Better than 95 percent chance of happening.

2. **Very likely**: Better than 75 percent chance of happening.

3. **Likely:** Better than 50 percent chance of happening.

4. **Unlikely**: Less than 50 percent chance of happening.

5. **Very unlikely**: Less than 10 percent chance of happening.

1. **Extreme**: Executive notification essential.

2. **High**: Considerable business disruption likely. Immediate attention required.

3. **Medium**: Monitoring and weekly reporting are recommended.

4. **Low**: An acceptable level of risk.

**Level of Risk= Impact * Probability**


- Analysis of risk events that have been prioritized using the qualitative risk analysis process and their effect on project activities will be estimated. A risk register and matrix will be maintained in jira as below,



- OPEN

- IN PROGRESS

- CLOSED

- NEVER OCCURRED


- OPEN

- IN PROGRESS

- CLOSED


Each major risk will be assigned to a project team member for monitoring to ensure it is actively managed.

- **Avoid**– Eliminate the threat by removing the cause or changing plans

- **Control/Mitigate**– Identify ways to reduce the probability or the impact of the risk

- **Accept**– Accept the risk and plan contingencies if it occurs

- **Transfer/Share**- Make another party responsible for the risk (buy insurance, outsourcing). Outsource risk (or a portion of the risk – Share risk) to third parties or parties that can manage the outcome. This is done financially through insurance contracts or hedging transactions, or operationally through outsourcing an activity.

For each risk that will be mitigated, the project team will identify ways to prevent the risk from occurring or reduce its impact or probability of occurring. This may include prototyping, adding tasks to the project schedule, adding resources, etc.

For each major risk that is to be mitigated or that is accepted, a course of action will be outlined for the event that the risk does materialize in order to minimize its impact.

Risks will be tracked, monitored, and reported throughout the project lifecycle. A Top 10 Risk List shall be maintained and included in project status reports.

All project change requests will be analyzed for their possible impact on the project risks.

All change requests will be assessed for their impact on existing risks. Management will be notified of significant changes through executive status reporting.

A Risk Log shall be maintained in Jira by the Project Manager and reviewed regularly during project meetings. The format of the Risk Log should be defined in the Risk Management Plan. Risk management plan approval.

List the individuals whose signatures are desired. Examples of such individuals are a Business Owner, a Project Manager, or a Project Sponsor. Add additional lines for signature as necessary. Although signatures are desired, they are not always required to move forward with the practices outlined within this document.

| Record | Where to Get? |

|--------------------------------|---------------|

| Procedure Document | Google Drive |

| Risk Management Plan Document | Google Drive |

| Risk Register / Log | Jira Tool |

| Generic Risk Document | Google Drive |

| RSK Audit Checklist | Google Drive |

- The project team shall recognize the importance of risk management

- The PRRT team should be committed to implementing risk management effectively

- If required, A training should be organized to understand risk management

- The PRRT team should be committed to monitoring performance and reviewing progress in risk management

Work product for the Risk Management area is

- Risk log/Register

The project should have a risk review team.

**Project Risk Review Team (PRRT):**

The risk management board comprises the Project Team, which includes the

- Project Owner

- Project Manager

- Lead developers

- QA Team

- Client

- Reviewing and approving identified risks

- Ensuring approved risks are logged in Jira

- Seeking solutions and mitigation strategies

- Planning scenarios to avoid or minimize risks

| Role | Responsibilities |

|------|------------------|

| Project Owner / Seller (Project Sponsor) | • Chair all Risk Management Board meetings <br> • Approve issues requiring additional scope, time, or cost |

| Project Manager | • Overall responsibility for all project risk management activities <br> • Identify risks <br> • Communicate risk management activities to project stakeholders <br> • Participate in Risk Management Board meetings <br> • Re-baseline project items if impacted by risk management changes |

| Project Coordinator | • Participate in Risk Management Board meetings <br> • Update risks in the Jira tool |

| Testing Manager | • Participate in Risk Management Board meetings <br> • Identify and confirm risk closure status |

| Project Buyer (In-house Project) | • Participate in Risk Management Board meetings <br> • Identify and analyze risks from the client side <br> • Provide feasible solutions for identified risks |

- This is a relatively easy measure.

- You can track the number of risks identified per project or program.

- There is no **‘right answer’** to how many risks a project should have identified.

- It completely depends on the **type of project.**

- A project you have carried out many times before will be **low risk**.

- A project with multiple areas of complexity using a methodology that is new to the team will inherently be riskier.

- However, this measure is useful for comparing projects where the PMO can apply some basic principles.

- If you know that **two projects are similar in many respects** (like duration, priority, complexity) then you can assume they would have around the **same number of risks**.

- If one project manager has identified **90 risks** and the other project manager has **identified 19**, you would be **justified in comparing** how robustly they are doing risk analysis on the project.

- You can also track the number of risks that materialize and turn into **real-life** issues on the project. Hopefully, there aren’t that many.

- However, this measure can also tell you that **risk analysis** is being done thoroughly.

- For example, if lots of risks are tracked that then turn into issues, you can give the team credit for spotting that these things might cause problems.

- If lots of **risks are tracked** but **none turn into issues**, this could be that the team is **tracking the wrong things** – issues pop up out of nowhere and never make it onto the risk log.

- As with all of these metrics, you need to consider the narrative around the metric to get the full picture.

- This can be a sign that lessons aren’t being learned.

- If a **risk occurs multiple times**, across the same project or several projects, it can show you that teams aren’t learning from past experience.

- _How do you track something you didn’t know was going to happen?_ This is a tricky one! Think of it as a way to track issues that occur that should have been flagged as a risk but weren’t.

- Look at the **number of issues** on the issue log that could have been **foreseen** but bypassed the risk stage.

- Track **how many risks passed by without happening**, whether you took active measures to manage them or not. This can be a **counterbalance** to the number of risks identified.

- If you identify a lot and close a lot, you can work out the key risks facing the project. This measure is also a sign that **active risk management** is happening during the project.

- A large number of identified risks and **no closed risks** show that risk analysis was carried out at the **start of the project** and then **not followed** up throughout the project lifecycle.

- You can include risk management metrics in your **project closure report**, and you should.

- However, to be able to take any practical steps to better risk management, or for **spotting trends**, you should be looking at your key metrics long before you write the project closure report.

- Some of the metrics above can only be calculated at the **project shutdown**, but where you can track measures across a project or program on an ongoing basis, that is better.

- It gives you a chance to spot trends, compare projects on a more real-time basis and do something about the data you uncover to help improve risk management across the organization.

- A periodic review should be conducted to verify and validate risks

- A risk plan should have details of the review

Process flow helps to understand when a team should identify the risks of the project and management.

- The project manager will create a **risk management plan**

- The project Manager will **identify** every **possible risk** associated with the project and mitigations.

- During Recording identified risk “**Risk**” Issue type will be used in Jira.

- Risk Assessment (Inherent or Residual, Probability and Impact)

- Symptoms

- Triggers

- Mitigation

- Contingency plan

- Risk Response Strategy

- Identified risks will be **unassigned** unless and until they are no longer occurring.

- Once a **risk occurs,** the coordinator or manager will **assign** it to the respective person. (Can assign it to self as well)

- The person who is responsible to resolve risk will change the status to In Progress ->Closed and report the same.

- A risk that is unidentified and occurred will come under the Unidentified Issue(Risk) type.

- A project manager or coordinator will be responsible for recording and assigning it to the respective person.

- The person who is responsible to resolve risk will change the status to In Progress ->Closed and report the same.

- PQA will be responsible for periodic audits

- To record metrics

- A total number of “Risk” in Jira will be calculated as the number of risks identified.

- Risk which is “IN PROGRESS” and “CLOSED” status will be counted as an occurred risk.

- Several risks which are linked as duplicates will be counted as risks that occurred more than once.

- Risks with issue type “Unidentified Issue(Risk)” will be counted as not identified risks

- An identified risk with the status “NEVER OCCURRED” will be counted as a risk that never occurred.

- Entry Criteria

- Inputs and Start Criteria

- Risk Plan

- Risk Identification and Analysis

- Exit Criteria

- Completion Criteria

- Follow plan and mitigations

| Acronym | Abbreviation |

|---------|--------------|

| PRRT | Project Risk Review Team |