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.