C.1 INTRODUCTION

This appendix is concerned with the techniques of cost-benefit calculations, an important part of any systems analysis effort. Its purpose, of course, is to demonstrate to the users of the new system, as well as other groups of managers throughout the organization, that the expected benefits of the new system exceed the expected costs.

As a junior systems analyst, you may not be involved in this effort at all, or you may be given the job of developing a cost-benefit model for a small part of the overall system. Even as a senior systems analyst in charge of the entire project, you may not be involved in the cost-benefit calculations; it may be done, for example, by a separate, independent financial group.

Or it may not be done at all! Many systems are developed in organizations simply to meet mandatory government requirements (e.g., reporting systems for the Equal Employment Opportunity Act or new systems to deal with the vagaries of tax legislation). Of course, even in these cases, when there is no benefit to be derived from the system (other than the luxury of avoiding penalties or being allowed to stay in business!), management generally wants to know what the cost of the system will be; but this may be carried out as part of the estimating activities discussed in Appendix B.

There is one other reason why the cost-benefit study may not be carried out: the user may not want one. Just as a consumer may not be able to cost-justify a Cadillac (i.e., he could have done just as well with a small Honda or even a bicycle), so many users are unable to cost-justify a new system they have asked for. Sometimes they ask for a new system for the same reason a consumer may buy an expensive car — keeping up with the Joneses [1]. In other cases, the user may feel that there is a legitimate need for a new system, but may recognize that all the benefits are intangible or extremely difficult to quantify; the user may justify the request for the system by claiming an “entrepreneurial hunch” that it will pay off.

As a systems analyst, it is not your position to insist that a cost-benefit calculation be carried out; after all, it’s the user’s system, and if he wants to build it without any justification at all, that is his prerogative. However, it’s a very good idea to find out whether a cost-benefit calculation for the project has been done and, if so whether it is a rational one [2]. If there is no cost-benefit study, or if the benefits are very fuzzy (or the costs glaringly underestimated), you should be aware that the project is vulnerable.

In the worst case, you’ll find that the user is not terribly enthusiastic about the project, but has been talked into it by higher management, based on the optimistic calculations of the project manager who really wants to build the system (because it will enhance his career, because he thinks that all users should be fully computerized, or for a hundred other reasons). In the best case, you may find that the user has authorized the system and is very enthusiastic about it despite the lack of a rational cost-benefit calculation. But users are fickle: today’s pet project becomes tomorrow’s discarded project.

And users come and go: the user who authorized the project yesterday may be replaced by a new user tomorrow who takes a very different view of the desirability of the project. So, if there is no cost-benefit calculation (and it’s evident that nobody wants to develop one), my advice is very simple; keep your resume up to date, for you may be looking for a new job before the project finishes.

In the sections below, we will examine several aspects of cost-benefit calculations:

• Cost analysis
• Benefit analysis
• How to express the savings
• Risk analysis

C.2 COST ANALYSIS

The purpose of this activity, of course, is to calculate all the anticipated costs associated with the system — not only the cost of building the system, but also the cost of installing the system and operating and maintaining the system, as well as ancillary costs. Each of these is discussed next.

C.2.1 The Cost of Building the System

In Appendix B, we discussed techniques for estimating the length of time required to build a system and the number of people required. Keep in mind that you need to calculate not only the cost of the programmers and systems analysts, but also all of the other people involved with the development of the system:

• Clerical people
• Managers
• Members of the user community
• Consultants and contract programmers
• Possibly members of the auditing, QA, or operations staff

In most cases, you can obtain from management (or from the accounting department) the average salary of the categories of people that are included in your project; this may be expressed in terms of hourly costs, monthly costs, or annual costs. Make sure that you take into account your company’s overhead factor; that is, you will probably have to multiply each salary by a factor of, say, 150% to cover the cost of insurance, employee benefits, and various other corporate overhead factors. Again, you should be able to get this figure from your management or from the accounting department.

