The “If/ Then” Risk Statement

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.

This entry was posted in Best Practices and tagged , , by Dave Gordon. Bookmark the permalink.

About Dave Gordon

Dave Gordon is a project manager with over twenty five years of experience in implementing human capital management and payroll systems, including SaaS solutions like Workday and premises-based ERP solutions like PeopleSoft and ADP Enterprise. He has an MS in IT with a concentration in project management, and a BS in Business. He also holds the project management professional (PMP) designation, as well as professional designations in human resources (GPHR and SPHR) and in benefits administration (CEBS). In addition to his articles and blog posts, he curates a weekly roundup of articles on project management, and he has authored or contributed to several books on project management.

2 thoughts on “The “If/ Then” Risk Statement

  1. Good article and I agree with your assessment, but there is another template that is necessary. Sometimes the event is certain, but the consequence isn’t. This needs the form:
    “Event has/will occur which MAY lead to consequence”.

  2. Good point, Payson. There are a lot of potential variations within this “if / then” framework. The important thing is to craft a description that can be understood by your intended audience – the decision makers.

    I met with some new customers this week, and just before I left, we spent about an hour going over the risks we had identified during our planning meetings. We were able to quickly conduct our preliminary qualitative analysis and craft several risk responses. They understood both the uncertainty and the consequences, because we were working in the “If / then” format. As we fine-tuned our risk register, it seemed like they were getting excited about the process. Gotta love it!

Comments are closed.