Risk Management for Product Managers – Part One

Share This Post

You’ve probably heard about risk management before. It’s that thing the project team or project manager goes through at the beginning of the project and then forgets about, right? Well, hopefully not. Good risk management is something that needs to happen throughout the entire project lifecycle. Product Managers are in an excellent position to offer unique insight into project risk. In this post I’ll define risk and briefly discuss a process for risk management. In my next post I’ll examine some common risks from a requirements perspective.

A general definition of risk is the possibility of suffering a negative impact to the project, whether it be decreased quality, delayed completion, increased costs, or project failure. The flip side of risks are opportunities, which you can think of as potential impacts to the project than can improve quality, speed up completion, decrease costs, or otherwise increase the chance of project success.

In general risk management approaches are cyclical in nature. Here is the cycle I usually follow:

During risk identification potential sources of risk and potential risk events are developed. There are many sources for risk, so consider things like previous projects/lessons learned, input from team members and stakeholders, audits/reviews, status reports, scope change requests, etc…

During risk analysis, each risk should be analyzed for the probability that the risk will occur, and the impact if it does. Impacts can be measured quantitatively or qualitative – whichever method you select, be as precise as possible.

During response planning, strategies and plans are developed to minimize the effects of the risk to a point where the risk can be controlled and managed. Higher priority risks should receive more attention during response planning than lower priority risks. Every risk threat should be assigned an owner during response planning. Common methods for responding to risks include avoidance, transference, mitigation, or acceptance.

Risk monitoring is the part that many projects forget to do. It includes: looking for new or changed risks, tracking identified risks to see if they have occurred yet, reviewing the effectiveness of the execution of risk responses, and ensuring that proper risk management policies and procedures are being followed.

More To Explore

Visuals in Requirements Mapping

In Praise of Requirements Mapping

Learn how to tie software requirements together with visual models and other artifacts created during the analysis process.

It’s a Matter of Trust

The combination of pandemic and moving to a rural community has increased the amount of shopping I do online, but even before those events I found myself depending more and