Considering and assessing risk—meaning, all the things that can go wrong in a project—is understandably scary. In a web redesign, for example, thinking ahead and saying out loud, “What if this content doesn’t migrate the way we planned?” or “What if our most important stakeholder expects a feature we didn’t know about?” can feel like setting ourselves up for failure.
A traditional risk assessment tends to lag the realities and miss important perspectives because of the time and expertise it requires to update it. It is also usually based on expert opinion since more a thorough risk assessment requires data that takes time to gather if it can be gathered at all, and expensive statistical expertise to properly analyze and interpret the results. I’ll admit the outputs of a traditional risk assessment can feel satisfying; numbers seem scientific and give us a comforting sense of accuracy. It’s a false comfort, though—interpretation and even insight gathering are still susceptible to bias.
Why bother talking about risks then?
You might think, if we are so frequently wrong about how risky things are and how confident we can be in our assessment, then why articulate risk at all? Because, when done well, risk assessment serves some much-needed purposes. It helps us:
- Know what to look out for
- Determine how much energy to put into prevention or contingency planning
- Build shared language and normalize talking about risk—this makes it less charged or scary
- Get the whole team looking ahead, communicating about risks, and actively mitigating them
What level of detail is really needed to meet those goals? Not much, really. In fact, the simpler, the better! Simpler is more approachable to a wider variety of team members, meaning you gain greater insights from more perspectives and areas of expertise. A simple framework is also nimble, giving you the ability to revise and adapt. You want just enough information to identify actions and decision points, or to identify an area where more rigor might be warranted.
Simple, working framework
To that end, I have found success using the following lightweight framework. I developed this based on a conversation I had with friends in 2017.
Here is a quick example of a few risks articulated using this framework, explained in greater detail below. Some of this may look familiar to more traditional risk tracking frameworks.
Not releasing on time for any reason
|Quicksand||Moderate||Regularly checking in on upcoming activities, vacations, and meetings – collaboratively managing the schedule and scheduling. Articulating impacts of delays when they are considered. Keeping the gantt chart updated. Avoid custom code where possible; start with a simplest-first approach and add complexity judiciously. Share “sneak peaks” of deliverables wherever possible.|
|Unavailability of key staff Or Turnover|
Key project stakeholders or staff leave.
|Earthquake or Hurricane||High||Clear communication of upcoming touchpoints, meetings, and activities needed from key staff ensures critical team members have an understudy. Use [tool] for all project communications, so nothing is lost/locked in someone’s email. Document key decisions as we go.|
First, simply articulate the risk. Don’t go into great detail, but use language that everyone on the team will understand.
Class: Fires, Quicksand, Hurricanes, Earthquakes
This is the biggest difference from other risk articulation frameworks. Rather than noting the likelihood, look at whether we can see a risk coming.
- Fire = Something that is currently causing harm and will likely grow if left unchecked.
- Quicksand = Something with a slow-building, cumulative effect.
- Hurricane = Something that can be seen coming, but is not yet causing harm.
- Earthquake = Something that may happen and will hit without warning if it does.
Remember: A risk can change categories over its lifecycle. Once a hurricane or earthquake hits, for example, it becomes a fire. Also, the class of risk and the impact of the risk are unrelated! You can have a low-impact fire and a high-impact hurricane, or vice versa.
In other words, how much damage could this risk cause? How much should we care about it, really? Choose from low, medium, or high. Embrace the fact that this is a judgment call and a bit squishy.
What can we do to ensure we notice if this risk is materializing? What can we do to make it less likely to happen?
More about the Risk Classes
As the most unique aspect of the framework, let’s dig in a little more to understand the specific implications of Fires, Quicksand, Hurricanes, and Earthquakes. These terms may take some socializing—team members may forget the nuance between a Hurricane and an Earthquake at first, but over time I find they become a useful shorthand
- Fires often blind us to more impactful risks. It is very easy to ignore the other classes of risks and only tackle the fires since they are obvious and demand your attention now. The other three are quiet and sneak up on you. Another dimension to this; our society celebrates heroism (firefighting) but does not celebrate the quiet work that prevents the necessity for heroism (the people who, say, install smoke detectors or inspect the sprinkler system). It is always cheaper and easier to prevent fires than to recover from them.
- Quicksand sneaks up on you. It’s often deprioritized even when you can feel the project going off course. Like quicksand, even though the risk is causing harm now, we often don’t do anything until we’re up to our necks and can’t do much about it.
- Plan for Hurricanes. Think of hurricanes the way you would an upcoming launch or major event; a bit of forward-looking planning and open communications—plus a contingency plan—can let your project team roll right through a hurricane. You just need to make sure folks know how to batten down the hatches when the hurricane hits; and are keeping an eye out for it.
- Be judicious about Earthquakes. They’re the easiest to ignore—but can hit the hardest. Carefully consider the appropriate level of effort here—should you just look at post-earthquake care (aka a contingency plan)? Or look at earthquake-proofing your project?
By using more familiar, less numeric scales, this framework is faster for most folks to work with and doesn’t give a false sense of confidence. It invites more participation, which leads to a more risk-aware and adaptive team.
Let us know how it goes!
This is a relatively new risk articulation framework; I would love any and all feedback or suggestions on how to make this more useful.