22. Refining the Risk Management Prescription

To finish up, we return to the prescription first laid out in Chapter 10, to add a few refinements. Here we build on that chapter’s first section: “What It Means to Do Risk Management.”

1. Use a risk-discovery process (Chapter 14) to compile a census of the risks facing your project.

2. Make sure all the core risks of software projects (Chapter 13) are represented in your census.

3. Do all the following homework on a per-risk basis:

• Give the risk a name and unique number.

• Brainstorm to find a transition indicator—the earliest practical indication of materialization—for the risk.

• Estimate the cost and schedule impact if the risk should materialize.

• Estimate the probability of risk materialization.

• Calculate the schedule and budget exposure for the risk.

• Determine in advance what contingency actions the project will need to take if and when transition occurs.

• Determine what mitigation actions need to be taken in advance of transition, to make the selected contingency actions feasible.

• Add mitigation actions to the overall project plan.

• Write all the details down on a template like the one in Appendix B.

4. Designate showstoppers as project assumptions. Perform the ritual of passing each of these risks upward.

5. Make a first pass at schedule estimation by assuming that no risks will materialize. In other words, your initial estimating step is to determine the nano-percent date (see Chapter 10), the earliest date by which you can’t prove to yourself that you won’t be done. This is different from established industry practice in that we suggest you use the nano-percent date as an input to the scheduling process, not as an output of it. Derive N using a parametric estimation tool, if you have one, tuned to its most optimistic settings.

6. Download RISKOLOGY (see http://www.systemsguild.com/riskology). Enter your project parameters on the main worksheet. While you’re at it, enter all the customization factors you can find, based on supporting data from your company records. Override as much of the simulator’s industry data about core risks as you can, substituting credible data from your own environment. Add customized worksheets for all the non-core risks you’re tracking. Run the simulation to produce a risk diagram for your project, forcing the intersection to your nano-percent date.

7. Express all commitments from this point forward using risk diagrams, explicitly showing the uncertainty associated with each projected date and budget. Rather than explain the concept of a risk diagram to any of your less-than-savvy stakeholders, refer to it as a simulation of your project, run five hundred times, showing all the possible outcomes and the relative likelihood of each.

8. Create a work breakdown structure showing all the tasks needed to complete the project. Estimate the effort required for each task, using whatever scheme you currently employ. We’re going to be using these estimates in a slightly less-than-conventional way: Only the relative weights of the task efforts will matter, not the absolute values. These relative weights will be required input to the calculation of the EVR metrics.

9. At the start of the project, force commitment on net dataflows in and out of the product. You should be able to come up with a complete definition of all net input and output flows—down to the data element level—within the first 12 to 15 percent of calendar time. Treat sign-off on these net flows as a major project milestone. Don’t proceed to later tasks if this milestone hasn’t been passed. Remember, failure of this closure metric, the net flows sign-off, is a potential fatal warning.

10. Force a complete design partitioning prior to any implementation. Use this as input to the process of creating an incremental delivery plan.

11. When the design partitioning is complete, revisit the work breakdown structure, reestimate task weights, and express tasks as percentages of the remaining work to be done.

12. Assess value to the same precision as cost.

13. Break the requirements contained in the specification down to their elemental level. Number them in a rank-order by priority. Use net value to the user and technical risk as the two criteria for prioritization.

14. Create an incremental delivery plan in which the whole product is broken into versions (lots of versions, at least enough to schedule a new version every week or so). Assign all the elemental requirements to their versions, with the higher-priority items coming earlier. Calculate EVR for each version and record it in the plan. Treat the incremental delivery plan as a major project deliverable.

15. Create an overall final product-acceptance test, divided into VATs, one per version.

16. Plot out EVR versus the expected delivery date of each version. As the versions pass their VATs, place the actual results on the same graph.

17. Throughout the rest of the project, monitor all risks for transition and/or expiration, and execute contingency plans whenever materialization occurs. Monitor the EVR glide path and its performance against the expected path. Treat deviations as a sign of possible risk manifestation.

18. Keep the risk-discovery process going throughout the project to cope with late-appearing risks.