by Mark Kromer

I am starting a new series on risks & alternatives in all areas that I focus on for this blog: product, project & program management, within the context of software technology. In all of those areas the first thing to do is to perform exercises and common practices that lead to identification both of potential risks and then viable alternatives. Mitigation, plans and analysis will come later and I’ll touch on those in the next parts of the series.

In a project, a risk is an event that can negatively (or positively, according to PMI) effect the outcome of your project. In products, a risk is similar but is more of a business case item such as those that are captured through market research in a SWOT analysis or in a cost/benefit scenario. And program management would cover risks from a resource or investment perspective.

In all cases, identifying alternatives is key to mitigating risks and to identifying the risks associated with not just the current strategy, but alternative strategies as well so that your stakeholders and decision-makers are given the best tools, outlooks and data to make the right decision on project, products or programs.

For project managers, PMI recommends using an RBS or risk breakdown structure to list out risks for projects and they also list many different techniques for what is one of the most difficult exercises in risk identification, which is getting all of the risks from the stakeholders, project members, etc. The usual techniques are brainstorming, interviews and virtual meetings with or without anonymity. As a PM, it is your responsible to figure out which technique works bets for the product, project, program and audience.

For a couple of rules of thumb here is what I have found in practice:

1. On small projects, risks can be identified well with SME interviews.
2. On large complex projects, a mix of techniques will likely be needed to be most effective including group techniques like Delphi.
3. I have not found that brainstorming works well with risk identification. It works well with initial requirements and idea gathering. But what happens sometimes in brainstorming risks, is that the unstructured format does not lend itself well to following through potential risk paths and mitigation.
4. Risks must be documented and followed-through throughout the lifecycle. For projects, I recommend a risk register and for product & program management, I like using business case documents with alternatives decomposed into costs & ROI.

No matter how you decide to approach this first initial step of risk identification, you must be certain that this is an on-going repeated process. You are not likely to identify all risks and alternatives up-front. And you are likely going to have to work hard to pry the information out of the teams. So research your topics for your product or project and make sure that the risk register, business case, or whatever format you use to track risks & alternatives is constantly updated and validated.