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.