This is our fourth newsletter in the series on risk. Our risk series follows the
risk management framework developed by Donald Lessard, MIT Sloan School of Management, and
Roger Miller, Universite Quebec a Montreal. Lessard and Miller propose a six step
framework: 1) Identify / understand risks, 2) Shape risk, 3) Create options / Build in
flexibility, 4) Take risks strategically, 5) Transfer or hedge risk, and 6) Diversify the
risk or pool it.
This newsletter will discuss step 3 of the framework: creating options and building in
flexibility in software development project plans. Why do we need options in software
development? We have all witnessed too many software projects gone astray that missed
their objectives completely or came limping in significantly over-budget. Remaining
flexible, watching for red flags, and keeping some options open should provide for more
cost effective projects. We live in uncertain times, so why not plan for uncertainty?
As members of software development teams, we plan flexibility into our technical
architecture in the form of redundant servers and failover procedures. Why not plan
flexibility into our software development project plans? For example, planning for buggy
Scenario planning is the process of envisioning multiple realities and making plans for
effectively competing under each of them. Four or five discrete scenarios should be
sufficient according to McKinsey consultants H. Courtney, J. Kirkland, and P. Viguerie in
their Harvard Business Review article, Strategy Under Uncertainty (Reprint
#97603). The McKinsey consultants also stress that the scenarios should be updated at
least every six months. Organizations engage in scenario planning because it is more than
merely a planning experience. It is also a learning experience and such learning keeps an
organization agile and able to respond faster.
Y2K brought contingency planning to the forefront and taught many people scenario
planning. We worked last year with a bank whose Y2K preparedness involved various
scenarios regarding failure in the infrastructure. For example, what if the electrical
power grid failed? What if the phone lines failed? The client had three main scenarios for
varying levels of disaster, from a mild level disaster to a crippling disaster. All
scenarios called for keeping their customers informed. This client also hired consultants
to point out their blind spots.
For additional ideas on creating options for your software projects, please refer
to our Winter 1994 newsletter, Must the Date Move, and our Summer 1994
newsletter, Checks and Balances.
Subsequent newsletters will address steps four through six of the Lessard/Miller
framework. You can view the earlier newsletters in our risk series, and all our past
newsletters, here on our website at: http://world.std.com/~pcraig.
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.