Risk identification is our first step towards converting unknown-unknowns to known-unknowns. It is neither possible nor advisable to identify all risks which could impact your project’s objectives – like any other project planning process, too much is as bad as too little. But how do we know that we’ve done enough risk identification?
To increase confidence that we’ve identified a reasonable set of risks, we should lift a page out of good estimation practices by utilizing multiple methods. I’m not encouraging you to pull out your copy of the PMBOK® Guide, flip to Chapter 11, and use each of the inputs, tools & techniques from the Identify Risks process but there is a benefit in looking beyond those tried & true friends, the scope baseline and expert judgment.
From the day you learn about a project, assumptions are made by you, your team and key stakeholders which will affect planning and execution outcomes. An effective project manager is an inquiring project manager. When estimates are elicited, designs get drafted and resources get reserved we should always ask what assumptions were made as well as what the impact will be if those assumptions are proven to be invalid. Key assumptions should be placed on a watch-list so that they can be periodically revisited and proactively validated.
If your company has mature retrospective practices, a quick review of a lessons repository might help to identify risks which had been missed. But what if lessons learned is an oxymoron in your company? In that case, exploit your network and request the historical issue logs from recent projects which appear to have any key areas of commonality with your project. Such overlaps could include scope elements, technology components, or delivery partners. While the majority of the issues might not be relevant to your project, the vital few might not only help you identify new risks but might also provide some useful empirical data to support quantitative risk analysis.
Your project likely has dependencies on activities or resources from other projects. While your team might have identified delays to these key external dependencies as risks, have you taken the time to look at the macro-level changes within and outside of your company? Why not meet with the keepers of your company’s enterprise and portfolio risk registers to identify any threats or opportunities within those repositories which could impact your project?
Juliette Binoche could have been speaking about risk identification rather than acting when she said “Acting is like peeling an onion. You have to peel away each layer to reveal another.”