官术网_书友最值得收藏!

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.

  1. Open your Project Control Register and create a new tab called RFMEA:
    How to do it...
  2. 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.
      How to do it...
  3. Set up your calculations:
    • a. Risk Score = Likelihood*Impact
    • b. Risk Priority Number (RPN) = Likelihood*Impact*Detection
      How to do it...
  4. 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
        1. Schedule — impacts delivery of related component by > 25% OR
        2. Cost — impacts cost of related component by > 25% OR
        3. Solution — renders related component unusable
      • vii. 7 or 8
        1. Schedule — impacts delivery of related component between 10% and 25% OR
        2. Cost — impacts cost of related component between 10% and 25% OR
        3. Solution — changes the specification of the component which may only deliver partial requirements and may not obtain client approval
      • viii. 5 or 6
        1. Schedule — impacts delivery of related component between 5% and 10% OR
        2. Cost — impacts cost of related component between 5% and 10% OR
        3. Solution — changes the specification of the component which may only deliver partial/all requirements but will meet with client approval
      • ix. 3 or 4
        1. Schedule — impacts delivery of related component by < 5% OR
        2. Cost — impacts cost of related component by < 5% OR
        3. 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
        1. Schedule — impact insignificant and can be absorbed OR
        2. Cost — cost increase inconsequential or can be contained within current budget OR
        3. Solution — changes are not noticeable
    • 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
  5. 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
    How to do it...
  6. 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.

主站蜘蛛池模板: 会同县| 临海市| 萍乡市| 阿拉尔市| 庆阳市| 临城县| 汪清县| 伽师县| 元谋县| 布拖县| 江源县| 余干县| 兴海县| 两当县| 万源市| 北川| 河间市| 东源县| 游戏| 贺兰县| 靖边县| 新兴县| 沐川县| 莒南县| 天镇县| 门头沟区| 紫阳县| 启东市| 台南县| 承德市| 吴江市| 武隆县| 额敏县| 玉山县| 行唐县| 张北县| 都昌县| 武川县| 淮滨县| 玛沁县| 阳曲县|