Enter this information in the impact column of the risk table.
* * *
Risk probability
For each item on your project risk list, determine the probability that the risk will actually occur. Again, you can use rating scales (e.g., High-Medium-Low or 1–10) to rate the probability of occurrence.
Enter this information in the probability column of the risk template.
* * *
Risk detection (adjustment)
Since the basic R = I × P model can’t possible capture all of the nuances of a particular project situation, it is common to add a qualitative adjustment factor to the risk ordering. Detection is a good adjustment factor. Essentially, you want to determine if advance detection of the risk will be easy, hard, or, perhaps, impossible. Using detection as an adjustment factor may also have the side benefit of helping you devise specific detection mechanisms to use during project execution. I like to use a −1, 0, +1 adjustment, but you could use 1–10 or another scale also. If you use detection as a risk-quantifying factor, the equation becomes:
Risk = Impact x Probability + Detection Adj.
Note: This step is optional. Enter this information in the detection adjustment column of the risk template.
* * *
Qualitative adjustments
The most efficient and effective adjustment often just uses professional judgment (brainstorming with your core team) to determine an adjustment. During this process, keep in mind that you need to find the High-High or High-Medium risks first. The primary goal here is to add or subtract points to break ties in the overall risk score so that a clearer prioritization can be determined. Stay focused on the top part of your list until you are comfortable with the relative ordering, then you can move on to bottom of the list. You should use the same scale as for the detection adjustment (i.e. 1, 0, 1). If you use a qualitative risk adjustment factor, the equation becomes:
Risk = Impact × Probability + Detection Adj. + Qualitative Adj.
Note: This step is optional. Enter this information in the qualitative adjustment column of the risk template.
* * *
Prioritization
As mentioned previously, overall risk is usually quantified as impact times probability (I × P) plus adjustment factors. Based on your team’s assessment of each risk’s impact, probability, and adjustments, you should be able to put them in rank order with the High Impact, High Probability risks at the top. I suggest that you don’t spend a lot of time trying to get the bottom half of the list in exact priority order. There are more quantitative risk models that can be used to get a better ordering, but they require more inputs. This simplistic model will usually identify the big risks pretty well.
Order the risks in the risk table from highest to lowest (top to bottom).
* * *
Make Plans to Address the Risks
Identify risks to manage
Since you can only spend so much time focused on risks, you need to determine which ones you will manage and which ones you won’t. This is usually the same as the top-priority risks that you previously identified, but not always. For example, it may be very easy to address some low-priority risks, so you decide to take care of them. It may be incredibly difficult to address a high-priority risk, so you determine that it is not worth spending the energy to address it. Whether or not a risk is addressed should be a conscious decision by the PM. By not addressing an identified risk you are, in fact, accepting it. PMs should document all risks that are accepted so that it does not appear that they were merely forgotten or missed all together.
Indicate acceptance of a risk in the mitigation/contingency plan section of the risk template.
* * *
Mitigation plans
Mitigation can be thought of as doing extra project work in an effort to prevent the risk event from occurring. This is an effective way to address a risk, assuming the benefits (of preventing the risk) outweigh the added costs of the mitigation.
Crafting a mitigation involves understanding the root cause of the risk, brainstorming potential ways to prevent the risk, and then breaking them down into WBS elements and individual tasks that can be added to the detailed project plan.
When optimizing your overall project schedule, mitigation plans often end up on the chopping block as a way to save time and resources. By eliminating a valid mitigation plan, you are essentially accepting the risk, or taking a gamble that the risk will not occur. You may win, or you may lose. This is okay, but again, it should be a conscious PM decision weighed against other possible optimization alternatives.
Describe any mitigation plans in the mitigation/contingency section of the risk template.
* * *
Contingency plans
Contingency plans are subsets of the overall project plans that only get used if the specific risk event does occur. The objective of a contingency plan is to rapidly neutralize the impact of a risk event on your project. Contingency plans should be created using the same process and thought that goes into creating any project plan. Contingency plans for high-priority risks can be just as important as the primary project plan.
After your overall project plan has been optimized, identify your top-priority risks that do not have mitigation plans. You should create contingency plans for these risks. Also, if you have any high-priority risks with mitigation plans, but you are still uncertain of their potential success, then these should also have contingency plans.
Describe any contingency plans in the mitigation/ contingency section of the risk template, and depict the contingency as an alternate pathway on the project network diagram.
* * *
Triggers
Identify a triggering event for each contingency-managed risk. Once the trigger occurs, the contingency plan is initiated. Like a detection event, triggering events should be watched for by the PM during the project execution.
* * *
Reassess the Risks During the Project Execution
Top risk list
Maintain a current list of the highest-priority risks and distribute it with your regular project status reports (see Appendix A for an example of a Project Status Reporting template and workflow). Use this list as a means to regularly communicate top risks, their consequences, and the current mitigation/contingency strategy. This is an excellent way to keep risks visible to the team and management so that they are not forgotten. It also tends to keep people thinking of new and better ways to address the risks. A mitigation or contingency plan that was not obvious at the start may become apparent midway through the project.
* * *
Periodic review
Once a quarter is usually a good schedule to set for formally reviewing your project risks in detail. However, you should determine a period that is appropriate for your project. Use the same basic process described in this document, with the exception of eliminating risks that are associated with activities that have already been completed.
* * *
Integration
Status reporting
A summary of the top risks captured in this process should be integrated into the project’s periodic status reports.
* * *
Action items
A risk is not a task or an action item. However, as part of your mitigation or contingency plan, one or more action items or tasks may be assigned. These should be added to the project Gantt chart or action item list. The over-reaching risk should remain on this list. Specific cross-references can be tagged on the Gantt chart, action items list, and risk list, if desired.
* * *
Template for Risk Planning
[Project Name] Risks
Risk description and potential outcome
Impact (H-M-L)
Probability (H-M-L)
Detection adjustment (−1, 0, + 1)
Qualitative adjustment (−1, 0 + 1)
Description of mitigation/contingency plan and triggers
Risk #1
M
H
−1
Enter description here.
Risk #2
M
L
0
Enter description here.
Chapter 9: Management—Creating an Environment of Agility
Overview
Agile project management is about deftly managing the change in requirements associated with project uncertainty, so that it becomes a positive force for both the project and the business, rather than a negative one. The project manager guides the team through the changes necessary to bring the project to a successful completion. The individual team members execute the activities that bring about successful course changes. Now, it is up to management to create an environment that will nourish the seeds of change and creativity, rather than crushing or stifling them.
Creating an environment that is supportive of change is not easy, especially when you consider that management must balance the project needs against the longer-term business planning needs, which are generally rooted in predictability. The stability and certainty, which is so often strived for in classic project management, is a perfect match for long-term business planning. Replacing that predictability with the controlled chaos of the agile project can be unnerving for most managers. Yet, continuing to employ classic methods in an agile environment will likely result in the same loss of predictability—and perhaps something worse.