people understand how to manage risk. Executives do it every day when they make calculated decisions. Given the right data about software behavior, managers can control software risk as they would any other business risk.
In order to be successful, any software risk management approach must apply an advanced, proven methodology, appropriate technologies, and specialized expertise in software risk identification, mitigation and management.
If a software package is essential to your business, either because it is embedded in your products or because your operations platform relies upon it, the risks inherent in flawed software may be unacceptably high. The software reliability issue boils down to determining how much risk your company is willing to accept by counting on a product that includes potentially damaging, even dangerous, software.
Put succinctly, the fundamental software question is one of software risk assessment and management. These issues can be framed in terms of potential payoff and required investment, and sound decisions can thus be made using a marriage of business goals and technology realities.
Just as there is no "sure thing" in business, there is also no "sure thing" in SRM. The key to an appropriate approach is to understand the business impact of technical software risks, then address the most pressing risks using sound technology. Business risks, including technology risks, must be identified, ranked in order of severity and addressed in rank order by well-conceived mitigation techniques.
The Early Bird Gets the Bug
Starting the risk analysis process early is important; the earlier in the development process that risks are taken into account, the more efficiently mitigation planning and resource allocation can proceed. Software risk management efforts-including test planning, technology choice, human resource allocation and budgeting-should be driven by business impact determinations.
Fundamentally, risk analysis helps project leadership choose among a large set of possible SRM approaches, and realistically determine which ones should be applied.
A basic outline of an SRM methodology based on business-relevant risk analysis should include the following steps:
- Identify software-induced business risks.
- Synthesize information relevant to product use and business goals.
- Create a software risk management strategy to determine critical trade-offs between technology-driven approaches and business objectives.
- Implement the software risk management strategy by designing, measuring, monitoring and testing software against identified business risks.
Keep in mind that risk identification is not just a one-time activity. It is a dynamic process; risks evolve and change according to fluctuating market pressures, technology advances and business strategy. Any type of severity ranking is clearly context-sensitive and time-dependent, hinging directly on the changing business needs and goals. Thus, it is important to regularly revisit the risk analysis process and periodically review the risks according to changing business and technology scenarios. Software upgrades and changes in operating environments make this process all the more important as their introduction can create new, unforeseen vulnerabilities.
In the End, a Business Decision
The threat of software-related losses provides a significant incentive for businesses to manage the risks of essential software failure. In the past, business risk management models traditionally underplayed the importance of software risk management. Today, however, executives recognize the increasingly central role of software in virtually every aspect of business operations.
In the age of eBusiness, software failure can lead directly to business failure. Software product performance and its direct relation to business success or failure is clearly an executive management issue. As a result, a proven, methodical approach to software risk management is an absolute necessity.
1. From Hershey's Form 10-K. Filed March 13, 2000 with U.S. Securities and Exchange Commission.
2. From eBay's Form 10-Q. Filed August 9, 1999 with U.S.