Here we summarize risk management in a project. Identify tools that can be used to assist in risk management

Most projects are put together and identify significant deliverables and milestones to be delivered in a project, as Wills & Governance (2015) discuss. The deliverables and milestones are normally identified at the start of the project. As a project moves through the deliverables and milestones, risks and issues arise, actions must be taken, and decisions must be made. Risk should be managed the same as the project as Wills & Governance (2015) point out.

Managing risk includes the identification, assessment, and prioritization of risks. Once identified, the risk is coordinated by the risk manager, and resources are allocated to minimize, monitor, and control the possibility or impact of an unfortunate event happening, as described by Wills & Governance (2015). A project characteristically has risks associated with them, and the larger and more complex a project becomes, so does the complexity of the risks. Therefore, risk management is normal and critical to project management and becomes a part of all aspects of project management since risks occur everywhere, as Wills & Governance (2015) points out.

Many corporations and projects manage risks in one document. The document is referred to as a RAID log, as Wills & Governance (2015) describes. A company's RAID log, which is an acronym for Risks, Actions, Issues, and Decisions, normally has standards in place on how to manage the RAID items, which would be assumed as part of planning for the project assessment. To create a RAID log, one needs to have an approach to identify, track, and manage risk. The four primary steps to the approach, as Wills & Governance (2015) describe, are identifying the risk, assessing the risk, taking action, and monitoring the risk. The first way to identify the risk would be to document the risk in the RAID log. The second step is to assess the risk to understand the impact and the probability of the occurrence of the risk. The third step, once the risk has been assessed, the project team would take action on the risk. The action could be accepting a risk, avoiding it or taking no action to mitigate it. The last step is to monitor the risk. A risk is a living process, and if the team has addressed the risk, it should still be monitored to be sure the resolution or result impacts the team's expectations.

One of the managers on our team used a risk management log at the healthcare company he worked at before working with our team. The DevOps manager decided to adopt that risk management log. The team produces a release once a quarter using Agile Scrum. As part of planning for the software release each quarter, the team reviews all the completed features to understand the risks. They are documented in the risk management log. The team started this in January this year and helped the team think about what risks we have in the feature and what action would be taken if the issue arises during the release or after the release occurs. The columns in the log we used were current status, risk impact, the probability of occurrence, risk map(a color of red, yellow or green), risk description, project impact, risk area, symptoms, triggers, risk response strategy, response strategy, contingency plan, and the symptom occurred to date. Going through the process of filling these columns out as a team helped me think about what action or reaction would occur for each risk before it happened. The document is completed as part of the teams Operational Readiness Review(ORR).

References

Wills, K. R., & Governance, I. (2015). Assessing IT projects to ensure successful outcomes (1st ed.). Ely Cambs: It Governance.