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 .
|