Waltzing with Bears : Managing Risk on Software Projects by Tom Demarco Chapters 8 to 13 Reflection

Reflection on Chapters 8 to 13 of Waltzing with Bears : Managing Risk on Software Projects by Tom Demarco

Link to sample Chapter 1 from Waltzing with Bears http://www.systemsguild.com/pdfs/bearsample.pdf 

Link to Waltzing with Bears Textbook Download

Chapter 8, “Quantifying uncertainty”, explains that one of the risks for any project is uncertainty in the schedule for completion of the project. It further illustrates how this uncertainty can be expressed in the form of a risk diagram, which helps to at least narrow down the window of uncertainty.

Chapter 9, “Mechanics of risk management”, talks about how risks can be identified. As the saying goes, “History repeats itself”. So the chapter states that one of the most useful methods of identifying risks is analyzing previously failed projects in the organization and listing the causes, which can serve as risks for the current project. However, I feel that this method will be highly effective only if the organization has been involved in similar projects in the past. For instance, if an organization has only been involved with maintenance projects previously, then the risks in a development project will be much higher. Nevertheless, the technique can be a valuable step in identifying risks initially. The chapter also states project estimation as an important task in risk management and emphasizes that both planned and un-planned tasks in the project must be estimated in order to avoid project delays.

Further, the chapter mentions four strategies of dealing with risks – avoidance, containment, mitigation and evasion. The author presents a very interesting point that out of the above four strategies, risk evasion does not cost anything. However, ideally it can not be considered as a risk management strategy because as per the “ethics of belief” philosophy, the risk evader is not proved right, he is just “not found out”. Another task that I thought could have been included in the above four is “risk prevention”. In my previous project, we were to design a database for storing procedure codes for claim adjudication. The current system had 5 character procedure codes, so a field size of 5 would be sufficient. However, to support future expansion of procedure codes, a field size of 10 was allocated. This would prevent the risk of the database not being able to accommodate larger procedure codes.

The chapter also explains the concept of showstoppers as risks and how their ownership can be transferred to higher authority so they are just assumptions for the project. To quote an example, in my previous project, the developers worked directly on the client’s mainframe. The mainframe had both scheduled and unscheduled downtime each day, which was essentially a showstopper for the project. So the project maintained a log of the mainframe downtime, which would help get an extension of the project deadline. Additionally, the chapter elucidates how risk impacts budget and schedule and how risk mitigation is in fact a good investment of time and cost.

Chapter 10, “Risk Management Prescription” presents a comprehensive list of the steps involved in risk management, namely risk discovery, risk estimation, calculating risk exposure, risk mitigation, and risk monitoring. It emphasizes the “Schedule > Goal > N” rule of N-based scheduling.

Chapter 11, “Back to Basics” discusses the use of risk diagrams as a tool for assessing the extent of risks and their characteristics and types, namely aggregate risks and causal risks. It also explains how a risk model can be used to transform causal risks into aggregate risks and help in estimating the schedule for the project. The examples provided in order to explain the concepts of the incremental and cumulative uncertainty diagrams were quite simple to understand.

Chapter 12, “Tools and Procedures” introduces the Riskology tool for risk assessment and explains its use and the underlying risk model. Although the use of the tool does not require an understanding of the risk model, the chapter presents an explanation of the model and the Monte Carlo sampler very aptly through a simple example (estimating time for jogging along a track) to give a background of the underlying framework. I found the tool quite intuitive in use and addressing the core risks that impact a project.

Chapter 13, “Core risks of software projects” lists five of the most common risks that impact any project such as schedule flaw due to overaggressiveness, undersizing or wishful thinking, requirements inflation due to change in domain, employee turnover, specification breakdown due to ambiguities in product specification or requirements being piled up by stakeholders and poor productivity. The chapter further quantifies the risks using industry patterns.