Waltzing with Bears : Managing Risk on Software Projects by Tom Demarco Chapter 14 to 17 Reflection

Reflection on Chapters 14 to 17 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 14, “A Defined process for Risk discovery”, states that along with core risks, there may be project-specific risks that impact a project. This chapter talks about identifying project-specific risks and the factors that hinder the risk discovery process. One such factor is the “can-do” attitude of the organization, wherein a project member who articulates a risk could be termed as a negative-thinker. In order to overcome this problem, it is important that the organization encourages “what-if” thinking. This is also the basis of the defined process for risk discovery described which begins with the outcomes of the risk, unfolding the scenarios that could lead to the risk and ultimately the causes of the scenarios.

The chapter also suggests some more techniques for risk discovery such as brainstorming, scenario-building and root cause analysis. My previous project employed the brainstorming and root-cause analysis techniques for identifying the causes of defects in the code, which were very effective in reducing majority of the defects caused due to oversight or not following coding standards. These techniques will help promote “what-if” thinking among project members to identify the risks. The author also recommends identifying and isolating the “win” conditions of each stakeholder in the project to make sure that they are not contradictory, as conflicts in “win” conditions is a definite risk to the project being accepted.

Chapter 15, “Risk Management Dynamics” emphasizes the importance of risk management as an ongoing activity as opposed to an activity done only at the beginning of the project. It includes the following tasks that need to be carried out throughout the life cycle of the project - risk monitoring, risk discovery, risk data collection and tracking closure metrics. The closure metrics that need to be tracked include “boundary elements closure” and “earned value running”. The boundary elements closure metric protects against the risk of specification breakdown by analyzing the net boundary flows so as to obtain a sign-off by all the stakeholders within the first 15% of project duration. The earned value running (EVR) metric is used to track project completion status from 0 to 100 percent and provide credible evidence of partial doneness while the project is in progress, as and when each module of the project completes (incremental delivery).

 Chapter 16, “Incrementalism for Risk Mitigation” further explains the concept of “incremental implementation” as explained by the earned value running metric collection in the previous chapter. Creating the work breakdown structure is one of the techniques for categorizing tasks and their dependencies, measuring the EVR and targeting incremental delivery. In my previous project, the visual basic screens for insurance member enrollment and billing were developed in increments and each week a “build” (incremental version) of all the screens combined would be sent to the client as a deliverable for review. This technique would help in increasing visibility and involvement of the stakeholders and gaining acceptance from them early on as the product is being developed as opposed to once the product is already built and thereby, reduces the risk of product not being accepted by the stakeholders. It also helps in targeting the uncertain requirements in earlier versions to reduce the risk. So, I agree with the author that incremental delivery is a good method for any project, especially when the risks are high.

Chapter 17, “The Ultimate risk mitigation strategy” emphasizes with examples that for projects with critical deadlines, it is better to make an early start, which I think is a very practical option for reducing the risk of not meeting deadlines. It will also help in discovering issues early on. Since the amount of effort involved in a project is more or less constant, starting the project early will enable finishing it early or at least on time. 

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.

Waltzing with Bears : Managing Risk on Software Projects by Tom Demarco Chapters 5,6 and 7 Reflection

Reflection on Waltzing with Bears : Managing Risk on Software Projects by Tom Demarco Chapters 5,6 and 7
Link to sample Chapter 1 from Waltzing with Bears http://www.systemsguild.com/pdfs/bearsample.pdf

Link to Waltzing with Bears Textbook Download

Primarily, the book “Waltzing with Bears” offers valuable insights about risk management techniques and how they can be applied. However, chapters 5, 6, and 7 deviate from the theme a little to talk about scenarios where risk management techniques cannot be employed (For example: ‘can-do’ attitude of an organization).

Chapter 5 adopts a very pragmatic approach towards risk management and explains various such circumstances where risk management is avoided. For instance, stakeholder might not take up the project if he/she knew the risks involved. The author also talks about organizations that advocate the “manage for success” approach and that it is difficult for one person to swim against the tide and promote risk management in such an organization.

