Sprint 4 Risk Management Plan - Pyxsys/SOEN390_19 GitHub Wiki
04/07/2021
| Version # | Implemented By | Revision Date | Approved By | Approval Date | Reason |
|---|---|---|---|---|---|
| 1.0 | Nirmal Randhawa/Mickael Bou-Samra | 01/05/21 | Pierre-Alexis Barras | 01/27/21 | Initial Risk Management Plan Draft |
| 1.1 | Pierre-Alexis Barras/Mickael Bou-Samra | 02/02/21 | Pierre-Alexis Barras | 02/02/21 | Sprint 1 Release Risk Management Plan |
| 2.0 | Pierre-Alexis Barras | 02/23/21 | Pierre-Alexis Barras | 02/23/21 | Sprint 2 Release Risk Management Plan Draft |
| 3.0 | John Zeng | 03/17/21 | John Zeng | 03/17/21 | Sprint 3 Release Risk Management Plan Draft |
| 4.0 | John Zeng | 04/07/21 | John Zeng | 04/07/21 | Sprint 4 Release Risk Management Plan Draft |
UP Template Version: 11/30/06
A risk is an event or condition that, if it occurs, could have a positive or negative effect on a project’s objectives. Risk Management is the process of identifying, assessing, responding to, monitoring, and reporting risks. This Risk Management Plan defines how risks associated with the Kap Industries project will be identified, analyzed, and managed. It outlines how risk management activities will be performed, recorded, and monitored throughout the lifecycle of the project and provides templates and practices for recording and prioritizing risks. The Risk Management Plan is created by the project manager in the Planning Phase of the CDC Unified Process and is monitored and updated throughout the project. The intended audience of this document is the project team, project sponsor and management.
The purpose of the risk management plan is to foresee risks and estimate risk impacts, This will help identify risks before they occur. Risk management is important during the conceptualization, planning and execution phases of the project.
The project manager working with the project team and project sponsors will ensure that risks are actively identified, analyzed, and managed throughout the life of the project. Risks will be identified as early as possible in the project so as to minimize their impact. The steps for accomplishing this are outlined in the following sections. The will serve as the Risk Manager for this project.
Risk assessment consists of 3 processes: risk identification, risk analysis and risk prioritization. Risk identification will include all the risks of the project and these risks could be identified as technology risks, organizational risks, people risks and requirements risks. Risk analysis assesses the likelihood of occurrence of the risks and impact on the project itself. Lastly, risk prioritization involves setting priorities to focus risk mitigation efforts.
Risk identification will involve the project team, appropriate stakeholders, and will include an evaluation of environmental factors, organizational culture and the project management plan including the project scope. Careful attention will be given to the project deliverables, assumptions, constraints, WBS, cost/effort estimates, resource plan, and other key project documents.
A Risk Management Log will be generated and updated as needed and will be stored electronically in the project library located at .
| ID | Date Raised | Risk description | Owner |
|---|---|---|---|
| 1 | 01/25/2021 | Unauthorized privileged user access. | Developers, System Admins |
| 2 | 01/25/2021 | Implementing a disruptive feature to organizations performance. | Developers, Product Owner, Users |
| 3 | 01/25/2021 | Data leaked to the public. | Developers, System Admins, Users |
| 4 | 01/26/2021 | Inconsistencies between database and instance values. | Developers, Users, Product Owner |
| 5 | 01/26/2021 | Improperly formatted transaction received. | Developers, Product Owner, Clientele |
| 6 | 01/26/2021 | System is unpowered/goes offline unexpectedly. | Developers, Product Owner, System Admins |
| 7 | 01/27/2021 | UI is unintuitive/ Steep application learning curve | Users, Product Owner |
| 8 | 01/27/2021 | Poor elicitation of requirements and risks | All parties |
| 9 | 01/28/2021 | Bike produced with defected parts | User, Manufacturer |
| 10 | 01/29/2021 | Features requiring the implementation of incompatible software. | Developers, Product Owner |
| 11 | 01/30/2021 | Inability to complete requirements/features by established deadline. | All parties |
| 12 | 02/06/2021 | Users unable to set up project. | Product Owner, Users, Developers |
| 13 | 03/11/2021 | CI delays project advancement. | All parties |
All risks identified will be assessed to identify the range of possible project outcomes. Qualification will be used to determine which risks are the top risks to pursue and respond to and which risks can be ignored. The risks identified can all pose a threat to the system however there are some risks that are more serious and can lead to more serious consequences so they must be tackled first.
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: Each identified risk will be assigned both a probability and impact attribute varying from High, Medium, and Low. The risk items will then be placed in a 3x3 impact matrix. Risks that fall within the (R)ed and (Y)ellow zones will have risk response planning which may include both a risk mitigation and a risk contingency plan.
Probability
- High – Greater than 70% probability of occurrence
- Medium – Between 30% and 70% probability of occurrence
- Low – Below 30% probability of occurrence
Impact
- High – Risk that has the potential to greatly impact project cost, project schedule or performance
- Medium – Risk that has the potential to slightly impact project cost, project schedule or performance
- Low – Risk that has relatively little impact on cost, schedule or performance
The table below outlines the probability of each risk occurring and the impact it would have if it occurs along with the mitigating action corresponding to each risk:
| ID | Risk Description | Probability of Risk Occurring | Impact if Risk Occurs | Severity | Risk Mitigation |
|---|---|---|---|---|---|
| 1 | Unauthorized privileged user access. | Low | High | High | Roles are properly set. Admin’s privileged access defined and tested. |
| 2 | Implementing a disruptive feature to organizations performance. | Medium | Medium | High | Consult with users, client, and development team to effectively determine product requirements |
| 3 | Data leaked to the public. | Medium | Low | Medium | Encrypt information |
| 4 | Inconsistency/decoupling between database and instance values. | Medium | High | High | Safe multithreading practices enforced in development. Rigorous time-sensitive testing. |
| 5 | Improperly formatted transaction received. | High | Medium | Medium | Enforce the use of a standard acceptable format on client and server. |
| 6 | System is unpowered/goes offline unexpectedly. | Low | High | High | Use of logs to track actions performed on the system. Regular back-up creation. |
| 7 | UI is unintuitive/Steep application learning curve. | Medium | High | Low | Provide multiple mock-ups and testing of UI. Implement tutorials and tool tips. |
| 8 | Poor elicitation of requirements and risks | Medium | High | Medium | Produce several documents and consistent meetings to clarify requirements. |
| 9 | Bike produced with defected parts | Low | Medium | High | Enforce a quality check before introducing parts into the system. |
| 10 | Features requiring the implementation of incompatible software. | Medium | Medium | Medium | Produce code that is decoupled and modular. |
| 11 | Inability to complete requirements/features by established deadline. | High | Medium | Medium | Enforce consistent progress updates on active tasks. |
| 12 | Users unable to set up project. | Medium | High | High | Provide extensive instructions in project .README |
| 13 | CI delays project advancement. | Medium | low | low | Produce effective tests and good code to pass all checks. |
Risk Item Impact Matrix
| Impact | High | Y: 1, 6 | R: 4, 7, 8, 12 | R: |
| Medium | G: 5, 9 | Y: 2, 10 | R: 11 | |
| Low | G: | G: 3 | Y: | |
| Low | Medium | High | ||
| 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 numerical rating applied to each risk based on this analysis, and then documented in this section of the risk management plan. A lower number signifies greater importance.
| ID | Risk Description | Risk Level |
|---|---|---|
| 1 | Unauthorized privileged user access. | 1 |
| 2 | Implementing a disruptive feature to organizations performance. | 2 |
| 3 | Data leaked to the public. | 9 |
| 4 | Inconsistency/decoupling between database and instance values. | 8 |
| 5 | Improperly formatted transaction received. | 5 |
| 6 | System is unpowered/goes offline unexpectedly. | 6 |
| 7 | UI is unintuitive/Steep application learning curve. | 7 |
| 8 | Poor elicitation of requirements and risks | 7 |
| 9 | Bike produced with defected parts | 9 |
| 10 | Features requiring the implementation of incompatible software. | 2 |
| 11 | Inability to complete requirements/features by established deadline. | 5 |
| 12 | Users unable to set up project. | 1 |
| 13 | CI delays project advancement. | 8 |
Each major risk (those falling in the (R)ed & (Y)ellow zones) will be assigned to a project team member for monitoring purposes to ensure that the risk will not “fall through the cracks”.
For each major risk, one of the following approaches will be selected to address it:
- Avoid – eliminate the threat by eliminating the cause
- Mitigate – Identify ways to reduce the probability or the impact of the risk
- Accept – Nothing will be done
- Transfer – Make another party responsible for the risk (buy insurance, outsourcing, etc.)
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.
| ID | Risk Description | Risk Mitigation | Risk Contingency | Approach |
|---|---|---|---|---|
| 1 | Unauthorized privileged user access. | Roles are properly set. Admin’s privileged access defined and tested. | - | Avoid |
| 2 | Implementing a disruptive feature to organizations performance. | Consult with users, client, and development team to effectively determine product requirements | - | Mitigate |
| 3 | Data leaked to the public. | Encrypt information | - | Accept |
| 4 | Inconsistency/decoupling between database and instance values. | Safe multithreading practices enforced in development. Rigorous time-sensitive testing. | Code must be reviewed to pinpoint the cause of the decoupling and resolve it. | Mitigate |
| 5 | Improperly formatted transaction received. | Enforce the use of a standard acceptable format on client and server. | Notify the sender of the accepted format and ask to resend. | Transfer |
| 6 | System is unpowered/goes offline unexpectedly. | Use of logs to track actions performed on the system. Regular back-up creation. | - | Mitigate |
| 7 | UI is unintuitive/Steep application learning curve. | Provide multiple mock-ups and testing of UI. Implement tutorials and tool tips. | Give one-on-one tutorials to staff to guide them through features. | Mitigate |
| 8 | Poor elicitation of requirements and risks | Produce several documents and consistent meetings to clarify requirements. | Requirements must be elicited again to achieve the requested result. | Mitigate |
| 9 | Bike produced with defected parts | Enforce a quality check before introducing parts into the system. | - | Mitigate |
| 10 | Features requiring the implementation of incompatible software. | Produce code that is decoupled and modular. | - | Avoid |
| 11 | Inability to complete requirements/features by established deadline. | Enforce consistent progress updates on active tasks. | Prioritize more important requirements and use the time left over to work on the remaining tasks. | Accept |
| 12 | Users unable to set up project. | Provide extensive instructions in project .README | - | Mitigate |
| 13 | CI delays project advancement. | Produce effective tests and good code to pass all checks | - | Mitigate |
A Risk Log will be maintained by the project manager and will be reviewed as a standing agenda item for project team meetings.
The following table provides definitions for terms relevant to the Risk Management Plan.
| Term | Definition |
|---|---|
| ERP | Enterprise Resource Planning |
| Clientele | Refers to users that interact with the application as customers of the users (eg. Raw Metal/Parts Vendor, End-Consumer) |
The level of risk on a project will be tracked, monitored and reported throughout the project lifecycle.
A “Top 10 Risk List” will be maintained by the project team and will be reported as a component of the project status reporting process for this project.
All project change requests will be analyzed for their possible impact to the project risks.
Management will be notified of important changes to risk status as a component to the Executive Project Status Report.
The risk management team will be using a top-N (top 5 in this case) risk report to monitor risks for the ERP software. The evolution of the ERP software will give rise to new risks and all risks will have to be reprioritized. Our risk report contains the following information: the risk factors, ranks from this week and last week, potential impact, mitigating actions and time frame for resolution.
| Rank | Risk Factor | Potential Impact | Time Frame for Resolution |
|---|---|---|---|
| 1 | Users unable to set up project. | No progress completed/Unusable application | Immediate |
| 2 | New functional requirements | Previous functional requirements may be affected. | Immediate |
| 3 | Organizational risks | Difficult to spot, may highly impact software functionality. | Immediate |
| 4 | Changes in ERP user interface | Impacts functionality | Validation complete by next week |
| 5 | Inability to complete requirements/features by established deadline. | Fails to meet business requirements | Meetings must be held after PO meeting. |