Share or Transfer Your Risks
in Software Development

by Pat Craig 

from the Summer 2000 issue
of the Complexity Management Chronicles 

We begin our penultimate newsletter in the series on risk management  techniques. Our series has followed the risk management framework developed by Donald Lessard, MIT Sloan School of Management, and Roger Miller, Universite Quebec a Montreal. This newsletter discusses step 5 of the framework Transfer or hedge risk.

Why transfer or hedge risk? Software can be outrageously expensive to develop. Design and requirement errors cause havoc. Project Managers underestimate. Once developed, there is also the risk that no one will want to buy the software. Working to transfer or hedge these risks can increase the probability of success and add to the return on investment.

Software professionals excel in hedging risk. The Year 2000 effort is a great example. Another example is installing redundant servers and failover procedures to hedge the risk of a hardware breakdown.

We will devote the rest of this newsletter to transferring risk beginning with academic theory, followed by its application in the real world.

Michael Porter devotes a chapter to the risks generated by buyers and suppliers in his book, "Competitive Strategy Techniques for Analyzing Industries and Competitors".

Porter warns readers to be careful about choosing buyers (customers) and suppliers. Buyers can pressure a company to lower its prices. Suppliers can start charging you more for their goods and services. Porter presents ways to analyze and mitigate these risks. The following software companies have expanded on Porter’s ideas. They have transferred substantial risk for their new product development efforts over to their buyers or suppliers!

Transfer Risk to Buyer
We worked with two software companies who built their core product with funding from a single buyer, a large New England bank. Both of these companies began with a group of software developers working as consultants for the bank. When their consulting assignment ended, they formed their own company and sought new customers. These software developers transferred their risk by letting their client determine what the product would be and building it to their exact specifications. When the product was completed and paid for, these developers marketed it to other customers. Eventually both software development organizations were sold to larger corporations, (Compuware and Transaction Systems Architects.)

Transfer Risk to Supplier
Another client collaborated with suppliers to build new software. This 10,000+ person company serving the financial community sold 45% of a new investment information business to its largest suppliers. With the suppliers owning almost half of the business they are less likely to cut off the supply of information or to raise their prices!

Hopefully, these brief examples will provide ideas on how you might transfer risk. Our next newsletter will address the last step of the Lessard/Miller framework diversifying or pooling risk. You can view  earlier newsletters on risk here at http://world.std.com/~pcraig.

©2000 by Complexity Management
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. 

*********************************************************************** 

Go to Next Newsletter
Return to Complexity Management Home
Contact Pat Craig at patcraig@alum.mit.edu