Please login or join to subscribe to this thread
I’ve never heard of minimum numbers of entries when it comes to risk register. Every project is different and the number of risks is dependent on many factors.
Any project bigger than a bread box will have almost an infinite number of risks (positive & negative).
The key is applying Dr. Hillson's definition of "uncertainty that matters" to whittle that number down.
It is possible that the project team had identified lots of risks, but had prioritized the 16 as the ones where active response was warranted and had discarded the others rather than putting them on a watch list.
Replaying my conversation with the PM team on the project, I think the problem is the opposite of what you state. I.e., they didn't whittle down a big list; instead, I think they felt like they didn't really know fully the utility of a risk register, and are doing it more of an exercise than the creation of a useful tool to manage their project. In other words, I don't think they fully grasp the importance of a Risk Register, which means they're probably not taking the ID stage of risks seriously enough. Definitely a topic for discussion with them.... Cheers.
The number of risks is heavily dependent on the risk appetite of the project sponsor who chartered the project.
Some projects are very low risk and virtually a carbon copy of prior work. They utilize resources to generate revenue in a very predictable way. They may not be very innovative, but they pay the bills. Other projects take on new challenges, require great innovation, and have inherently more risk with (hopefully) potential for a greater ROI if things go per plan.
There's also not much point in just creating a list of everything that could possibly go wrong without a plan to manage the risks. Sure an asteroid could hit the office. Are you going to develop a mitigation plan for every existential threat? Spending energy to plan for that contingency is almost certainly a waste so why bother documenting it as a risk. Focus on the things with a great enough probability and impact that your efforts will be meaningful rather than just symbolic.
doing regular project health checks, I observed a wide range of the number and quality of risks documented. This is - for the organization I last did these checks - due to
- lack of many of the PMs understanding the purpose of risk management (especially contractor PMs)
- lack of management understanding the benefits of risk management
When risk management was seen useful it was to communicate risks to the client and/or management so to make them act (kind of cry for help). For example one PM had a risk of lacking a key resource on client side, which resulted in delays of user tests and approvals and hence low progress and risked the Go-Live. He elevated this risk to the next level for 4 months until it was very high and finally the client hired a person for this role. Here risk management was used to put increasing pressure on the client.
Some PMs just fake risks to get to a reasonable number of risk items. Some PMs try hard and come up with 100+ risks, which also is meaningless. Risk identification requires experience and judgement, you do not get those from reading the PMBoK Guide.
So I second Kiron here, for this organization, risk management is not active (=immature).
Working at IBM previously, we had a big risk database with potential risks (per project type) and had to assign probabilities and impacts to those. This led automatically to a risk register and overall risk. You could and would tweak the result anyhow, again it was judgement.
There is no magic to number of risks and I don't think anyone should ever attempt a formula. First, as risks are threats, this first pass of 16 should be valid risks that need to be identified, analyzed, evaluated for likelihood and impact consequence. Once to this point, if these risks have a impact that will justify avoiding, or lessening the possible consequences or likelihood, then you know you have a good set of risks to start your process. A good question to ask in a group setting is are we missing risks other similar projects have encountered. ... Risk identification should also be ongoing. There are various methods however to stimulate risk identification which could also be applied. The number of risk you have must also be manageable and you must have the resources of labor and such to address and take actions on those risks.
Some time back I created a Mind Map for Risk Management. Apparently one cannot attach files to this forum but if you provide me with an email address I can forward a copy in PDF format.
In the risk identification process I usually break it down by project phase and then risk category.
Phases could include: Planning; schematic design; detailed design; procurement; construction/implementation; commissioning; close out; occupancy.
Categories could be:
organizational incl. funding, governance;
project management incl. resource availability, management failure, dysfunctionality;
technical incl. available technology, site conditions;
external including political, stakeholders, market forces, public, force majeure (acts of God).
It is not the quantity of risks that matter it is the quality of the assessment.
The risk register should contain the top ten risk only. In fact, usually, those risk address the 80-20 rule related to imapct.
I can see a rating of identified risks based on probability, impact and exposure subject to project tolerance, say top 10 etc. and actively deal with these but the Risk Manager should have a more complete picture.
Please login or join to reply