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.
In the agile environment, we don’t expect to stay with the original plan for the course of the project. We expect that the primary plan will point us in the right direction, but that course changes will be required to navigate the uncertain landscape (see Figure 8-4). Thus, when the project manager executes a contingency plan (i.e., diverts from the primary pathway), management is not surprised. There is more support, there is less questioning, and there is minimal delay in approving these key decisions.
Figure 8-4: Project course changes in an agile versus classic environment.
In most companies, major project changes are a blood pressure– raising exercise that is frowned upon. Since there is a negative connotation associated with these course changes, project managers, sponsors, and technical leaders alike are reluctant to champion them until it’s too late. When these course changes do get under way, they’re usually frantic and frustrating for the project team, creating more incentive to sweep the next one under the proverbial rug. It is for all of these reasons that course changes on projects are usually not as effective as they could be. To be successful, we need to break away from the stigma that change is bad, or is the result of bad planning. Creating, communicating, and discussing appropriate risk management plans is an effective way to do this. Creating them demonstrates a forward-looking project management perspective. Communicating them tends to pull in the interested stakeholders. And discussing them generates the energy and support necessary to make the plans happen.
Agile Strategy Keep your team looking forward by working with them to develop network diagram–based contingency plans, and then communicate and discuss these with both your team and external stakeholders.
Agile PM calls for any number of possible business scenarios to be put in front of the project manager. As discussed previously in Chapter 3, you need to make the project the business. Visualize the benefits of getting to market first and the downfalls of coming in second. Let the project manager combine her intimate knowledge of the project with the business realities, and let her imagine how she will lead the team and company to success, including how she will manage risk. Encourage the use of appropriate mitigation and contingency planning. Get management sign-off on the risk pathways, and let the project manager run with them. Finally, try to remove the attitude roadblocks associated with making changes to the primary plan.
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:
Identify potential risks.
Assess the risks.
Make plans to address the risks.
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.