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!
How do you define success for your team? Take a moment to think about this…
Remote work has transformed how organizations operate, with virtual teams becoming the new normal across…
Effective leadership has never been more critical. Whether managing a team in a high-pressure corporate…
Remote work has transformed how organizations operate, with virtual teams becoming the new normal across…
The Business Analysis Body of Knowledge (BABOK® Guide v3) is a comprehensive guide to the…
A certified Business Analyst (BA) has successfully passed an International Institute of Business Analysis (IIBA.org)…
View Comments
"The building burns down... but it won't matter because by that time we'll have outsourced the service so production won't stop."
I've read your three recent articles on risk management, and I was wondering what you think about "perishable" risks, i.e. the notion that some risks are only valid during a certain period or phase of the project, after which we'd be "in the clear". As the #1 laziest project manager (portfolio manager now, actually), I don't like tracking things I don't absolutely have to, and it seems to me a good approach in order to keep the risk register clear of clutter and only containing pertinent information. What are your thoughts?
I'm with you on the tracking comment. I don't even like tracking things I do absolutely have to! As for "perishable" risks, it seems to me that many, if not most, risks are only valid during a certain period or phase of the project. That's why it's key to keep the register fresh by making sure it’s reviewed regularly. What often happens is that PMs get really excited about creating a great risk register early in the project and then put it on a shelf somewhere to collect dust for the rest of the project. For the reason you suggest, however, we need to revisit the register on a regular basis because it will change. For example, perhaps there was a risk around a piece of equipment that we're no longer using. The probability of that happening will change to zero and we can take that one off the list. Or maybe we just started using a new piece of equipment that poses a risk we hadn't needed to consider until now. It will need to be added to the list. Best practice would suggest that review of the risk register be a standing item on the weekly team meeting agenda. That's how we are able to keep it fresh and the information pertinent. In the example you gave, reviewing the risks would give us the opportunity to decrease the impact of building burning down to zero after outsourcing the service, which will result in a revised risk score that will drop that event to the bottom of the list and take it off the tracking radar. Of course, regular review probably also means that other risks will now require tracking that maybe we weren't before - but at least we're focused on the ones that really matter at the time. Hope that makes sense. Thanks so much for the comment!