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