Software Performance Engineering (SPE) techniques have the potential to prevent software performance problems and produce high-quality software on-time and within budget. Unfortunately, SPE is often not included in software development projects, performance failures are all too common, and the remedies are costly and time consuming.
In many cases, the failure to use SPE can be traced to the lack of convincing economic data to quantify the economic value to the organization. Shrinking budgets and increased fiscal accountability mean that management needs a sound financial justification before committing funds to software process improvements such as Software Performance Engineering (SPE).
Preparing a business case for SPE can demonstrate that the commitment is financially worthwhile and win support for an SPE initiative. For example, a business case for SPE would identify the problem to be solved, indicate how SPE can solve the problem, and quantify the costs and benefits of adopting SPE for a given project or the organization as a whole. It would also discuss the impact of SPE on the software development process and identify any risks that might prevent the projected benefits from being realized along with strategies for mitigating them.
The heart of an SPE business case is the cost and benefit analysis. Quantifying the costs is straightforward. You will likely need software for modeling and/or measurement; you may need computer equipment; and you will need staff and/or consultants, training, etc. Some costs are one time while others, such as staff, are recurring costs. This type of data is readily available.
Identifying the intangible benefits is also relatively easy. Some examples are:
Quantifying the benefits of SPE is more of a challenge because SPE success is the absence of problems, but it is possible to quantify problem prevention. Examples of typical costs of performance problems include:
One approach to deriving this data is to consider past software development projects that had performance problems in their first release and gather the cost data. How much time was required by how many people to do refactoring? If new hardware was required, how much did it cost? If the help desk example is relevant in your environemnt, identify the cost of handling each call and gather data on how many calls are typically received when you deploy a new, poor-performing software release. To quantify lost revenue, determine the length of the delay and the expected sales, customers, etc. expected during that period. The original business case for the project usually has quantitative data on financial expectations that may help to quantify the cost of performance problems.
The Business Case for SPE paper provides background material on financial analysis techniques and shows how to use them to make your own business case. Feel free to use this information to help justify SPE in your organization.
When you are successful, please contact us for assistance on your initial projects to help you achieve quick success. Our approach is unique and has proven successful time after time.
The purpose of the panel was to present experiences in using SPE and quantify their costs and benefits. The first panel was held at the CMG2002 conference in Reno. Panelists from a variety of organizations described their projects, the level of SPE effort used, the result, and the costs and benefits (e.g., hardware savings, performance improvement, etc.). All panelists presented compelling data on the economic value of SPE. You can view the panelists presentations here:
This information should help you justify SPE adoption and use in your organization.
Dr. Connie U. Smith and Dr. Lloyd G. Williams have collaborated on a book titled Performance Solutions: A Practical Guide to Creating Responsive, Scalable Software published by Addision-Wesley. You can order it from Amazon.
See the publications page for links to additional SPE papers to help you get started.