One of the professional development training items on the books for FY17-18 at work was a book I’ve had on my to-read list for several years: Waltzing with Bears – Managing Risk on Software Projects by Tom DeMarco and Timothy Lister.
This post gives a quick overview of what I learned, with more details to be found in this PDF.
Overview
Part I: Why bother to do risk management?
- Risk is always there, so manage it instead of ignoring it.
- Risk is a possible future event that will lead to an undesirable outcome (problem). There are 5 steps to manage risk: discovery, analysis, planning, mitigation, monitoring.
- Unmanaged risks that materialize into problems are very costly, both to the company and to individuals.
- Good process alone isn’t sufficient to mitigate risks.
- Risk management provides many benefits.
Part II: Why shouldn’t we do risk management?
- Old management styles are incompatible with it. You’ll likely fail if you’re doing it by yourself.
- It’s at odds with managing for success because you can’t manage away risks; they’re always there.
- Risk management is incompatible with culture if you tolerate failure but not uncertainty.
- Counting on lucky breaks is not risk management.
- You can ignore risks when the probability of materialization is small enough, you can’t do anything about it should it happen, there are minimal consequences, or it’s someone else’s risk.
Part III: How shall we go about it?
- There’s a 9-step prescription (updated to 18 steps later on) for discovering, managing, and monitoring risk. Figure out which ones you’ll avoid, accept, mitigate, or evade. Compute your costs of exposure, containment, and mitigation.
- Quantify unknowns by coming up with windows of uncertainty based on past performance (or at worst, guesses).
- There are programs or Excel worksheets to run numbers for causal and aggregate risks. Modeling can also simulate these risks.
- Risk reserves are the time and money you set aside to contain risks.
- Try to think about risk like a probability distribution (graphs) rather than a single number.
- Discover risks by brainstorming catastrophes, working backward to scenarios, then doing a root cause analysis.
- Monitor for transition indicators (risk becoming a problem), always be discovering risks, collect data, and track how complete your project is.
- Common software risks: schedule flaws, requirements inflation, turnover, specification breakdown, under-performance.
- Start projects early.
Part IV: How much risk should our organization be willing to take?
- You can’t just hand-wave the potential benefits. Without precision here, you can’t quantify ROI or
manage risk effectively. - Benefits can be shown using uncertainty diagrams.
- Instead of looking at the aggregate cost/benefit (i.e., entire project), look at its components so that you can rank them accordingly.
- Compare the uncertainty of cost/schedule with the uncertainty of benefit to avoid death marches.
- There’s an 18-step process for managing risk and keeping information flowing.
Part V: How do we know if it’s working?
- You have a risk register with common software project risks, and there are triggers.
- You have a process for continually discovering risks, and it’s open to others.
- You use uncertainty diagrams.
- Projects have goals and estimates, and they are different numbers.
- All risks are monitored for transitions happening.
- Each risk has contingency and mitigation plans.
- Exposure has been calculated for each risk.
- Projects have quantified values, and the components are ranked on them.
- You deliver incrementally.