Chapter 6 further elaborates on the “uncertainty” factor in certain corporate cultures that accept failures and delays but not uncertainties. Such an approach thwarts risk management efforts. The result is that such organizations concentrate on selective minor issues while large problems are blindly ignored and taken off the risk list, the consequences of which usually cataclysmic to the project. This can be avoided by tracking the risks that are crucial to the project from effect to cause, along with other minor issues.

Chapter 7 explains that when listing the risks, there are some risks that are dependent on sheer luck and which cannot be incorporated in the list of risks impacting a project. The example the author quotes is that of an “asteroid demolishing the company”. From personal experience, I can share one such instance. During the coding phase of my project in my previous organization, when the team size increased to 60, we were shifted to another building so that the entire team could be seated together. About 2 weeks after the shift, there was a downpour, which flooded the basement of the building and damaged the servers and generators in the building. As a result, the entire team was not able to do any work for 3 days till the servers and generators were restored. The project went off-schedule.

So basically, the absence of 1-2 people in the team can be handled using risk mitigation strategies like padding the schedule but the absence of an entire team of 60 for 3 days (more than 1000 hours of effort) is not foreseeable and hence cannot be planned for in advance when estimating the delivery dates for a project. But that does not imply taking chances with all the risks as the author concludes. Proper risk management strategy requires every risk to be evaluated before taking it off the list.

Waltzing with Bears : Managing Risk on Software Projects by Tom Demarco Chapters 1 to 4 Reflection

Reflection on Waltzing with Bears : Managing Risk on Software Projects by Tom Demarco Chapters 1 to 4
Link to sample Chapter 1 from Waltzing with Bears http://www.systemsguild.com/pdfs/bearsample.pdf

Link to Waltzing with Bears Textbook Download

Chapter 1, "Running toward risk" starts off with describing what should be your attitude towards risks. There is no project without risks. And the best way to deal with risks is to accept them instead of avoiding risks. Once you accept the risk, you can work on a risk management strategy.

Chapter 2, "Risk Management Is Project Management for Adults" presents examples of risk management and risk mitigation. We all do some sort of risk management or mitigation in our daily lives. Insurance, for instance, is a classic example of risk mitigation by transferring the risk of financial loss to the insurance company and obtaining coverage for a monthly premium in the event of an accident or a health problem. Tom Demarco discusses the phases of risk management which start with

1. "Risk Discovery" - identifying all possible risks through brainstorming
2. "Exposure Analysis" - quantification of each risk in terms of its probability of materializing
   and its potential impact
3. "Contingency Planning" - what you expect to do if and when the risk materializes
4. "Mitigation" - steps that must be taken before transition in order to make the planned
   contingency actions possible and effective when required
5. "Ongoing transition monitoring" - tracking of managed risks, looking for materialization

Chapter 3, "Denver International Airport Reconsidered" talks about the project to build a new Denver International airport to replace the existing one, Stapleton Airport. Stapleton was judged incapable of expansion, inadequate to serve the growing city, and guilty of contributing to ever-more-evident noise- and air-pollution problems. With the new airport, costs would be reduced, pollution and air-traffic delays would be eliminated, and growth would be assured. The new Denver International Airport (DIA) was scheduled to open on October 31, 1993 and everything for ready except for the software DIA Automated Baggage Handling System (ABHS) due to which the airport could not open.So much blame was laid on the software team that even today, the phrase "DIA Automated Baggage Handling System" is a recognized symbol of incompetent software projects. Later analysis found that there was little or no risk management at the DIA project. Had there been a risk management strategy adopted earlier on in the project, a delay in the software delivery would have been identified as a significant risk.



Chapter 4, "The Case for Risk Management" presents the importance of risk management for even the smallest projects. What the software industry can learn from the DIA example is the potential cost of not managing risk. Risk management is a way to break the grim cycle of failed projects by providing a set of meet-able goals and schedules and engendering successful projects that look and feel successful from beginning to end.