Decompose for Better Risk Identification

My last couple of ProjectBrief posts have pertained to risk management best practices.  The first post was about the value of articulating risks as events, and my last blog was about including the consequence of risks in the register.  This time, I want to remind people of a PM best practice that lends itself well to identifying risks.

I find that people often struggle with identifying risks.  When you ask team members about the risks they are concerned about, even with all their knowledge and expertise, it’s not always easy for them to think concretely about specific events that can impact the project.  Often, they don’t get much beyond a 50,000 foot view of catastrophic events far out of proportion to the project. “The building burns down” is one favorite example of suggestions I’ve heard when facilitating risk identification.  Or I remember training HR folks at a big bank who worked on projects dealing with bank staffing, hiring, compliance, etc. and they really never got much beyond the risk of bank robberies. Hmmm.  What about project risks related to project staff resources, changing compliance requirements, or maybe teller software, I wondered.

Tools to help team members and others involved in identifying risks should help provide intellectual handles so people can get their feet a little more firmly planted on the ground as it relates to events that will impact their project. It’s the project manager’s job to help people think realistically about possible events that would specifically impact their project budget, schedule, scope, or quality.

It’s never a bad time in project management to use decomposition, and risk identification is no exception.  A risk breakdown structure is just the thing to help pull those identifying risk down to earth.

Rather than jumping straight to the question of “What risks do we have on the project?” first facilitate a decomposition exercise to think about categories of risk. Maybe a key category, for example, would be technology.  Additional decomposition of that category might include sub-categories such as hardware, software, integration, database, and vendors.

As with any decomposition/breakdown structure exercise, sticky notes work great and it doesn’t really matter what it looks like.  Decomposition that’s hands-on is essential.  No moving boxes on a computer screen while everyone watches – get in a room with a white board or find an online tool that allows everyone to contribute.  In addition, I find that something that ends up a little messy typically yields the most useful results.

Once you’ve done some decomposition, use those lowest-level categories as springboards for identifying risk events. You will find it may be a lot easier to get beyond events such as “The building burns down, resulting in…project gets cancelled (presumably)” and identify risk events such as “The vendor’s file versions are not compatible with ours and require conversion, resulting in project delays and compromised data.”

The idea is simply to get people to think about aspects or elements of the project rather than the project in its entirety in order to identify real, project-specific events that are worth investing project time and money in managing.

Not that bank robberies are a good thing, but it may not make sense to use HR project resources to respond to them. I suspect those project managers have quite enough project-specific risks they need to address without having to worry about bank robberies.  Now if they can just think of them!