Summary


  • The shorter, detailed planning horizon in the agile planning methodology makes mitigation less attractive than contingency planning.

  • Contingency planning around scope and schedule risks is partially integrated into the overall agile project plan (network diagram) in the form of decision points and pathways.

  • Weighting the many possible project pathways in an agile project is an effective way of prioritizing them, so that you can extend your detailed planning along a particular pathway, if necessary.

  • An environment that implicitly views changes in the primary project plan as negative creates inherent delays in dealing with the issues that prompted the changes.

  • Project course changes should be expected in the agile environment.

Risk Management Workflow

Risk management should be initiated during the tail end of the project planning process, and it should be reassessed periodically throughout the project. There are many benefits to employing a risk management process. They include setting realistic project expectations by maintaining visibility of risks, quicker recovery of problems through previously conceived contingency plans, and lower impact of potential problems through preventive actions. There are four basic parts to the risk management process:

  1. Identify potential risks.

  2. Assess the risks.

  3. Make plans to address the risks.

  4. Reassess the risks throughout the project.

This process is used in conjunction with the risk planning template. An electronic copy of this workflow and template can be downloaded from http://www.xocp.com.

Definition of Risk

Risk

A risk is an unplanned future event that may positively or negatively affect your project. Overall risk is usually quantified as impact times probability. There are also various qualitative adjustment factors that can be used when evaluating risk.
Risk = (Impact x Probability) + Adjustment(s)
While risks are unplanned, they are not necessarily unanticipated. For instance, in the agile network planning approach, you may create a primary pathway, but anticipate events that could occur that would cause deviation from this path. These anticipated events (risks) are reflected as alternate pathways in the network diagram.
A risk is something that may happen in the future. Once the risk actually happens, it becomes an issue and should be addressed appropriately, usually through a contingency plan.


Risks versus issues

Risks are forward looking, while issues are events happening in real time. A risk may, and often does, turn into an issue. However, project managers (PMs) should strive not to let this happen. While the risk event is not officially planned (as part of your WBS and Gantt chart) it has been identified. How else would you know about it? Once identified, PMs should create contingency plans for the risk (i.e., alternate pathways). If this is done, then, when the risk event does happen, it does not turn into an issue. Rather, it triggers the contingency plan, which should address the unplanned risk event.


Identify the Risks

Review project planning outputs

During the initial project planning effort, you may encounter potential problems with the work breakdown structure (WBS), duration estimates, resource estimates, dependencies, constraints, etc. These should be noted and added to the project risk list.


Review project dependencies

Almost all project plans have some dependencies. Review these dependencies and determine if they pose a risk. If yes, then add them to the project risk list. For instance, your staffing may be dependent on the completion of another project (the engineers that you require will be moved to your project when their current project ends next month). Depending on the status and progress of that other project, this dependency may or may not qualify as a project risk.


Unknowns

During the initial project planning effort, you may encounter gaps for which you cannot obtain the necessary information. These gaps or unknowns should be added to the project risk list. For example, if you and your team cannot complete all sections of the project data sheet (PDS), then any omission should be noted as a project risk. The PDS is designed to only include the few core elements required before starting a project. If you are missing one of these core elements, you are at risk.


Lessons learned

Review the lessons learned from previous similar projects. First, try to address these in your project plan. If you cannot address them appropriately, they should be added to your project risk list.


Brainstorming

Identify people with experience on similar projects and lead individual or group brainstorming sessions focused on risk identification. You may start with your current project risk list and ask people to help identify additional potential failures around project schedule, scope, or resources.


Assess the Risks

Risk description

Create a summary description for each item on your project risk list. In many cases, it may be obvious what the risk means, based on the name you have given it on the project risk list. In other cases, it may not. In these latter cases, a brief description will go a long way toward minimizing confusion about the risk. The description should include the potential outcome should the risk occur (see next section). Also, by writing a brief description, you are forced to thoroughly think through the risk, so that you fully understand it. Often people combine two risks into one on the project risk list. Then, when they try to put a description together, they realize that they are dealing with two separate risks.
Enter this information in the description and outcomes column of the risk template.


Risk outcome

Based on your description, determine what will probably happen if the risk event should occur. There are often multiple, possible scenarios that might occur, and, if so, they all should be captured as potential outcomes. Note: The outcome is different from the impact. Outcomes describe qualitatively what will happen because of the risk, while impact describes quantitatively the severity of the risk. (See the risk impact section below.)
Enter this information in the description and outcomes column of the risk template.


Risk impact

For each item on your project risk list, determine the impact to the project if the risk event should occur. You can use rating scales (e.g., High-Medium-Low or a 1–10 scale) to rate the severity of the risk to the project in terms of its effect on project success. The rating should be determined by a group of knowledgeable people who are (ideally) part of the team.
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.




Agile Project Management(c) How to Succeed in the Face of Changing Project Requirements
Agile Project Management: How to Succeed in the Face of Changing Project Requirements
ISBN: 0814471765
EAN: 2147483647
Year: 2006
Pages: 96
Authors: Gary Chin

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net