Member-only story
On Risk Management, Part II: Identify
They say risk is the sword of Damocles hanging over every PM’s head. We can’t ignore it, pretend it’s not there. We can’t put our heads in the sand and hope it will magically vanish. We have to face it, grapple with it, and turn it into an ally, if possible. But before we can face it, we have to find it.
In Part I, we tried to understand what risk means in product management, what types of risk exist, why it is important, and why project/product leaders do not address risk.
Today, we’re pulling out our risk-spotting goggles and embarking on a treasure hunt. A hunt for the lurking risks in our projects, the hidden traps in our plans, the subtle threats in our strategies. We’re setting off on an adventure to learn how we can identify these risks, armed with a map of techniques, each one an invaluable tool in our PM arsenal.
Part II: Strategies for Identifying Risks
While creating your plan, you and your team probably have the “Creative Mode” switched on. While working on risk identification, it is very useful to switch on the “Apocalyptic Mode”.
Imagine that you are at the end of the project and it failed. Why and how could that happen?
Same way goes also for opportunities! How did the project end up earlier? What can we do to achieve this?
1. Project Documentation Analysis:
It’s like unearthing an old diary, filled with scribbles about what we thought, did, and planned. We’re poring over project documents, from project plans to technical specifications, user personas to wireframes. We’re looking for inconsistencies, dependencies, and assumptions that might set off a trap.
Remember that time when the design team assumed the backend would support a feature, but the technical specifications document said otherwise? The resulting delays and rework were a classic risk that could’ve been spotted with careful document scrutiny.
