Project managers know that risk management is an ongoing process, and risk identification happens throughout the project life cycle. Of course, one of the basic requirements in identifying project risks is describing each risk in such a way that it is meaningful to management and other stakeholders who aren’t part of the project team. To that end, a common practice is to document risks as “If / then” statements, in the following format:
IF [Event], THEN [Consequences].
You may remember the definition of a risk as “An uncertainty that matters.” In this case, the Event is the uncertainty, and the Consequences are why it matters. The risk statement relates the Consequences to the Event. As an example, let’s say an interface is being built that will pass “hours worked” for each employee from the timekeeping system to the payroll system. Obviously, the hours worked is a critical input in order to calculate payroll for those employees who are paid by the hour. For this reason, the interface must be developed, and testing completed, before payroll system testing can begin. A risk statement that describes this dependent relationship might be written as:
IF the interface from timekeeping to payroll is not completely tested prior to the beginning of payroll system testing,
THEN payroll system testing will experience a day-for-day schedule slip.
This sentence structure is preferred because it facilitates a qualitative risk analysis. Articulating the Event so specifically makes it easier to determine the probability that it will occur. It’s also easier to visualize, making it easier to identify risk response strategies. Can the risk be avoided, by moving the interface out of scope? Probably not, since it’s so critical to the payroll system. Can the risk be transferred, by having a third party develop the interface? Yes, but unless they are significantly more experienced in this specific task, the probability of the occurrence may be the same. Can the risk be mitigated, by making the development and testing a higher priority for the team, and assigning resources to assist with preparing test data and evaluating the output of the interface process? Probably, because that should reduce the probability of the Event occurring.
Articulating the Consequences helps to assess the impact of the Event, in terms meaningful to the project. For example, a schedule slip of up to two days in the start of payroll system testing might be within the schedule reserve, but more than that would delay the beginning of parallel testing. This would force the go-live date to be moved out three months, since a new payroll system can only be rolled out at the beginning of a new quarter. Thus, the impact of a delay of two days would be negligible, but any more than that would impact the delivery of the payroll system by three months. From this, it is possible to estimate the additional cost of the Event, at each probable delay. This assessment could then be used to drive whether to mitigate the risk, based on the cost of the mitigation approach under consideration, or accept the risk, without attempting to reduce the likelihood of it occurring.
As you can see, a well-constructed risk statement will make your other risk management chores easier. It’s also makes it easier to explain the risks you’re managing to the project sponsor, stakeholders, and management.