Keep in mind also that the people working on the project will not be available 100% of the time: some time will necessarily be lost because of illness, vacation, personal leave, and the like. Your company may have a standard factor to apply for this lost time; if not, a figure of 10% is the very least you should assume; 20% to 25% is not all that unrealistic. (It’s possible that this has already been taken into account in the resource estimates carried out in Appendix B. Check to ensure that the lost time factor has not been left out and that it has not been applied twice.)

In many projects, you must also include the cost of training the development staff. Team members may need training in new development methodologies, new programming languages, or various hardware and software skills associated with the vendor equipment being used. Another cost that must be taken into account is that of computer time, terminals or workstations, and development tools (editors, testing packages, etc.) that are required for the development of the system. In some cases, the terminals and development tools may already exist and your project may not incur any additional charges; in virtually all cases, though, the project will have to include costs for the computer time involved. (Note that this may also include disk storage costs, telecommunication costs, as well as costs for paper, forms, and other ancillary supplies).

Some new projects are developed with new people, that is, people who did not work for the organization prior to the project and for whom office space presumably did not exist. Thus, you may have to include recruiting costs (travel expenses for the job candidates, recruiting fees for employment agencies, etc.), as well as employee expenses associated with the initial orientation training that a new employee must go through. And you may need to include the cost of office space, desks, telephones, and other equipment for the new staff.

On some projects, there are also travel costs associated with visits that must be made to remote user sites in order to interview users. Obviously, this is not a factor on a project where all of the users are located in the same geographical area as the development team; but on projects where there are diverse groups of users in different locations (often in different countries), this can be a major expense. By the way, management will often assume that all the required information can be gathered in one trip; in real projects, subsequent trips are often necessary to resolve questions and misunderstandings [3].

Thus, the costs for development of a system can be many and diverse. The following list summarizes the discussion above; it may not be a complete list, but it covers most of the major items:

• Salaries and overhead for all the personnel attached to the project
• Training costs
• Computer time and development tools for the staff
• Recruiting costs for new staff
• Office space and office equipment for new staff
• Travel expenses to visit remote users

C.2.2 The Cost of Installing the System

In a simple project, it may be sufficient to telephone the user and tell her or him that you have finished developing the system; you may be able to deliver it to him on a floppy disk, and let him install it on his own desktop computer. But on a large, complex system, there is much more to the installation process, and there are many costs involved. Among them are the following:

• User training costs
• Database conversion costs
• Vendor installation costs
• Cost of regulatory approval
• Cost of parallel runs
• Cost of development team during installation

Typically, the entire user community will require some training to become familiar with the usage of the system. Additional training may be required for supervisory users; some training may also be required for the operations staff and various other ancillary personnel. Note that this means that we must also include the cost of developing the user training courses, the cost of training manuals or course documentation, as well as the cost of user training facilities (classrooms, etc.). Finally, don’t forget the cost of the user’s time during this training process; you may be asked to compute that in terms of the salaries of the users, or you may have to compute it in terms of the replacement cost of the people doing the users’ jobs while the users are being trained.

Database conversion costs can be ignored if you are installing a new system for which there is no predecessor. But if the new system is replacing an existing system, then there will almost certainly be an existing database that needs to be brought over to the new system. If the existing database is noncomputerized (e.g., file folders full of scraps of paper), then there may be a substantial cost associated with data entry; that is, someone (or possibly a large group of people) will probably have to sit at a terminal and enter all the relevant data into a computer system. If the existing data are already computerized, there may be a somewhat smaller cost involved in mechanical translation of the old files into a new format [4].

Vendor installation costs should not be ignored, especially if the system involves new hardware, new telecommunication equipment, and/or new software. The vendors will generally give you a good estimate of the installation costs, and you should be able to get them to quote a fixed cost.

For some systems, there may be a cost of licenses or other forms of regulatory approval, from various local, state, or federal governmental authorities. This could also include such things as environmental testing of radiation emissions from the CRT screens used by the user’s data entry operators. If regulatory approval is a “cut and dried” procedure simply involving the filling out of forms, you should be able to estimate the cost fairly accurately; if instead it involves an open-ended testing process, your estimate may have to be much more approximate.

