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 patcraig@alum.mit.edu .
|
