Let's Get Pro-Active
About Managing Risk

by Pat Craig 

From the Summer 1999 issue of the Complexity Management Chronicles 

This newsletter will discuss pro-actively managing software risk and will follow-up on our last issue. In our experience, the biggest software fiascos result from acting on flawed assumptions that sometimes originate from risk assessments. The need to track and to validate assumptions is the central theme of Rita G. McGrath and Ian C. MacMillan's article, "Discovery-Driven Planning," published in the Harvard Business Review in July-August 1994 (Reprint #95406).

New ventures are usually undertaken with a high ratio of assumption to knowledge. Unfortunately these assumptions often prove wrong, thereby requiring project redirection. Discovery-driven planning, through the use of milestones or checkpoints, raises the visibility of the make-or-break uncertainties and helps managers address them at the lowest possible cost.

MacGrath and MacMillan mention three common planning errors:
1) Managers proceed as though their assumptions are facts, especially after a few key decisions get made;
2) Managers make incorrect assumptions about their ability to implement the plan; and
3) Managers assume a static outside environment and miss key external changes. (As we all know, the software environment changes rapidly!)

We have seen flawed assumptions cause two large software projects to flounder. One project, that assumed a new technology would fill its claims of robustness, wasted hundreds of millions of dollars.

On a different project, involving a workflow system, a project manager faced with a build vs. buy decision chose to build. A year into this project, improved workflow products became available. Instead of reassessing the development effort based on these new products, the manager stayed the course and spent $40+ million on development over three years. Senior management now believes that this decision resulted in overspending in the tens of millions of dollars.

McGrath and MacMillan make a strong case for focusing on assumptions. They advocate appointing one person to coordinate investigating and updating the status of all assumptions prior to each milestone. As their article applies to software, we'd like to take it one step further and suggest that a new software discipline is called for: software risk managers.

Why do we expect that managers who are good at building software can be both builders and architects? Other fields exhibit a check and balance relationship between a driver and a risk mitigator.

We assisted a major bank install a system to monitor and to control market and credit risk. Bond traders worked closely with financial risk managers who ran this computer system daily to control risks. Similarly, a real estate developer would hire an architect when constructing a new building. First the architect resolves all issues with material, design, the site, etc. Then the architect hires the builder.

Based on our examples, assumptions can have a crucial impact on software projects. The time has come for software risk managers to become an integral part of the team.

©Complexity Management 1999
Somerville, Massachusetts
Located in Metropolitan Boston 

Complexity Management Chronicles, a newsletter for software quality assurance professionals, is published in print form four times a year. Send your name and snail-mail address to the e-mail address below if you would like to be on the mailing list - at no cost to USA mailing addresses. 


Return to Complexity Management Home
Contact Pat Craig at patcraig@alum.mit.edu