Shaping Risk
by Pat Craig 

From the Fall 1999 issue of the Complexity Management Chronicles 

Poor risk control caused a recent client to overspend approxiately $100,000 on a small project. Seven people tests for four months. However, the code and the design were of poor quality. Finally, the Business Sponsor sent the software back to Development for months.

A project/risk manager would have quickly decided to delay the product, cut the testing effort, and save the money. But the management decided to forego a part-time project/ risk manager. This part project reminds us of the need to continually improve risk management.

Thus we begin our third newsletter in the series on risk. Our first newsletter offered ideas on risk management. Our second newsletter focused on the dangers of assumptions and the need for professional software risk managers. (You can view these past newsletters here).

This newsletter will discuss a risk management framework developed by Donald Lessard, MIT Sloan School of Management, and Roger Miller, Universite Quebec a Montreal. Based on our experience, we find their conceptual framework highly relevant to software projects.

At a high level, Lessard and Miller propose a six step framework: 1) Identify/understand risk;   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.

Our last newsletters focused on step one in the Lessard/Miller framework - identifying risk. This newsletter provides client insight about step two - shaping risk. Subsequent newsletters will address steps 3-6 of the Lessard/Miller framework.

A client of ours, a financial service provider, has built and refined their risk system for the past seven years. Our client has divided software project risks into four major groups: criticality risk (impact on the business), novelty risk (degree to which a project has "never been done before"), complexity risk (interaction between multiple technologies and businesses), and size risk (the raw size of a project in personnel, time or cost).

On software projects deemed critical to the business, this client resolves all problems as soon as possible (ideally within 24 hours) and maintains senior executive ownership, usually by means of a weekly status meeting.

To control the risks posted by building complex software, they define the project architecture right away (within a few months) and recruit knowledgeable business/ technical staff.  To shape the risk inherent novel projects, they provide time for "trial and error" and utilize prototyping. To keep a tight grip on larger projects, they plan for a four to six month delivery of components and estimate the project effort/ cost on a phased basis.

In conclusion, it gets down to fundamentals: Shape a project and you shape the risks. A different project creates different risks. In our next newsletter, we will focus on step three of the Miller/Lessard framework - Creating Options.

©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