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.