Creating Options
by Pat Craig 

From the Winter 2000 issue of the Complexity Management Chronicles 

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

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 2000
Somerville, Massachusetts, 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