Writing Actionable Risk Statements

A risk, as defined by the Project Management Institute, is “an uncertain event or condition that, if it occurs, has a positive or negative impact on project objectives.” But, my favorite definition of risk comes from consultant David Hillson: “Uncertainty that matters.” It’s short, memorable, and cuts to the chase.

Another way to look at these definitions is: If the event and consequence are certain to occur, it isn’t a risk, it’s an issue—deal with it, and If the event doesn’t matter to the project, don’t bother treating it as a risk.

Since project management is about trying to accomplish project objectives, risk management is a vital project management discipline. I own several risk management books that describe tools and techniques for risk management, but most are either too theoretical or too simplistic. So, I’ve selected to discuss one technique that I’ve found helpful for documenting risks.

When teams are struggling to identify risk, the most common problem is that people tend to worry about getting too detailed; then they overreact by describing risks too broadly. For example, “Bad things might happen that would make us late” is not a useful risk statement because it is not actionable. An actionable risk statement is one that describes a concern—a situation that exists or may come to exist—and a possible negative consequence.

Well-formed risk statements invite exploration of three types of response:

• Prevention—Actions that reduce the likelihood of either the concern or the consequence
• Impact Reduction—Actions that reduce the negative effect of the consequences
• Detection—Mechanisms to provide early warning or timely detection of the event or consequence, resulting in additional time and options for response

A well-formed risk statement generally follows one of two templates:

1. If <bad thing that may happen> then <negative consequence> might be the result.
2. <Factual statement of existing situation> may lead to <negative consequence>.

The distinction between these two templates is subtle but important. In the first case, the cause has not yet materialized and we may be able to prevent it. It encourages us to ask what we can do to:

• Reduce the likelihood of the bad thing happening
• Reduce the likelihood of or avoid the negative consequence
• Reduce the impact of the negative consequence
• Improve our ability to detect the bad thing
• Improve our ability to detect the negative consequence

The second case asserts that a situation exists, limiting our response to detecting and dealing with the potential consequences. Here we ask, what can we do to:

• Reduce the likelihood of or avoid the negative consequence
• Reduce the impact of the negative consequence
• Change the current situation to decrease the likelihood of the negative consequence
• Improve our ability to detect the negative consequence

Stick to these (or similar) templates when documenting risks, and you will find the discussion of both risks and responses is more focused and effective. I’m happy to answer any questions in the comment section below.

Payson is presenting a tutorial called “Twelve Risks to Enterprise Software Projects—And What to Do about Them” at the Better Software and Agile Development Conference West, June 1-6, 2014.