Risk Process
From Square Root
This process has served it's useful life. It's not a bad thing, it just means we don't need this process anymore.
Read the reflection section for more information.
This process defines the team's risk identification, management, and tracking strategy. The ultimate goal is to proactively attack risks to increase the team's chances of success.
Contents |
Approach
Risks are defined by the following fields.
- Description
- Describes the risk in a condition -- consequence format that is concise and comprehensive.
- Probability
- Likelihood that a risk can occur .1 low, 1 a sure thing.
- Impact
- The projected impact this risk could have as a problem. 1 is low, 10 is high
- Exposure
- Product of the probability of a risk occurring and the projected magnitude of the loss.
- First Indicator
- First indication that a risk element is about to or has become a current problem. Indicates ;that a better mitigation strategy is needed.
- Mitigation Action
- Planned actions to keep the risk from becoming a problem.
- Responsible
- Person responsible for continually assessing this risk and ensuring that it does not become a problem.
- Category
- The general subject a risk falls under
- Contingency Plan
- If this risk becomes a problem, the actions that will take place to deal with the problem.
- Trigger for Contingency
- Conditions under which the contingency plan will be executed
- Status
- Describes the effectiveness of risk mitigation plan
- Notes
- Any additional comments that may be helpful for post milestone review.
- Date
- The date the risk was identified
There are five basic areas any risk management strategy must address[1].
- Identify - There are two ways a risk can be identified. The idea is to make sure important risks are not overlooked and to strike a balance in the formality of how risks are recorded. All risks added to the list must be in an appropriate condition..consequence format but need not have all fields immediately filled in.
- Risks can (and should) be brought up at any meeting and will be immediately added to the risk list.
- Risks can be added to the risk list between meetings by coordinating with the Risk Manager.
- Analyze - Adding probability, impact, or priority of a risk.
- Plan - Adding trigger, mitigation, contingency, and indicator information to a risk.
- Track - Examination of collected risks and risk data to determine if planned actions are having the desired effects or if risks need to be updated.
- Control - Modifications to risk plans.
Continuous feedback and communication among the team on risks is critical to the success of this strategy.
The top 20% of risks in a prioritized list are considered the top priorities[2] [3] when allocating resources to deal with risks.
Risk are prioritized by exposure. Probability and impact is initially assigned by
I want a method for assigning priority, probability, and impact that is time effective and accurate.
Roles
Risk Manager - this person is in charge of making sure all risk documents are kept up to date, calculating risk metrics, and facilitating risk related discussions at meetings.
Metrics and Data
Top 10 List
The Top 10 List consists of the top 10 risks from the prioritized risk list. Each risk is presented in the list along with it's rank this week, last week, the number of weeks on the list, and any progress that is being made to address the risk[4].
- Frequency
- At least every iteration, should be reviewed at weekly team status meetings.
- Data
- Prioritized list of team risks.
It is expected that risks will not stay on the Top 10 List indefinitely. This isn't a metric that can be defined in terms of good or bad but more a tool for making sure the team is addressing risk appropriately.
Risks by Category
This metric is meant to expose the most risky areas of the project.
- Frequency
- At the end of every iteration
- Data
- Categorized risk list
This isn't a metric that can be defined in terms of good or bad but more a tool for identifying areas of the project that may be in need of more attention than others. Care should be taken in how this data is represented.
Risk to Problem Conversion
This metric is a count of the number of risks that become problems for the team. Any time a risk becomes a problem a report will be created to understand why the problem occurred, if it could have been avoided, and what lead to the problem occurring. Problem reports will be held in the wiki.
- Frequency
- Any time a risk becomes a problem as identified by the contingency trigger
- Data
- Risk list and the assigned team member's assessment and analysis of the risk.
This metric is meant to help the team learn from mistakes so that we prevent them from happening again in the future either on this project or on future projects on which we work.
Analysis and Reflection
Someone has indicated that this page contains outdated or incorrect information.
Reason: why did we change this process? say why and link to the new one.
