You have to create the risk strategy for your next project, and your deliverable should be a ‘heat map’ of risks plotted on the ‘impact’ and ‘probability’ aspects. The problem is twofold: first you’ll have to come up with the complete inventory of all possible risks (this work is to be repeated of course, as you’ll never be sure you have all relevant risks on your list – there is no natural ‘stop criterion’ to tell you that you’ve covered all possible or relevant risks.
How not to solve it
You invite your team for a brainstorm session, and you ask the group to come up with risks and to assess the probability and impact of these risks. Using the principle of the ‘wisdom of crowds’, you think that engaging the whole team will enhace the chances of producing an (as much as possible) exhaustive list of possible risks. And also, group wisdom will help you to arrive at a more realistic assessment of probabilities and impacts of these risks.
Why it does not work like you think it would
There are certainly situations where the ‘wisdom of crowds’ is helpful, but this is not one of such situations. Because you’re using the brainstorm approach to both make an inventory and then assess specific qualities of what you’ve inventoried (first the risks list, and then the probability and impact of these risks), the ‘availability bias’ comes into play. This bias means that the ease of bringing examples of X to mind, is then connected to what it is about X that we want to assess. In our case, when we’re judging risk probability, then those risks that come to mind very easily will be judged as having more impact than risks that we find more difficult to ‘retrieve’ into our consciousness. For example, if the risk of running short on resources is easy to come to mind, the group will automatically judge this risk to be quite probable – regardless of actual probability of this risk.
What you should do
Use a structured checklist to find the risks, and not rely only on the memory of participants. Using the checklist to prompt for risks, makes all risks more or less ‘easily’ come to mind for the group, and this then also normalizes their judgement of the probability of these risks. One such structured checklist is discussed here – it is based on a domain model for projects that describes the fundamental ‘elements’ of projects, and relationships between these elements. Risk here is defined as how ‘healthy’ these relationships are.