Menu

The Way You Describe a Risk Is What Makes It Manageable

BloggingAllianceButton

Project managers know that risk management is an ongoing process, and risk identification happens throughout the project life cycle. In many projects, the team is empowered to draft risk log entries. 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. If you’ve ever seen a risk log entry like “Database” with little or no explanation from the person who logged it, you already understand why the project team needs some guidance.

The If / Then Risk Statement

To that end, I include a short explanation in every project kickoff where I explain how to document risks as “if / then” statements, in the following format:

IF [Event], THEN [Consequences].

I begin by defining a risk as “an uncertainty that matters.” 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 like this:

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.

Qualitative Risk Analysis

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. Using this example:

  • 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 Event 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? If resources are available, this strategy 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 slip in the schedule 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, if your data conversion and cutover strategy requires the new payroll system to be rolled out at the beginning of a calendar 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.

Based on this analysis, it is possible to estimate the incremental cost of the Event, at each probable delay. This assessment could then be used to drive whether to transfer or mitigate the risk, based on the cost of each strategy, or to accept the risk, without attempting to reduce the likelihood of it occurring.

Communicating an Easily Understood Risk

As you can see, a well-constructed risk statement will make your risk analysis much easier, and allow your analysis to be better understood. And an easily understood risk is obviously easier to explain to the project team, the sponsor, stakeholders, and the management chain. Never underestimate the value-add of communicating project risks to a wide audience, or the potential for loss of support if they don’t understand what you tell them.

 

For more brilliant insights, check out Dave’s blog: The Practicing IT Project Manager

About Dave Gordon

Dave Gordon is a project manager with over twenty years of experience in implementing human capital management and payroll systems, including premises-based ERP solutions, like PeopleSoft and ADP Enterprise, and SaaS solutions, like Workday. 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. You can view his blog at The Practicing IT Project Manager by clicking the button below.

Check Also

Easy Ways to Reenergize Your Meetings

There are enough bad meetings in the universe that you would probably be hailed as …

Leave a Reply

Your email address will not be published. Required fields are marked *