The cost of parallel runs, if any, must also be included in the estimate of installation costs. For many types of systems, the user will insist that the old system be carried on, in parallel with the new system, for some period of time. This may entail a temporary doubling of user staff or other related expenses. You should be able to find out (hopefully in the specification for the system) how long the parallel run period will be; this should help you develop an appropriate estimate.

Make sure that you don’t forget the cost of the development staff involved in the installation. Typically, the programmers and systems analysts who were involved in the development of the project will be heavily involved in its installation. Obviously, in addition to their salaries (and possible overtime) and overhead, you must also take into account any travel expenses required to install the system in a remote user location.

Finally, keep in mind that for large systems installation will not take place in one fell swoop; a new banking system, for example, may be installed in one branch office after another, over a period of several months. In general, this will mean that the installation cost of the initial branches (or user areas) will be more expensive than those of the subsequent ones, because the installation team will be more and more experienced and (hopefully) any initial problems with the system will have been shaken down after the first few installations. On the other hand, if the installation process goes on for several months (or even years), then you must take into account the possibility of staff turnover: people who have become experienced at installing the system and training user groups may get tired of the process and move on to a new job somewhere else.

C.2.3 The Cost of Money

The money required to develop and install a system does not grow on trees; it must either be borrowed by the organization, or it must be taken out of the organization’s current funds. Thus, there is a cost associated with the use of the money. Depending on your organization, you may be asked to express this as the cost of borrowed money or in terms of the interest that the money could have been earning if it had been invested instead of being used for your project.

This is an area where you should turn to your accounting department for advice. They will almost certainly have a standard guideline for how such matters should be treated, and it’s important that your project use the same approach.

C.2.4 Operational Costs

Once you have installed your system, it will cost money for the user to continue operating it. However, this should also represent an area where your new system will save money, since it will presumably be cheaper than the current system that the user has (unless you have added a great deal of functionality). Typical of the operational costs are:

• Hardware costs and related supplies and equipment
• Software costs
• People costs
• Maintenance costs
• Facilities costs

