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.
No comments:
Post a Comment