Scope

Risk Analysis and Management are an integral part of the Project Management. This document has the scope of collecting most of the essential data regarding each risk. Due to its interactive nature, every register entry can be filled completely in with different steps. Thereby, in order to assure the consistency of the information, it is useful to check the “maturity” (stage reached in the process) of each entry.

Process description

This register needs to be ready for starting the Business Case preparation. Whatever is the choice for compiling it (either public or filtered) at least a part of the register shall be made public. Keeping in mind the existing company’s policies and predominant culture, the information describing the risks under scrutiny has to be shared and accepted by all interested parties (i.e. a variable section of stakeholders).

Quality

Data validation is an essential step of the process. Validation includes the traceability of the sources, verification of the tools (e.g. equations) used for calculating values. The most important element is the trust between the proponent (who signals the risk and reasonably could become its owner) and the PM, who remains accountable for the matter.

RACI (who does what)

ID	Operation desc./Roles	Owner	Spr	PM	SME	BA	Stkhd
1	Organizing the collections of thoughts about risks	C	C	A	C	C	C
2	Posting the risk as perceived	A	A	A	A	A	A
3	Daily digest of the issues and check the situation based on each risk’s proximity.	I	A	C	C	R	I	I
4	Quick assessment with the proponent and/or producer (see post about Triage)	I	A	C	C	R	I	I
5	Updating the weekly meeting with the outstanding items	I	A	R	C	C	I	C
6	Carry out the Impact Analysis (see document)	I	A	R	C	C	C	C
7	Chairing the meeting with stakeholders[1]	I	AR	C	I	I	I	C
8	Managing the next step[2]	C	AR	C	I	I	I	I

ID Explanation

1. The risks described in the Business Case (e.g. marketing, organizational etc.) are the first to be registered beside the person (owner) who will check them.
   1. The “internal kick-off” meeting is the first occasion for setting the right attitude from the team’s members. Each person has to feel free to highlight possible causes that would hamper the production.
2. The use of workshops or wikis will be encouraged during all project’s life.
3. Being informed of the evolution of the mapped risks.
4. Any time a new risk will be spotted, the first phase of the evaluation process should start a.s.a.p. It depends upon the first output to decide for the next step.
5. Risks and Issues should be dealt with in a specific meeting, whose agenda has to include all the necessary information and the attendance of the “Risk Owner”
6. Impact Analysis results will be read within the Risk Governance Strategy.
7. The meeting will discuss the result of the Impact Analysis and then evaluate the validity of the proposed actions (e.g. Acceptance, Transference etc.)

Document structure

Distribution list

This kind of information can be considered highly important. Therefore, it is suggested to inform all the interested stakeholders as described in the “Communication Management Strategy”.

The level of management to be (directly[i]) involved depends upon the rank of the output.

The main criteria for making available this document should be based on the resulted importance of the issue itself. However, the proposer (and any relevant stakeholder behind the request) shall be informed of every change of status.

Document structure

Registrar Section

Item Name	Notes
Risk ID	It is part of the Registrar Section (see post)
Issue ID	If available, it means that the Risk has been detected after the release of the Plan (more to come in the next posts)
Impact Report ID	See Impact Analysis and Report
Item ID	the reference to the Product Breakdown (more to come)
Risk Plan ID	the reference to the most specific item in the mitigation plan(s)
Exception Report ID	the reference to the document describing the proposed actions (when the proximity is very small or the event has been triggered – see pending status)
Version	The versioning (see post) it is not only the best way for tracking changes; it offers the possibility to understand the (d)evolution of the current situation.
Sign	Is it a Risk or an Opportunity (see post)? Using the same register makes possible to catch and adjust any possible occurrence.
Risk Category	Risk Category – See Category Risk’s list
Description	It is a key value. The reason for this lies in the clarity and then the understandability of the threat to the outcome
Cause	It could be a sensitive topic. It is not only a problem of “savoir faire” with the involved people. Sometime the complexity of the argument requires the usage of Fishbone diagram
Event	It is the situation that triggers the occurrence that influences the outcome. The event cannot be analyzed without explicit references to the Cause
Consequence	Its description cannot be limited to the financial costs (impact). Again the importance of a clear and fully referenced description represents a huge asset for the project.
Impact	This topic has been discussed in this post. In essence, it is the cost to be paid if the event had it full effect on the output.
Inherent	It is the main part of the analyzed risk
Residual	It is the remaining part left by any action to be taken (mitigation etc.). The term remains meaningful only if it is still indicating an acceptable risk. See DAU definition
Probability	AKA likelihood. While it definition is quite easy; its application presents a lot of challenges. Especially when the history (e.g. team productivity) is not available.
Inherent	It is pointing out the main “flow”
Residual	It indicates the collateral situations. Sometimes, after a careful investigation of the “Causes” it is possible that these two values are reversed.
Expected Value	It is the correspondence of the Impact when we are dealing with the Opportunities
Proximity	As discussed in the previously, this value gives the timing. However, there are some scenarios where the time is not a calendar value; it is created by other factors, for example: production rhythm
Risk Response	Categories (see post). It is one of the following type of the following actions (making reference to Risk Plan):
Assumption	the risk is positively accepted
Transfer	any action that moves the responsibility toward an entity able to tackle it better (e.g. insurance)
Mitigation	an action that reduces the impact. It could be a workaround.
Avoidance	When the root of the problem can be eliminated
Risk Status	It states the condition of the process. These can be some useful labels
Discovered	It has been classified, but it is still not assessed.
Analyzed	There is a “price”, but the Owner is still to be assigned.
Allocated	The Owner has been assigned.
Active	The event is not yet happened.
Pending	The event has been triggered, operations are undergoing
Closed	The event did not happened
Risk Owner	The person who is responsible for monitoring the event. He/she has to be just one for each risk and directly involved in the production.

Technical domains

1)      Project Mandate for any involved role/person.

2)      Business Case

3)      Every approved plan

4)      Quality

Financial / Commercial domains

1)      Project Brief

2)      Cash flow

Notes

---

[1] Based on the Impact Analysis Report, already distributed to the interested people

[2] It could be either the production of the workaround or starting the procedure for Change Management; this could include the Exception Report

---

[i] Directly it means that the document will be sent via email.