Hardware is a broad term here, including the cost of the computer equipment (assuming that it hasn’t been purchased outright, but see also Section C.2.6, telecommunications equipment, terminals, workstations, and supplies (paper, forms, floppy disks, disk packs, printer ribbons, etc.). Keep in mind also that some hardware can be thought of as a consumable in the sense that it wears out and needs to be replaced. This includes terminals, some printers, and perhaps other types of hardware. Be sure that future periods reflect replacement costs as needed.

Software costs, in this discussion, mean the ongoing lease costs for operating systems, database management packages, and other system software that your system may have leased from a software vendor.

People costs include the operations staff, technical support personnel, maintenance programmers, and the cost of those users directly involved in the ongoing day-to-day operation of the system. As discussed above, you will probably have to express this as a loaded cost in order to take into account insurance, benefits, and corporate overhead.

Maintenance costs include the expected monthly (or annual) maintenance cost for the computer equipment; your estimate here should not only include the cost of preventive maintenance that the vendor provides, but also any extra costs associated with actual repairs if equipment breaks down. You should also include the maintenance costs of vendor-supplied software, if applicable; the maintenance contract offered by the software vendors usually includes a hot-line telephone number for technical support, as well as free (or reduced-cost) upgrades to new versions of their packages.

In addition, your maintenance costs should include an estimate of the maintenance cost for repairing and enhancing the application software. This can be a major cost factor, as evidenced by the fact that most organizations spend more than 50% of their data processing budget on maintenance. There are various ways that you can estimate the maintenance costs of the new system:

• If you system is replacing an old system, you might estimate that the new system will require the same amount of maintenance effort. This is a fairly conservative effort, for it implies that the old system was developed using fairly modern software engineering techniques and that the new system won’t use techniques any more modern or efficient. This is unlikely if the old system is 10 to 15 years old, but it at least represents a sort of worst-case estimate.
• An optimistic estimate might be based on an expected savings over the maintenance of the current system. Many organizations have found, for example, that their maintenance costs have been reduced by a factor of five or more by careful use of structured analysis, structured design, and structured programming [5]. You should investigate other similar projects within your own organization to see whether savings of this kind have been achieved; if so, it may be reasonable to expect similar savings on your project. Be leery, however, of the temptation to show sizable personnel reductions based on the installation of your new system; it rarely happens, for reasons discussed in Section C.3.1.
• If there is no current system to use as a comparison (or if you want to avoid overly optimistic and overly pessimistic estimates), try to determine the average maintenance cost for similar systems in your organization. This will probably be based on some normalized unit (e.g., maintenance dollars per line of code per year or maintenance dollars per function point per year), but the estimates that you carried out in Appendix B should allow you to make the appropriate maintenance estimates for your project.

A final cost that must be estimated when calculating the operational cost of the new system is that of the physical plant (e.g., the computer room and the office facilities for operations staff, vendor maintenance people, and user staff). If the new system is going to operate on a centralized mainframe that is already in place, these facilities costs may already have been buried in the overall hardware cost discussed above. However, if you are developing a brand new system that will have its own operational facilities, this could well be a major cost.

C.2.5 The Cost of Failures

There is yet another cost that you must take into account: the cost of potential failures in the new system. It is convenient to bury this in the category of operational costs, but it tends to hide what will become an increasingly important aspect of information systems in the future: their reliability.

There are various forms of system failure, as you can imagine; in some cases, the system is entirely unavailable for operation until the error has been corrected, while in other cases, the system continues to operate, but one or more of its outputs are incorrect. In some cases, some functions in the system may be inoperable, and in other cases, some users may be unable to access the system. All these forms of failure have a cost associated with them: hardware costs, software costs, people costs associated with correcting the error, potential legal costs if the system has caused financial loss or some other grievous loss, and possibly loss of revenues or loss of customers.

How should one estimate this? It would be naive to ignore this area altogether, for we have not yet achieved the ability to build perfect systems; on the other hand, if you ask any of the programmers or systems analysts on the project how many failures they expect to have in their new system, they look at you as if you had just suffered a new form of senility.

Perhaps the most responsible thing you can do is to (1) look at the failure rate of the current system, if you are building a new system to replace an existing one, and (2) look at the failure rate of all other systems in your organization [6]. You may then be able to make some reasonable assumptions about the failure rate that can be expected in your new system. Hopefully, your project can be built with substantially fewer errors than in the current system, or even the average system in your organization; indeed, you should be striving for a minimum of a factor of 10 improvement, if not more.

If there are no available statistics about software reliability of your organization’s current system and no basis on which to make an estimate for your new system, then at the very least you must include this fact in your risk analysis document; see Section C.5 for more information. If you are building a large, complex system in which a failure would have potentially disastrous, far-reaching consequences, it is professionally unacceptable not to have a software reliability model, despite the fact that most organizations do not currently bother doing so. For more information on this area, see Software Reliability by Glen Myers (Reading, Mass.: Addison-Wesley, 1979).

C.2.6 Distinguish between Capital Costs and Expensed Costs

Some of the costs associated with the new system will be expensed during the year in which they occur; that is, your organization will recognize those costs on their P&L statement (and in the tax returns they file with the IRS) during they year they occur. Other costs are capitalized; that is, the costs are spread over a period of several years. While this does not affect the aggregate cost of the system, the classification of a cost as expensed versus capitalized can have an enormous impact on the organization’s tax position. Similarly, the decision to incur some costs on a purchase basis instead of a lease basis can have an enormous impact on the organization’s cash flow, even if the total cost remains the same.

Typically, hardware purchases are considered a capital expense, and the cost is spread over a period of 3-4 years for desktop PCs and laptops, and 5-7 years for mainframes and other larger items (depending on the prevailing tax regulations). The cost of developing the software may or may not be capitalized. And installation costs and operational costs are normally expensed in the period when they occur, though there may be minor variations in this area.

Obviously, this is not an area where you can invent your own accounting policy. It is important to find out what financial standards are used in your organization and follow them in a consistent fashion.

C.3 BENEFIT ANALYSIS

It is much more difficult to calculate expected benefits of a new information system than it is to calculate its costs. In some cases, as mentioned at the beginning of this appendix, it may be impossible — because the system is mandatory or because the user has decided that he wants the system regardless of whether tangible benefits can be identified.

It is the attempt to calculate tangible benefits that causes so many problems. Users are likely to wax enthusiastically about “better control” or “more timely information” or “better decision-making scenarios,” but if you ask them how much money they’re going to save or how much profit it will add to the bottom line, they’re likely to waffle and say, “Oh, lots and lots ... I just know that it’s going to be terrific!” Indeed, the new system probably will be terrific — but words like terrific don’t fit very well in a spreadsheet showing numerical comparisons of costs and benefits.

Thus, your biggest job in carrying out a cost-benefit calculation will be that of pinning the users down and getting them to commit to tangible benefits that can be measured and calculated in a quantitative way. If you are unable to do this (which is the case for many projects and many systems analysts), try to get the users to compare your new system with some other system with known benefits. Thus, you might say to your user, “Suppose you had to make a choice between the new system we’re talking about and System X. Which one would you consider is most important? If we could only implement one of them, which one would you pick?” Assuming that System X has some tangible benefits associated with it, this should give you at least a crude way of determining the approximate value of the new system.

In the following sections, we will distinguish between tactical benefits and strategic benefits offered by the new system. In this context, a tactical benefit is one that allows the organization to continue carrying out the same business activity, but at a lower cost (or a higher profit); a strategic benefit is one that allows the organization to begin conducting an entirely new kind of business or to conduct business in a new area or with new clients.

C.3.1 Tactical Benefits

The tactical benefits are often associated with reductions in clerical or administrative personnel; while this is not music to the ears of the clerical users, it is nevertheless a fact of life. A new information system may allow the same function to be carried out with half the number of users or even less. This is generally because the users are currently carrying out calculations or data-recording activities by hand, when it could be computerized; or they are forced to carry out the same activities (or record the same data) multiple times, when it could be done once on a computer; or it takes them a considerable of time to retrieve data, when it could be done quickly by a computer.

Though this is an obvious benefit of the new system, be careful that you don’t overestimate its effect. In some cases, there will be fewer savings than you might have estimated; union regulations and the good-hearted nature of middle ranks of management in the user organization may prevent some of those clerical-level users from being laid off. And, equally important, you should realize that more senior levels of management are less and less impressed by the savings of one or two clerks; they are looking for bigger and better benefits from the introduction of a new system.

A slightly more interesting form of tactical benefit is the savings that comes from being able to process business transactions more quickly. Faster turnaround (or being able to handle more transactions per second) not only affords the opportunity to reduce clerical costs, it can lead to better cash flow for the organization (i.e., getting the customer’s order turned into cash more quickly, speeding up delivery time of customer orders, etc.). The trick, again, is quantifying this and expressing it as a dollar figure. But, as an example, consider the following dialogue between the systems analyst and the user:

Analyst: So, how many orders a day do you process?

User: Well, we process 10,000 orders a day. But there’s always a backlog — so it takes a week, on average, before a customer’s order is processed and shipped.

Analyst: And the invoice is sent to the customer along with his order, right? So the customer isn't expected to pay his invoice until he receives shipment of his order?

User: That’s right.

Analyst: So, if we could reduce the order processing delay from five days to one day, we would get the customer’s cash, on average, four days earlier. And if the average customer order is $1000 and we process 10,000 orders a day, that means we’re talking about $10 million dollars a day. Getting our hands on $10 million four days earlier than before, for each day’s orders, would be worth. ...

A new system may also bring about savings in computer equipment; the old system may be running on an expensive mainframe computer, while the new system runs on a client-server configuration, on a desktop computer, or perhaps on a small Web site. Such a change not only saves computer hardware costs, but it also saves money in the area of facilities costs, operator costs, and the like. And if the new system reduces the amount of paper and printed forms, that should also be reflected as a savings. Make sure your calculations are complete here; keep in mind that fewer file cabinets may be needed, less office space, fewer typewriters, possibly fewer telephone calls between your organization and the customers, and so on.

The maintenance costs of the new system should also provide a benefit, as discussed in the previous section. Hardware maintenance costs should be reduced (unless you are running your new system on the same computer equipment that is installed in the organization), and software maintenance costs will presumably be lower than that of a current system.

C.3.2 Strategic Benefits of the New System

In more and more cases, the truly interesting and important benefits of a new system are the strategic benefits — not only the opportunity to save a few clerical people or a few pieces of paper, but rather the ability to let the organization do things that would not be possible with the current system. There are several examples of potential strategic benefits:

• Identifying or attracting new customers that the organization would otherwise be unable to identify.
• Entering new markets or providing new products that were previously not available.
• Capturing, reproducing, or distributing knowledge and expertise that was previously known only to one or two people in the organization.

In an economy as competitive as today’s economy seems to be, an information system that can attract new customers or prevent current customers from being lost to the competition is valuable indeed. In some cases, this may be possible because your new system offers functionality that was not available before; in other cases, it may result from your system’s ability to identify potential new customers that the organization was previously unaware of. Whatever the situation, you should try to quantify this benefit in terms of increased customers or increased market share and, from that, ultimately in terms of revenues and profits.

A more difficult form of strategic benefit is the ability of the new system to provide information that was not previously available. The typical example of this is the ability of the system to identify trends and patterns (e.g. sales trends by territory or season or customer preferences for different products). This is possible in almost any automated system that replaces a manual system; and there is usually an opportunity for any type of on-line or real-time system to present such trends in a more timely fashion than would have been possible with a batch system. Similarly, a system with graphics capabilities can provide information in a more effective fashion than a current system that produces information in the form of tables and numerical printouts. And a system built with a fourth generation programming language and a modern database management system can permit ad hoc browsing through the database.

A somewhat newer form of benefit made possible by commercial expert systems is the encapsulation of knowledge that was previously known only by one or two people. This knowledge is typically judgmental, diagnostic, or evaluative in nature, and the human expert who possesses these skills is usually considered a very valuable asset to the organization; hence the ability of the new system to replicate this expertise should be a benefit whose value can be calculated.

As artificial intelligence techniques continue to grow, we will find ourselves identifying, as a benefit, the ability of a system to extend the knowledge originally only known to one or two human experts in the organization. Thus, a human expert in the organization may have a number of rules of judgment that he or she uses to diagnose the likely cause of failures in some mechanical system (an oil drilling platform, for example). It would obviously be strategically beneficial to capture that human expert’s knowledge and replicate it for others to use; but it may be an order of magnitude more valuable to be able to extend that expertise and increase the diagnostic ability to deal with system failures.

C.4 HOW TO EXPRESS THE COSTS AND BENEFITS OF THE SYSTEM

If all the system costs were incurred instantaneously and all the benefits realized instantaneously, it would be relatively simple to represent the value of the system as the difference of benefits and costs. But, as mentioned earlier, costs usually occur over a period of years; and even if a cost is actually incurred at one point of time (e.g., a hardware purchase), the organization’s accounting policies may dictate that it be spread over a period of several years.

Thus, you will probably have to demonstrate the costs and benefits of your proposed new system over a period of time. There are four common methods for doing this:

• Cash flow
• Return on investment (ROI)
• Internal rate of return (IRR)
• Net present value (NPV)

Each of these is discussed next.

C.4.1 Cash Flow

Whether or not your system eventually shows a profit (benefits that exceed the costs), management may want to know how much cash will have to be invested before a positive cash flow can be expected; obviously, they will be more concerned about this for large projects than for small ones. Note that the project's cash flow may be quite different than the information officially reported as profits and losses for the organization. For example, the project team may spend $100,000 in salaries during a one-year systems development effort; but the tax laws may allow that cost to be depreciated (or amortized) over, say, a period of 5 years. Thus, the organization may report only $20,000 of costs on its tax returns for the year, but the $100,000 in cash is definitely gone. Similarly, the benefits of the new system may look quite different from a cash-flow point of view than from the point of view of the organization's profits and losses as reported to the Internal Revenue Service.

In most cases, it is appropriate to show both an annual and an aggregate cash flow. Your cost-benefit study might produce a table like this for management:

Project X Cash Flow Projections

C.4.2 Return on Investment

Another way of evaluating the costs and benefits of the system is to calculate the return on investment. Suppose, for example, that you invested $110,000 in some stock or real estate and that you were then able to sell it for $160,000. (Note that these are the same figures used in the cash flow example above.) This would mean that you made a $50,000 profit on a $110,000 investment; expressed in percentage terms, this means that your return on investment was 45%.

This sounds better than investing money in a savings bank! But wait; in the example above, that profit did not occur at the end of the first year; indeed, it took 4 years. So this makes the return on investment appear to be approximately 11% per year. Even this is somewhat misleading, though, because it does not take into account the present value of future money. This is discussed next.

C.4.4 Net Present Value

If someone gave you $100 today, you would know what the value of the money was: you would have a good idea of how much you could buy with that much money. But how much is $100 worth if you know that you’re not going to get it for a year? This is known as the present value or the discounted value. The present value of money that you will receive in the future is defined as the amount that you would have to invest today, at current interest rates, in order to end up with the amount specified. Thus, the present value of next year’s $100 is approximately $95.24, at interest rates of 5%.

In general, if we want to calculate the present value of some amount of money (which we will call F), n years into the future, we can use the following formula:

P = F/(1+i)n

where i is the interest rate. Thus, in the example above, the present value of the benefits could be calculated as follows (assuming an interest rate of 5%):

Project X Present Value Calculations

As you can see, this makes financial return on the project much less impressive, but it is much more realistic. To be even more realistic, though, we must realize that future costs need to be discounted in the same way as future benefits. Just as a benefit of $10,000 at the end of the second year is only worth $9070 today, so a cost of $10,000 that will be incurred at the end of the second year represents a present cost of only $9070.

This leads to the definition of net present value for a project: the difference between the present value of the benefits and the present value of the costs. For our sample project, this would lead to the following calculations:

Project X Net Present Value Calculations

Thus, the net present value of the system — today’s value of the profit we expect to get from the system at the end of 4 years — is $34,198.

C.4.4 Internal Rate of Return

The internal rate of return is analogous to the percentage rate that banks, money market funds, and other financial institutions advertise for their savings accounts and other investment opportunities. The internal rate of return (IRR) is defined as the interest rate that would be required in order to generate the cash savings each year (i.e., the benefits of the system, which we have already identified) given an investment equal to the cash expenses that we have identified. In the example above, imagine that we had invested a total of $110,000 in a make-believe savings account over a period of 4 years. The question is: what interest rate would we have to earn in order to be able to withdraw a total of $160,000 by the end of the fourth year, with no money left in the “bank” at the end? By comparing this against the prime rate and various other investment rates, management can see whether the new system is indeed a good investment.

Suppose that we describe the future benefits to be achieved at the end of year 1, year 2, ..., year N as B1, B2, ..., BN; suppose also that the future costs are described as C1, C2, ..., CN. Then, the following polynomial formula must be solved for the interest rate, i:

C1/(1+i) + C2/(1+i)2 + ... + CN/(1+i)N = B1/(1+i) + B2/(1+i)2 + ... + BN/(1+i)N

This is not the kind of formula that one can easily solve on the back of a napkin or even with a simple four-function calculator. However, specialized calculators can be obtained with IRR functions built in; also, a variety of special-purpose PC-based and mainframe-based programs exist for this kind of financial analysis. If you don’t have such tools readily available, ask your financial or accounting department for assistance.

C.5 RISK ANALYSIS

As part of your cost-benefit calculations, you should be prepared to carry out a risk analysis for the new system; if management does not ask for one, you should do one anyway. The reason for this is that we cannot assume, with total certainty, that we will achieve the estimated benefits or incur the estimated costs. Things might turn out better than we estimate; of more concern is the fact that things might turn out far worse.

Management will generally want to know what the consequences are if things go wrong during the project; and they will want to know what things can go wrong. Specifically, they will want to know the conditions under which the estimated costs might be significantly higher and the conditions under which the benefits might be significantly lower than estimated.

How could the costs be higher than what you have estimated? Here are a few possibilities; it is up to you to identify specific risks for your own project:

• The computer hardware vendor might go bankrupt.
• The project team might suffer extreme turnover, illness, or other disruptions.
• The technology used for the project might not work as advertised, especially if it is new technology that has never been used before.
• The window of opportunity might be missed; for example, the system might not be ready for installation until January 2, and government regulations might prevent the system from actually being installed until the following January 1.
• Political or contractual problems might arise with unions, outside contractors, and others.
• The project team might not have the required knowledge of the application or might have other deficiencies (inadequate training and experience) that lead to lower-than-expected productivity.
• Turbulent business or economic circumstances might force the project to be canceled.
• A variety of hidden costs might appear, for example, additional overhead or paperwork that had not been necessary in the previous system.

Similarly, the estimated benefits might fail to materialize. Here are a few possible reasons:

• The operational users might find it more difficult than expected to use the new system, leading to delays and disruptions. (This is particularly important if the system benefits were predicated on higher user productivity.)
• Expected improvements in market share might not occur. The system might not produce more customers, more orders, more business, or more revenues.
• The system might not behave as expected; for example, it might not process as many transactions per second as had been expected.
• The value of the new information made available by the system might turn out not to have any tangible benefits.

To deal with these risks, it is often a good idea to put together a worst-case scenario, a best case, and an expected case. The more precise and realistic you can make this, the better: there is no point fooling yourself and your management with unnecessarily optimistic assumptions about costs and benefits. Similarly, though nobody expects the worst-case situation to occur, it is important for management to understand just how bad things could get.

A final note about risk analysis: management will often know of far more risks than you do (e.g., a potential merger between your company and another company that will render the system useless). They can evaluate these risks, and will often not even tell you about them; they need you to evaluate the technical project risks.

FOOTNOTES

1. [1] This is particularly true in some highly competitive industries where new computer systems are developed to provide additional kinds of services to the marketplace (e.g., new banking systems, credit card systems, and airline “frequent flyer” systems).  Thus, your user may not be able to cost-justify such a system on its own merits, but may feel that he or she has to develop it to keep up with the competition.
2. [2] As a senior systems analyst, you are in a position to know this right away, of course.  But to a junior systems analyst, brought into the project after it has been underway for six months, it may not be so evident.  At that point, the project has taken on a life of its own and will fight for its existence independently of the user and any other rational decision-making process.
3. [3] Sometimes this can be minimized if your organization has sophisticated e-mail, videoconferencing, and other “groupware” tools,  in addition to the telephone.
4. [4] There is a hidden cost that you should be aware of: during the conversion of the old database to the new database, it is inevitable that errors will be found.  This is particularly true, as you can imagine, if the existing database is manual and entries have been made by hand; you will find missing data, incomplete data, and data that are obviously incorrect.  The older the data, the more of these errors you’re likely to find.  In addition, the conversion process itself may  be error prone, particularly if it is a manual process.  Thus, there is likely to be a cost associated with data correction.  It is probably a good idea to take a random sample of the existing database to get an estimate of the number of errors that will be found; then estimate the cost of correcting those errors (in most cases, the corrections will have to be made manually).
5. [5] For detailed calculations of this savings, see Capers Jones’ Programming Productivity (New York: McGraw-Hill, 1985).
6. [6] This assumes, of course, that someone in your organization is keeping track of such things.  A landmark survey of nearly 500 U.S. data processing installations conducted by Lientz and Swanson in 1980 suggests that approximately 50 percent of the organizations did not keep track of operational failures in their systems; see Lientz and Swanson, Software Maintenance Management, Reading, Mass.: Addison-Wesley, 1980.