As I mentioned in my previous post, Risk Buffers – An Example, this post is dedicated to identifying risks. The only real way to find risks is by experience, and if you don’t have the experience yourself, then you must rely on the experience of others. I’ll discuss three reliable sources for finding risks (but this is not exhaustive).
A taxonomy is a schema for classifying things. The library’s Dewey Decimal System and the Species-Genus-Phyla (or whatever it is) system that biologists use for classifying animals are both taxonomies. Risk taxonomies have been developed for classifying and organizing risks. Since the taxonomy is exhaustive, the beneficial aspect of this is that you can then use these risk taxonomies to make sure you consider all areas of risk.For IT and service projects, the Software Engineering Institute’s (SEI’s) Capability Maturity Model (CMM) developed a risk taxonomy (tr06.93.pdf – Taxonomy-based Risk Identification) twenty years ago that is still applicable. I have Appendix page A-1 with me on every project and refer to it often. For each entry, I ask the question: Are there any xxx risks? For example, for requirements stability, I ask: Are the requirements stable? Other industries have appropriate risk taxonomies available via the popular search engines.
These risk taxonomies are appropriate for finding product and service delivery risks, but not optimized for finding project delivery risks. For that, PMI’s Organizational Project Management Maturity Model (OPM3) is a better source for identifying risks, though it’s cumbersome. Basically, areas where the organization is not mature for project management are opportunities for risk.These taxonomies and maturity models are sources from other’s experiences to help identify sources of risk projects in general. Getting specific to your project, another useful technique for identifying risks (opportunities and threats), is work with your team or task owners and go through the WBS at a Deliverable, Activity, or Task level and ask them to estimate the Optimistic, Most Likely, and Pessimistic schedule for each. It’s really amusing that I can ask the project team if they can identify any risks and they’ll consistently say “No.” But they can confidently give me O, ML, and P estimates, then I follow up with: What about the Pessimistic estimate can make this be late (or what has to happen for us to achieve the Optimistic estimate)? Then, they can give me both threats and opportunities. Amazing.
Finally, a reliable source of risk that you never want to miss is your assumptions. An assumption can be defined as a risk without an owner. Project estimating assumptions, task estimating assumptions, all assumptions need to be formalized and documented in the risk register.In the previous post with the example risks, did you notice anything special about “risks” #3 and #4?
3. Ice could be so bad that your office closes for the day
4. You are low on gas and need to refill before you can make it all the way to work
Did you recognize that neither of these are risks? I’m being somewhat pedagogical to demonstrate my point here, but to complete our task, you have to go into the office. For “risk” #3, since the office is closed, you can’t complete the task. Part of the definition of a risk is that you have to be able to “control” the risk (mitigate, avoid, transfer or accept). This is why civilization-destroying asteroid collisions are not project risks. For “risk” #4, this is not a “might happen in the future.” It exists and must be dealt with, so it is not a risk, it is an issue.To summarize my comments from today’s post:
· Use taxonomies and maturity models to identify sources of risk
· Look for Product/ Service risks
· Look for Project Delivery risks
· Use your project team to identify risks (opportunities and threats)
· Formalize assumptions into risks
Do you have suggestions or techniques for finding risks?
© 2013 Chuck Morton. All Rights Reserved.