Simply identifying the risks facing a project is not enough. We need to write them down in a way that lets us communicate the nature and status of risks throughout the affected stakeholder community over the duration of the project. Figure 6-3 shows a form I’ve found to be convenient for documenting risks. It’s a good idea to keep the risk list itself separate from the risk management plan, as you’ll be updating the risk list frequently throughout the project.
Use a condition-consequence format when documenting risk statements. That is, state the risk situation (the condition) that you are concerned about, followed by at least one potential adverse outcome (the consequence) if that risk should turn into a problem. Often, people suggesting risks state only the condition—"The customers don’t agree on the product requirements"—or the consequence—"We can only satisfy one of our major customers." Pull those together into the condition-consequence structure: "The customers don’t agree on the pr oduct requirements, so we’ll only be able to satisfy one of our major customers." This statement doesn’t describe a certain future, just a possible outcome that could harm the project if the condition isn’t addressed.
Keep the items that have high risk exposures at the top of your priority list. You can’t address every risk item, so use this prioritization mechanism to learn where to focus your risk control energy. Set goals for determining when each risk item has been satisfactorily controlled. Your mitigation strategies for some items may focus on reducing the probability, whereas the approach for other risks could emphasize reducing the potential loss or impact.
The cell in the form labeled Mitigation Approaches allows you to identify the actions you intend to take to keep the risk item under control. With any luck, some of your mitigation approaches will attack multiple risk factors. For example, one group with which I worked identified several risks related to failures of components of their Web delivery infrastructure (servers, firewall, e-mail interface, and so forth). A mitigation strategy that addressed several of those risks was to implement an automated monitoring system that could check the status of the servers and communication functions periodically and alert the team to any failures.
Figure 6-4 illustrates an alternative template for your risk list, which is also included in the process assets on the Web site that accompanies this book. This format includes essentially the same information that’s in Figure 6-3 but it is laid out in a way that is amenable to storing in a spreadsheet or a table in a word-processing document. Storing the risks in a table or spreadsheet facilitates sorting the risk list by descending risk exposure.