Risk Registers do you Need More Software?

Risk, the 'R' in RAID, does it require standalone software or is it better integrated into project management tools? One place not to store it is a spreadsheet, could it be done in FinStarty?

A risk register is a common practice scoped to individual projects, departments, or organisations. FinStarty attempts to unify organisations' projects and make the bigger picture easy to see. Our team is nearing the start of a new development project, called "Structured Comments". It's based on the RAID framework, and we are exploring the possibility of extending this to include Risk Registers.

How to make a Risk Register.

Four processes—identification, assessment, response, and ownership of risk — are what the risk registers record.

Step One: Identifying Risks with Stakeholder Insights

Each stakeholder group will understand projects based on their specific expertise. It's essential to utilise these skills when identifying risks. Stakeholders must grasp the project's purpose and be aware of the processes, even in areas where they may not be directly involved.

To identify risks, you must first identify the project stakeholders and specialists. Otherwise, risks can be overlooked compromising subsequent steps.

Step Two: Assessment of Risk with Specialist Stakeholders

The assessment should begin with an initial statement from the reporting person regarding the risk and cause. Specialists providing the risk level and probability, as their evaluations are generally more accurate than those of other stakeholders. The project lead requires a comprehensive explanation for the report, including the reasoning behind the assessment. Estimates of time delays and cost overruns related to the risk could also be included. Evaluations should include why a particular conclusion was reached.

Step Three: Proportional Response to Risk

Response: This may require a change in the project or the acceptance of the risk. Mitigation plans can be created, and scenario planning conducted accordingly.

But there are Four main responses to risk:

• Mitigate, and design plans to reduce the risk.
• Transference, move the risk to a third party (insurance)
• Avoid, the risk that is too great and stops a project
• Step Four: Ownership of Risk

The responsibility for managing risk ultimately lies with the project owner. Consider creating dedicated sub-projects for these risks, with ownership of the risk passing to the assigned person. Those project owners should be able to take the initiative (have authority) to respond if necessary. This individual must be capable of recognising the risk, similar to the person who initially identified it.

Risk Timeframe

Risk statuses can change over time, some risks are linked to specific projects or external time frames. Generally, a risk identified during a project can be closed along with the project's. However, it may still require ongoing monitoring from the relevant department.

When projects are closed with risks still in effect, they'll likely be forgotten unless recorded. Coming back to bite at an unexpected time. Avoid this with a central risk register. Move risks identified on projects to a central risk register when appropriate. This can be aided by an easily automated process containing the previous details.

Next Steps

Moving an identified risk from a project to a central risk register should bring it to the attention of other stakeholders. Either departmental heads, other specialists or anyone who might need to take an interest but is not yet aware.

Risk Review & Resolution

Review and closure, most risks come to an end.

Important never-ending risks should documented, but leaving these risks unstructured in reports can force specific risks down the list. These are likely linked to never-ending risks. Structuring risks in a hierarchical format could negate this happening.

We probably do need to introduce a central risk register, fed by the risks identified in projects with the ability to add risks directly. The display using a hierarchical structure.