What’s the risk of not addressing a risk?  What happens on a project when a risk is identified and not addressed/mitigated?    There may be reasons not to correct it, e.g low probability of occurrence and minimal impact,  but how do we document and track this decision?  And if we’re delaying an implementation how do we insure the risk is addressed at a later date, e.g. next version release?   How do we insure that if an audit takes place the project team can clearly explain the reasons for the decision?  Is this even acceptable?

We spend so much of our time looking at risk, its potential impact and how we can mitigate it, is there a time when it is acceptable to note a risk and then move on without addressing it?  Certainly,  if is low impact/probability and the mitigation required will take longer and cost more than the risk then it can be acceptable to document the risk, the results of the analysis,  and the decision to take action at a later date.  This should be documented in the project’s Risk Management Plan.  We also have to acknowledge that in some cases when we say later, can end up be never depending on the products future.

So if a risk falls in the white, green or yellow risk areas on the sample risk chart below – we can likely justify taking no action.

We will need to document the reasons we decided not to address an identified risk and also make sure that we include any analysis for risks in the minor and moderate categories.  As mentioned earlier these results should be included in the project Risk Management Plan. The details can be documented in an internal memo/design decision memo/etc, but the decision should be kept in the Plan.

Moving into the major and extreme categories, any risk not addressed will need not just documentation but management approval.   In these cases we’d likely be invoking ALARP – as low as reasonably practicable – as the reason for not addressing a risk.  Any time ALARP is used we’re saying the cost of reducing the risk would not be disproportionate to the benefit gained.   It’s all about identifying and understanding the project risk versus the benefit of the system that is being produced.

Whether formally addressed in the design or left open,  as a project moves forward the decisions made on risk must be documented and recorded for future use.

Bio of Paul J. Kostek

Paul J. Kostek is a Principal of Air Direct Solutions, a systems engineering/project management consulting firm. He works with companies in defining system architecture, system requirements, interface definition, verification planning, risk management and software development standards. Paul received his BS from the University of Massachusetts, Dartmouth.   Paul works in a range of industries including: aerospace, defense, medical device and e-commerce.

Paul is a long-time volunteer with several professional engineering societies including IEEE, AIAA, SAE, INCOSE and PMI.  He also writes for the CERM.