In this post I would like to continue speaking about how TFS helps me to path through project detailed planning phase. Initiate discussion can be found at Projects Detailed Planning Phase. Why TFS?.
This time I will speak about Risk work item and how we use it in Project Management. Generally, this post will be dedicated to Project Management rather then TFS.
The purpose of the Project Risk Management is to identify, analyze, and respond to project risks in order to maximize the results of positive events and minimize the consequences of adverse events. The Risk Management process ensures that each risk identified within the project environment is documented, prioritized and mitigated wherever possible. The Risk Management process is fundamental to the successful delivery of the project.
So, standard Risk work item looks like the following:
Let’s go through fields of this work item:
- Title – I’ve got a list of risk titles which are grouped into three categories (client environment, team environment and system complexity). They cover different aspects of risks sources and I use this list as a template to create a list of not filled with other information risks at the start of the project.
- Area, Iteration – standard TFS fields. In my case they help me to link to application and iteration of the project.
- Probability – a percentage indicating the estimated likelihood that the risk will occur. I usually use values 5, 20, 40, 60, 80.
- Assigned to – a person who is responsible for risk response.
- Blocked – we do not use this field.
- Priority – the priority of the risk. Can be 1, 2, 3 (the highest).
- Severity – determines which risks should have a response plan. In our case this values are Critical (for sure) and High (recommended). This field is usually calculated using Probability and Priority fields:
- State – contains the following values: Proposed, Active, Resolved, Closed. I keep risks on Proposed status, put it on Active state when risk occurs and send it on Resolved when we solved it or to Closed when the risk is cancelled.
- Description – what could happen or go wrong? The main core of the risk.
- Mitigation – is filled usually for Critical and High risks and contains instructions how to reduce the probability or consequences of a risk event to an acceptable threshold reducing the expected monetary value of a risk event by reducing the probability of occurrence, reducing the risk event value, or both. They accomplish this via many different means that are specific to the project and the risk. Mitigation steps, although costly and time-consuming, may still be preferable to going forward with the unmitigated risk.
- Triggers – for each risk, we are identifying the triggers or symptoms, to help provide early evidence that the risk is about to occur, or is occurring and define which strategy will be applied to respond to the risk event.
- Contingency Plan – is developed usually for Critical risks and contains the list of actions needed to reduce the likelihood or consequences of impact to the project’s objectives. These plans describe the course of action to take should the risk trigger or symptom occur. Determine the response based on a cost/benefit analysis (cost vs. expected effectiveness);
- Describe the actions to be taken to mitigate the risk;
- Describe the actions to be taken when the risk event occurs (determines which risks should have a contingency plan);
- Assign responsibilities for each agreed upon response;
- Assigned a “due date” where risk responses are time sensitive;
Also we have standard fields that have every work item:
- History tab – contains the list of all changes that were made to the risk.
- Links – links to some documentations, folders, sites.
- Attachments – some additional attachments that can be linked to the risk.
These three tabs are really great, as they give us an advantage over Excel. Excel cannot provide us with these functions and my practice proves that these tabs are very useful.
That’s all I’d like to tell about Project Risk Management and how TFS can help us doing it.