An international standard for being scared?

I sometimes quote ISO90210 (not a real standard) to represent a common approach that, while often used, is not a formally recognised standard.  It is more a common but informal way people approach something.

In this case I am looking at how to be scared. 

Apparently there is a standard approach to being scared that inolves the amygdalae in our brain and us cheking our big catalogue of things to be scared of when any event happens. But that is a biological response and I am more interested here in a project management response.

So here is where I start – the ISO90210 standard for being scared at the start of a project (or halfway through):

1. For both Product risk and project risk (see below for the definitions), write down a list of:
• What could go wrong?
• What would cause it?
• When and how would we find out?
• What would happen after we found out?
2. Once you have a long list, review the list and look for patterns:
• Are any 2 things symptoms of the same underlying cause or event?
• Do several bad things result in a similar bad outcome?
• What is the level of risk outrage – ie how pissed off would the stakeholders be with each, regardless of how bad or mild it really is?
• Ask yourself – If one or two of these did happen, which ones would they be?
• Ask yourself – If there is one thing we know we should deal with, but probably won’t, what would it be?
3. Consolidate your list into the top three (or 1 or 5):
• Which 3 things should we be the most worried about?
• Why them in particular?

 Then you have a consolidated list of what you should be the most scared of. The final steps are:

1. Compare your list to what others came up with; and
2. Discuss what we should do about the combined list of concerns.

Note – it is worth looking at both product risk and process risk:

• Product risk is the risk that we will deliver the project but that the product we deliver will not do what we want (it will fail to meet expectations or do unwanted things). For example it might not sell or it might canabalise demand for another product; and
• Process risk (or project risk) is the risk the project won’t deliver the product we have asked for when we want it. Examples include too many bugs, a restructure impacting the team and so forth.

At least if you are going to be scared (which you should be on every project), you can now do it properly.