Risk Management is not an island!

 

Although the PMBOK Guide has individual chapters covering key project management knowledge areas, it also highlights the importance in an approach which integrates these knowledge areas in a pragmatic, tailored manner to fit the needs of a specific project taking into consideration organizational and team culture.

One of the most common examples of poor integration across the knowledge areas occurs with risk management.  Risk management needs be tied at the hip with other project management practices, but too often it is as isolated as a porcupine at a balloon convention.

What do I mean by this?

Risk is the embodiment of the uncertainty which is inherent in the DNA of projects.  Until all agreed-to scope has been delivered and accepted, risk does not disappear so why do we not connect the dots by referencing it in other key project management artifacts?

It starts with the charter – while expressing the desired outcomes and drivers for the project, there should also be coverage of the key sources of risk which could impede the realization of these outcomes.

It continues with other core planning artifacts such as stakeholder analysis documents and organization change management (OCM) plans – risks from the register should be referenced in specific stakeholder management plans and should form part of the rationale supporting your OCM strategy.

Risk drives variation in outcomes and hence the cost and time contingencies reflected in cost estimates and schedules should link back to specific risks in the register.  Risk responses for high severity risks should show up as line items in the schedule and should have been baked into your baseline budget.

Project changes should directly tie back to items in the risk register – closed and open risks.  Some project changes may eliminate certain risks – this is why one of the ways to implement the risk avoidance response is to reduce scope.  Other changes might introduce a whole new set of risks.  A well maintained risk register should be able to provide a forensic trail of project change.

Issue logs should also show evidence of traceability to risks – when known unknowns are realized as issues, linking those back to the originally identified risks provides the opportunity to assess whether there is a future likelihood of occurrence and can provide valuable input into post-project assessment of risk management practice effectiveness.

All decisions need to consider risk – analysis leading up to a decision should consider the risks associated with each option, and risk register updates should capture the uncertainties tied to the final decision.

Risk management is like quality – if you tack it on, the value derived is less than if it gets baked in as an intrinsic part of your overall project management approach.

(Note: this risk-free article was originally published on kbondale.wordpress.com in September 2014)