Assessing Risk
by Pat Craig
From the Spring 1999 issue of the Complexity Management Chronicles
All large software development efforts involve some risk. Stories of outright failures
or of projects failing to meet their dates fill the Wall Street Journal. For example, on
the front page of October 19, 1998's edition, an article on Federal Express included in
the headline, "New Software Caused Chaos." The next day, as part of their front
page, they mentioned that drug distributor FoxMeyer filed for bankruptcy following
Andersen Consulting's and SAP's attempt to install a new computer system.
These headlines and others have prompted us to write a newsletter series on identifying
and managing risk. Our first newsletter will identify risks for you to consider on your
new projects. Performing a preliminary risk assessment at the beginning of a
project will give you lead time to analyze and to minimize risk. While each company has
its own special risks, a checklist follows that lists the more common ones.
Financial Risks:
Return on Investment Risk: What's the probability that the project will not
deliver all the anticipated benefits, i.e. sales, better customer service levels etc. Or
could development costs spiral out of control?
Stability/Robustness/Maintenance Risk: Could annual maintenance costs balloon
into the stratosphere?
Legal liabilities: If your software fails, what is the extent of your liability?
Technical Risks:
Technical Complexity: Does this project depend on new technologies? (Beware -
vendors sometimes exaggerate or misrepresent their product capabilities!)
Design Complexity: Will the project access data from multiple databases or have
many interfaces to existing systems? Does the processing require complex error-prone
logic, such as a rules engine?
Operational Risks:
Implementation Risk: What's the likelihood that all the components will come
together flawlessly for a smooth roll-out into production? Have you planned how to pick up
the pieces if anything goes wrong?
Dependency/Synergy Risk: Does this project depend on on another project, or on an
outside vendor, or another department, for some of the coding? Does it depend on key
people and their availability?
Performance/Service Level Risk: Will the project meet performance objectives?
Acceptance Risk: Will the users resist the system? Will they revert back to their old
ways and subvert the system? Do the user groups really want the project? How many people
will need training? What will it cost to sustain this roll-out in terms of
Telecommunication staff support, Help Desk support, etc.?
Scheduling Risk: Can the install date move if problems arise?
We've written this short newsletter to help you identify some of the more significant
risks in software development. We'll elaborate on this important subject in future
newsletters.
©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 .
|