Ask someone that has managed a few projects what the “right” number of risk events is to track on a project, and the valid, though academic answer given may be “as many as are required to effectively address the unknown”. My (somewhat cynical) addendum to this response is “that the project team and organization are willing to manage effectively”.
Even though there is no absolute answer that is correct to even a small set of similar projects, there is definitely something to be said for defining guidelines as to how many risks are tracked when an organization starts to adopt consistent PM practices.
With too few risks identified, analyzed and responded to, you leave yourself more exposed to uncertainty. The greater the volume or magnitude of this uncertainty, the greater the likelihood of firefighting consuming a significant percentage of the (limited) resource availability you have for delivering the project’s scope. With too many risks identified, the challenge becomes one of attention dilution – after all, risks are a potential, not a certainty. It is hard enough to get risk response owners to focus on responding to a small set of risk events, and if you drown them in too many, they may simply become numb or turned off to the discipline.
The four key elements that a PM must learn to balance are the complexity of a project, the volume & magnitude of assumptions (another word for uncertainties), the discipline & diligence that the project team (including stakeholders & sponsor) will commit to risk management and the commitment that risk response owners will have executing risk response plans.
You could establish a rule-of-thumb tied to a qualitative evaluation of the complexity of a project – for example, a small project shouldn’t have more than 5 risk events identified, while a large or highly complex one could have up to 15. While this is not an ideal approach, it can help to “effort box” risk management activities until the discipline matures within the organization.
Another approach is to evaluate a project’s overall risk using risk factors – these are generic sources of risk that will affect a project to greater or lesser degrees. During initiation or even high-level planning, risk factor scores can be determined and the magnitude of these scores could help to guide how many risk events are identified for a project.
Regardless of what approach is taken, consistency is important since it is the only way to get useful feedback which in turn will help to improve the effectiveness of the discipline.
Easy in theory, difficult in practice 
Pingback: Tweets that mention What is the “right” number of project risks? « Easy in theory, difficult in practice -- Topsy.com
Many times there is confusion between risks and issues. The right number of risks is the number of “things” that will cause the project to fail that you don’t currently have a solution for. You don’t have the solution, because the risk is unknown. If it was known it would be an issue and you’d have a solution.
By the way assumptions are NOT unceratinties. Assumptions are the boundary conditions of the project.
I’d suggest you read some Risk Management guidance from domains where Risk Management is very mature. US DoD, US Department of Energy, US FDA. Places like that have mature risk management processes, handbooks, and process guides.
And best of all buy and read Ed Conrow’s, Risk Management book, http://www.risk-services.com/aiaabok1.htm
This will guide you in the proper development of risk management strategies and move you way for the approach taken here – and reveal that the approach of asking “how many risks are the right number” is a risk in itself.
LikeLike
Hi Glen –
thanks for your feedback!
Most of the clients I deal with are at a low PM maturity with risk management being the worst practiced knowledge area, hence the suggestions I made in the article were aimed at similar low maturity organizations who would be unable to institutionalize mature practices in a short term.
I’m not sure that I completely agree with the statement about assumptions – I’ve found that assumptions are what tend to generate significant uncertainty to projects – the obvious risk events stemming from scope, resources or other constraints tend to be addressed or identified fairly early on, but assumptions that get made by key project participants often tend to not get documented, validated, assessed or challenged and if proven invalid, can negatively impact the project. IMHO, all significant assumptions should be evaluated to see what the impact would be if they are proven wrong.
Thanks again for the feedback!
Kiron
LikeLike