There are several risk management resources that are needed to connect the dots between Cost, Schedule, Technical Performance and Risk adjustments to each of these. One of the best starting points is at the Mitre Systems Engineering Practice Office.
This post started with a question about distributing risk dollars across the WBS. Yes, you have a WBS and yes you have risk dollars outside your Performance Measurement Baseline. Both are needed to have a credible plan.
But first let's have a quick review of what "risk" means when we use the term in a domain and context. The cynic is me has learned there are very few outside the formal world of EVM, space, defense, and large construction actually know what risk management means - specially in the IT world. Here's the starting point from the DoD
The process for assigning risk at the WBS level - which was the motivation for this post - go like this:
- Starting with the WBS/CWBS confirm the proper decomposition of the deliverables and the processes that produce those deliverables. The WBS definition is from only one place - MIL-HDBK-881A Don't let anyone tell you there are alternative descriptions of a WBS. They're aren't.
- With the WBS the Integrated Master Schedule (IMS) can be further developed. All the work in the WBS is in the IMS.
- With these two items, the programmatic and technical risk can be assessed. This is a standard approach defined by the 2006 Risk Management Guide for the Defense Acquisition University. The other guide is the SEI Continuous Risk Management. Either risk management guide will work. Domain and context is important here.
- Now that you have the work, the schedule for performing the work, the risk involved in delivering the outcomes from that effort, you can start to assess the impact of these risks on the probability of completing "on or before" a date and "on or below" the target cost.
- For each deliverable, there must be a schedule and cost margin
- For the technical aspects, there needs to be an error band on the technical performance measure.
A good overview of how to start "thinking" about risk see "Rethinking Risk Management: NDIA Systems Engineering Conference 2009." This briefing outlines the processes and issues of managing risks on projects. It is software focused, but is applicable to any domain. This is one of those approaches that sets the baseline for how to do it properly. There are many voices out there for risk management. Don't start any where other than here (or the DoD). Then ask if other approaches are applicable.
The final thought, as always
Risk management is how adults manage projects - Tim Lister
