Book Review: Waltzing With Bears: Managing Risk on Software Projects

TLDR

The book contains dated ideas and I glossed over the theoretical sections. The last chapters made some excellent points, but not enough to change my 2-star rating. It’s a pity since I enjoyed Tom DeMarco’s slack book.

Strengths

• The authors write exceptionally well, making it flow effortlessly and drawing you in. The Indy 500 analogy is excellent, highlighting the stakes of taking every chance to win. While it might work for an Indy 500 driver, it’s unsuitable for software project management.
• Concise and short read.

Weaknesses

• Some sections of the book are densely written, making them difficult to follow. I skimmed some chapters, as they were too abstract and irrelevant.
• Some chapters were relatable but could have been more remarkable.
• The heavy emphasis on risk and academic analysis is outdated, and I disagree with some of their conclusions.
• I’m not a fan of risk diagrams – they are too abstract and hard to grok.

Who should read this book?

Anyone involved in project management – managers, product managers, and technical product managers.

One big lesson

Any plan that relies on a lucky break is a risky plan. Regardless of whether the plan succeeds or not.

Amazon link.

Chapter Notes

Caveat: I excluded chapters I didn’t find particularly intriguing.

Prologue

The book opens with a thought-provoking chapter. People are to be held accountable for their beliefs even if such blind leaps of faith are successful – the end still does not justify the means¹. This principle applies often in software engineering since we have unreasonable schedules and convince ourselves that everything will be alright eventually.

Running towards Risk

Risks and benefits always go hand in hand. If a project has no risks, then you shouldn’t do it. Risky projects lead you into uncharted waters and stretch your capabilities.

The opposite of risk management is reckless management, where you rely solely on luck to deliver success.

Chapter 6: The onus of uncertainty

At the start of the project, go around the room and ask folks what failure, rejection, and cancellation will look like. Use this to work backward, asking for scenarios that can lead to each and ways to derisk this.

Chapter 7: Luck

Reasons for not managing some classes of risks

• The probability of materialization is small enough to ignore.
• Should the risk materialize, it makes the effort irrelevant.
• It has minimal consequences and requires no mitigation.
• It’s somebody else’s risk.

Chapter 9: Mechanics of Risk Management

We aren’t really bad at estimating; what we are really bad at is enumerating all the assumptions behind our estimates

Paul Rook

• When a project strays, it is seldom because planned work took longer than anyone had thought; a much more common explanation is that the project got bogged down doing work that wasn’t planned.
• Risk management is not the same as worrying about the project – you must allocate time, effort, and money.
• Using time to measure risk exposure. If a risk is 20% likely to occur and will cost you five months if it does, your time-denominated risk exposure is one month of delay – (risk probability * time of exposure).
• Delegate some risks upwards to management so they truly own some of these decisions.

Chapter 11: Back to Basics

Unknown unknowns: Whatever you don’t know has a downside that can turn against you, and that is your risk.

Chapter 13: Core risks of Software projects

• Inherent schedule flaw
• Requirements inflation
• Employee turnover
• Specification breakdown
• Poor productivity

Chapter 14: A defined process for risk discovery

• Encourage folks to air their fears by asking about blameworthy and blame-free disasters.
• Gather win conditions from all stakeholders. If conditions clash, friction will occur, and that risk needs to be mitigated.

Chapter 16: Incrementalism for risk mitigation

• Incremental delivery derisks projects by forcing the delivery of versions involving serious risk into earlier versions.
• Proactive incrementalism requires selecting deliveries based on two criteria:
  • Value delivered to the stakeholder
  • Confirmation of risk hypotheses

Chapter 17: The Ultimate Risk Mitigation Strategy

• Any plan that relies on you catching a break here and there is the definition of risk itself. Don’t cut it close.
• For a project with a critical delivery date, starting early is essential.

Chapter 18: Value quantification

• Costs and benefits need to be specified with equal precision.
• Today, benefits have become quite imprecise; while we are clear on a project’s cost, we hand-wave about its value. Benefits are sometimes wishy-washy because the requester is in a place of power and authority.
• Just as managers are held accountable for project outcomes, stakeholders need to be held accountable for predicted and realized benefits.

Chapter 19: Value is uncertain too

• It’s difficult to predict the actual beneficial returns of Market enhancement products (competition might beat you or out-innovate you, the market might not respond etc.).

Chapter 20: Sensitivity Analysis

• Argues that the core valuable pieces of a codebase might be at most 10% of the entire codebase—the Pareto principle.
• Allocating cost/value to each segment of code
• Start with components that have the highest value/cost ratio

Chapter 21: Value offsets risk

• Only take risks if the potential rewards can compensate. No amount of risk-taking justifies a low-stake project.
• Death march projects require everyone to sacrifice. The authors challenge this: Why is the company unwilling to sacrifice and fund it appropriately if it is so important?

Conclusion

You can read more book reviews here.

1. You haven’t been proven right; you’ve only been “not found out” to be wrong ↩︎