Creating an effective risk register
Project risks are a fact of life on any software development project. The key is to identify and quantify the risks in a way that is easy to understand and communicate. A method to achieve this is FMEA—Failure Mode and Effect Analysis. A derivative of this is RFMEA—Risk Failure Mode and Effect Analysis.
Getting ready
Before starting, it is important to have a list of all the potential risks related to your project. An easy way to do this is to solicit information from all the team members and stakeholders. Do not try and categorize or justify the risk; purely collect the information and record the risk.
How to do it...
The risk register is key to the project. It is important to keep this a living document.
- Open your Project Control Register and create a new tab called RFMEA:
- Create your basic headings for your RFMEA or Risk Log:
- a. Risk ID is a unique number assigned to each risk.
- b. Risk event is a description of the risk.
- c. Likelihood is the probability that the risk event will occur.
- d. Risk score is the calculated and determined score of the risk event.
- e. Detection outlines the ability to detect a particular risk event.
- f. Risk Priority Number (RPN) calculates the priority of the risk event.
- g. Requirements # is the unique requirement ID that the risk is related to. The Requirements # is from the Requirements Traceability Matrix.
- Set up your calculations:
- a. Risk Score =
Likelihood*Impact - b. Risk Priority Number (RPN) =
Likelihood*Impact*Detection
- a. Risk Score =
- Enter your risks; the typical guidelines for values include:
- a. Likelihood:
- i. 9 or 10 — Very likely to occur
- ii. 7 or 8 — Will probably occur
- iii. 5 or 6 — Equal chance of occurring or not occurring
- iv. 3 or 4 — Probably will not occur
- v. 1 or 2 — Very unlikely
- b. Impact — if one of the below is true then the impact is:
- vi. 9 or 10
- Schedule — impacts delivery of related component by > 25% OR
- Cost — impacts cost of related component by > 25% OR
- Solution — renders related component unusable
- vii. 7 or 8
- Schedule — impacts delivery of related component between 10% and 25% OR
- Cost — impacts cost of related component between 10% and 25% OR
- Solution — changes the specification of the component which may only deliver partial requirements and may not obtain client approval
- viii. 5 or 6
- Schedule — impacts delivery of related component between 5% and 10% OR
- Cost — impacts cost of related component between 5% and 10% OR
- Solution — changes the specification of the component which may only deliver partial/all requirements but will meet with client approval
- ix. 3 or 4
- Schedule — impacts delivery of related component by < 5% OR
- Cost — impacts cost of related component by < 5% OR
- Solution — changes the specification of the component and the original scope of work and may require internal or client approval
- x. 1 or 2 - Very unlikely
- Schedule — impact insignificant and can be absorbed OR
- Cost — cost increase inconsequential or can be contained within current budget OR
- Solution — changes are not noticeable
- vi. 9 or 10
- c. Detection
- xi. 9 or 10 — Cannot be detected or forewarned, therefore no contingency can be included
- xii. 7 or 8 — Detection method is available but not proven very difficult to identify and react within sufficient time
- xiii. 5 or 6 - Detection method is identified and has been used in the past with mixed success
- xiv. 3 or 4 - Detection method is well known and a moderate degree of effectiveness
- xv. 1 or 2 - Detection method is well known and has been very successful in the past
- a. Likelihood:
- Enhance you risk register to include your strategy to deal with risk. Some common strategies include:
- Avoidance: eliminate, withdraw from, or not become involved with
- Reduction: optimize, mitigate
- Sharing: transfer, outsource, or insure
- Retention: accept and budget
- Monitor your risks frequently and assign an issue ID should a risk be realized. Additional columns which are useful to include to effectively manage the risk are as follows:
- Risk Owner: The person who owns the risk.
- Mitigation actions: Actions that can be taken to reduce the risk.
- Date actions due: When the actions are due by.
- Date risk was last reviewed.
- Risk status: The status of the risk. (New, Escalated to Issue, In Progress, Closed).
How it works...
The risk register exists to give you a forewarning of the events that can affect your project and strategy, should they occur. If a risk is realized, then this should be opened as an issue and managed accordingly.
There's more...
This book does not go into detail about RFMEA; there is a good white paper from the Engineering Management Journal namely:
Page 28 — 35, Engineering Management Journal Vol. 16 No. 4 December 2004 Project Risk Management Using the Project Risk FMEA, by Thomas A. Carbone, Fairchild Semiconductor Corporation and Donald D. Tippett, The University of Alabama in Huntsville.