In-Depth

Book Excerpt: The Business Case for Development

• By Donald J. Reifer
• August 1, 2002

The following is excerpted from Chapter 3 of Making the Software Business Case by Donald J. Reifer. Used with the permission of the author and Addison-Wesley.

This article provides the principles, rules, and analysis tools to put a business case process into action in your organization. These tools are aimed at helping you quantify the costs/benefits of alternatives and develop recommendations that make sense for your organization throughout the software life cycle. In essence, the process forms the underlying framework for developing business cases. Nine principles or fundamental truths are added to the process to provide a solid foundation for quantifying costs/benefits. To help you quantify the pluses and minuses of the alternatives under consideration, I discuss a wide variety of analytical techniques. The rules and tools discussed are sprinkled throughout the software development process along with guidance on how to apply them in practice to reenforce the principles discussed as you develop your business cases, do tradeoffs, and perform financial analysis.

Business case principles
When developing business cases, several principles or fundamental truths can be applied. Unlike software development, these principles are based on decision theory rather than on software engineering dogma. To illustrate the use of the following nine principles, let's assume that you are thinking about running seminars to train your people in Java and component-based software engineering concepts.

1. Decisions are made relative to alternatives. The options that are available to you include: 1) do nothing and let your people learn Java at their own pace via the manuals, 2) implement an on-the-job training program, or 3) bring in training seminars taught hands-on by seasoned professionals in a just-in-time manner. If funds were not available for option 3, you would disregard this option as unrealistic. The choice would narrow down to the first two options. If on-the-job training weren't feasible because you don't have the staff to put it together, your remaining option would be to let your people learn at their own pace.

2. If possible, money should be used as a common denominator. When making decisions, the prospective consequences of each of the alternatives needs to be expressed in common monetary units. The current value or worth of these funds is determined over time using today's value as the basis. To justify the investment, you need to determine whether training seminars reduce the time needed to become proficient in the use of the language. If they do, then you must determine how much time and effort can be saved via this option.

3. Sunk costs are irrelevant. It doesn't matter that you already ran a seminar in Java a year ago. That's a sunk cost and is irrelevant to this decision because your staff has changed and most of those assigned to this project are new and inexperienced. In this case, all events that took place prior to the decision being made have no effect on the resulting decision.

4. Investment decisions should recognize the time value of money. Money has value that increases over time due to inflation. Today's money is worth less tomorrow. Because you can put the money in a bank with a yield of 5% to 6%, this interest rate represents the minimum attractive rate of return. Any option you consider should yield more. If it doesn't, why pursue it? In addition, if you did nothing with the money, you would incur an opportunity cost of 6% -- the interest you could earn, or the cost of money.

5. Separable decisions should be considered separately. You might be called on to recommend a training firm as part of the decision process. The criteria you would use to make this decision would be different from the criteria used to select the training option to pursue. It would be better to consider the two issues separately because it is possible that you would obscure the results if you tried to address them simultaneously.

6. Decisions should consider both quantitative and qualitative factors. Whenever possible, differences in alternatives should be viewed quantitatively. But it may not be possible to quantify all the costs/benefits associated with an option in this manner. For example, bringing in training might improve image and morale. These qualitative factors would then be used to swing the decision from one option to another if the costs/benefits were close.

7. The risks associated with the decision should be quantified if possible. All decisions are based on forecasts of the future. There is uncertainty or risk associated with predictions. This risk needs to be scoped and quantified if possible. For example, what is your plan should the training you desire not be available when needed? Do you have a fallback position? If so, what is the added cost of this contingency plan? Have you assessed the consequences of this risk and included a reserve in your budget to handle it?

8. The timing associated with making decisions is critical. You need to make decisions in sync with your budgetary cycle. If you don't, you might have to wait until the cycle repeats itself before you can put in your request for funding approval. Time your decisions so that you can be ready to strike either when money is available or when budgets for training are being formulated and approved.

9. Decision processes should be periodically assessed and continually improved. Like any set of procedures, the procedures you use for assessing the business aspects of decisions can be improved. Look for ways to streamline your processes. Look for models and tools that you can use to improve the quality of your decisions and the quantity of options considered. Once decided, realize that you need to manage the actions needed to implement your suggestions.

As the principles illustrate, software engineers look to the future to determine the impact of options under consideration. They are more interested in cost at completion than cost to date. That's because they can influence the future with their decisions, not the past. I once asked a business school friend of mine what the difference is between an accountant and an engineer. He said that accountants look to the past to analyze expenditures; engineers typically look to the future to determine what it will take to get a job done.

To put these principles to work in a business environment, software engineers must understand the terminology that business professionals with whom they interface commonly use, and which is not part of their technical vocabulary. This terminology includes accounting, economics, investment, and tax-related terms. Software engineers must understand how to take the cost of money into account via discounting. They must also understand how to assess the tax implications of investment decisions. If they don't, they will have a difficult time communicating with the people involved in approving their requests for money.

To read more about Making the Software Business Case, visit http://www.awprofessional.com/catalog/product.asp?product_id={B46F7051-42D0-4A59-A877-399B4E51DEF5}&selectDescTypeId=SAMPLE_CHAPTERS&st=5130B593-BAEC-49C6-B6A8-0035DFD1EA3B&session_id={13E7A759-A030-4DC6-9615-3F2EEF90C334 }