Free University of Amsterdam, Department of Mathematics and Computer Science,
De Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands
Keywords and Phrases: valuation, discounted cash flow (DCF), net present value (NPV), internal rate of return (IRR), payback period (PBP), return on investment (ROI), risk-adjusted return on capital (RAROC), weighted average cost of information technology (WACIT), IT-investment management, quantitative IT-portfolio management, total cost of ownership (TCO), requirements creep, time compression, failure risk, overrun risk.
Anyone with a background in economics knows that there are established tools and techniques to determine the value of proposed investments. Some investments are harder to appraise than others, but continuous research in financial economics is carried out to increase insight in such hard cases. Normally, a business case is valuated using a discounted cash flow (DCF) analysis. Roughly, the cost are subtracted from the benefits, time value for money is taken into account, and risks are dealt with. The outcome of such an analysis is the net present value (NPV), giving the net value in terms of today's money. If the NPV is positive, and a few other indicators are favorable, for instance the pay back period (PBP) is not too long, the internal rate of return (IRR) is not too close to the used discount rate, and if the appropriate variant of the return on investment (ROI) is not too low, you can decide to invest.
Of course, such economic indicators are a model only, and do not need to reflect reality accurately. For instance, during the dotcom hype a loss-generating free-software reseller could have a higher market value than the entire German automotive industry. For those hard cases additional analysis is required, for instance using real option valuation (ROV), where despite a zero NPV still a positive appraisal of an investment can be found due to the value that options can represent. For instance, the stock price of Netscape at the initial public offering (IPO), could be valued at $14 using a very optimistic DCF appraisal, but was set to $28 by its major underwriters. Via an ROV-augmented DCF it turned out to be possible to justify this higher value .
The last few years IT-investments became so substantial that they are attracting the attention of executive management. For instance, it turned out among the large Dutch banks that 22% of their operational costs were attributable to information technology . In fact, IT has become the main production factor for the financial industry, and this pattern is similar in other industries. Moreover, every few years you see the IT-budgets increase with double digit percentages, so it is time for proper IT-investment management. But there is no data, no hope for rapid sustainable improvement, so the worst executive nightmare imaginable, when you need to come to grips with the largest production factor of the firm: information technology. The author is advising large organizations on these problems, and has developed tools and techniques to alleviate some of the problems. The surrogates for real data--public benchmarks--are utilized to obtain an idea of cost, duration, risk, return, and financing of IT-investments, and on these surrogates we base the DCF-appraisals that are necessary to rationalize IT-decision making.
There are not many public documents giving insight into prospective IT-investments. Fortunately, CIO Insight--a business magazine--published a nice IT-investment example [10,9]. We will use and adapt this example to illustrate how you can measure the impact on the firm's share price for a potential IT-investment. We quote the introduction of the example in its entirety:
Amalgamated Widgets, a fictitious manufacturing company with $500 million in annual revenues, was under pressure from its shareholders and from Wall Street to increase its profitability. One possibility considered by top management: Install an online procurement system to cut purchasing costs for just about everything the company buys, from raw materials for its widgets to such commoditized items as safety helmets, work gloves and office supplies, on which the company spends a total of about $225 million a year. There's been a lot of hype surrounding e-purchasing, and the company's executives, ordinarily a pretty conservative bunch, were uneasy about making a significant investment in a new--and, in their minds, unproven--technology. So they asked their CIO and CFO a simple question: How much actual value might such a system bring to Amalgamated's shareholders?
Then the paper explains a standard discounted cash-flow model. The data that were used for this calculation were as follows. The IT-investment was outsourced at a price of $1.2 million dollar. The development time is not given, but in the case study we read that:
Amalgamated's new system would not be up and running for a year because of the time it would take to build and install the system, train the company's purchasing employees, connect the system to suppliers and educate them in its use.
So, development time of the IT-system is apparently not more than 12 months. The operational lifespan of the ensuing system was estimated to be 4 years, and the operational costs were fixed at $610,000 per annum. Additional costs for migration or retirement are for the outsourcer. The cost savings of the project were estimated at zero in the first operational year, $850,000 in the second, $3.5 million in year 3, and $7.4 million in the fourth year . Tax rates are 32%, and the investment cost is deducted over the operational lifetime of the project: a tax break of $96000 per annum (32% of $1.2 million, divided by 4 years). The discount rate that was used is 20%: 10% for the Weighted Average Cost of Capital (WACC), and another 10%, since the history has been that only one in two IT projects at Amalgamated resulted in a return . The risk-adjusted discounted cash flow model resulted in a Net Present Value (NPV) of $2382686, which are the investment's net savings, discounted in today's money using the 20% discount rate. Another given is that there are 23.5 million shares outstanding which implies a positive impact of $0.10 per share, or since the share price was $10, a 1% increase on a single share (we will explain the calculations made later on).
A reliable key metric in economic studies on information technology is the function point metric [1,7,11,23,22]. There are many and diverse ways to recover this metric from information such as the minimal data of our running example. For now, it is not important to understand what a function point exactly comprises, other than that it is a synthetic metric giving an idea of the size of an IT-system. The function point metric can then be used as an IT-currency converter for our economic analyses. For our running example we will show how we can recover the amount of function points. Since we have no full information, we use public benchmarks for recovery of the lacking data. For the sake of this example we assume that the daily burdened rate of the outsourcer is $1000, and that there are 200 working days in a year, each day is eight hours of work. Then the amount of working hours for a $1.2 million IT-investment amounts to 9600. Using this number, we can estimate the amount of function points as follows. First we must find some public benchmarks on average productivity of outsourcers. In [21, p. 274] we find that for 100 function point systems the average work hours per function point is 4.33 hour. For 1000 function point systems this amounts to 10.41 working hours per function point, and for 10000 function point systems this is 27.39 work hours per function point. We used standard parametric statistical techniques to fit a smooth curve through these three benchmarks. Using an implementation in Splus [33,26] of a nonlinear least squares regression algorithm [5,17,33,28], the three observations can be fitted to the following curve:
In this equation hfp is short for hours per function point, and f is the amount of function points. So for a given amount of function points, returns the average work hours per function point. This formula is not a perfect fit, but the residual sum of squares is 0.08664753 (zero represents a perfect fit). Indeed, which is 0.23 off the original data point, , which is 0.18 besides the second observation, and finally , which differs only 0.03 from the original data point. Now the total effort is the amount of function points times formula 1: . Solving this equation leads to an IT-investment of 932.9265 function points according to benchmark. Note that when you are to invest substantially in IT in an outsourcing context, formula 1 should not be used to settle your contract, but for this example it will do. For elaborate information on closing outsourcing deals we refer the interested reader to . This does not dismiss us from the task of checking whether the found amount makes sense.
In the original example , a number of assumptions were made on the prospective IT-investment, and based on them, a discounted cash flow calculation was carried out. We will use benchmarks to derive from our recovered function point size the key indicators necessary for such valuations, and compare our findings to the original example's data.
For a start, we use a few formulas to estimate duration, and development costs derived from industry benchmarks. We took the first 3 formulas from [35, p. 64, formulas (49-51)]. Formula 5 is new.
Formula 2 takes an amount of function points, and returns the number of function points delivered per staff month, so p(932.9265) = 13.74478. Formula 3 returns the benchmarked duration in calendar months for a given amount of function points, so d(932.9265)=12.00456 months. Formulas 4 and 5 are based on productivity benchmarks: formulas 2 and 1 respectively. Both formulas return the total cost of development for a given amount of function points. So, , which is a little less than the quoted investment amount of $1.2 million. Of course, the result of formula 5 will be exactly $1.2 million, since we used its inverse to recover the amount of function points: . Given the complexity of formula 4, we often use formula 5 for recovery activities, and formula 4 for checking the result. The original example assumes a shorter development schedule than we estimated using benchmarked formulas. Namely, development, installing, training employees and suppliers, and connecting the system to the suppliers side is done in 12 months. Note that the original example does not include the costs for these activities, which can be substantial if the number of users is large. Leaving out training cost can mean the difference between a profitable and a loss-making investment. But for the sake of this example, we assume these costs to be zero.
We also want to derive operational costs, and the life expectancy of the system. We do that using the following formulas taken from  and [19, p. 419] respectively.
The minimal cost of operation mco, takes an amount of function points, and returns the minimal operational costs over the entire operational lifetime, so . And this amount is spent in y(932.9265) = 5.526649 years. Notice the large difference between the annual 610000 dollar and our annual 248780.4 dollar. The reason for the high number is that it is a fixed price, including exit and migration costs. For operational costs this is at the very high side, and via rational negotiations this amount could have been less (see  for a way to rationalize outsourcing deals). We will use this lower amount of operational costs in our valuation calculations.
The original example contains a risk premium above the cost of capital of 10%. We will show how you can quantify this risk premium more accurately. First, we need an indication of the chance of failed projects (cf), and the chance of late projects, denoted cl. The following formulas are based on outsourcing benchmarks, and taken from [35, pp. 46 and 48, formulas (30) and (34)]:
Both formulas take a function point total as input and return a number between zero and one as an output. If you multiply that number by 100% you obtain a percentage indicating the chance of failed or late projects. So, the chance of failure is , which is indeed almost 10%. And the chance of serious cost/time overruns is somewhat higher: .
For instance, suppose we have ten projects like the running example, and only half of them deliver a return of at least the profitability threshold of the firm. For the sake of the example we set the return on the failing systems and the WACC both to zero. Still, the net profits need to be much higher to compensate for the failures. Suppose the firm demands an annual return of $2 per invested dollar. For the ten IT-systems, only half will have a return. If that is indeed $2 per dollar, the overall profitability is zero: only one dollar per invested dollar. So the entire ten-system portfolio is then underperforming. In order to have the $2 net return, the 5 systems need to make $4 per invested dollar. So the WACIT is then 50%. In the ideal situation, you need a rich IT-portfolio database to accurately measure the WACIT. In practice, IT-portfolio databases do not contain many data points, so we need to approximate the WACIT. We do this as follows:
Let us explain this formula. We denote the IT-portfolio with P, |P| the number of records in the portfolio, and p represents the information on an individual IT-asset, an going IT-project, or an IT-investment proposal. Normally this comprises of 3 data points: initiation date, delivery date, and cost (planned or actual, or both). Using recovery techniques, like the one we showed with formula 1 (or other techniques, see [35,36]), we recover function point totals. We denote fp to be the function point total we recovered from the information in record p. Then we calculate for each function point total in the portfolio the chance of failure and serious overruns. We can use formula 8, if it concerns an outsourced project, or similar formulas depending on the context. For example, we can use an MIS benchmarked failure risk formula as published in [35, p. 45, formula (28)], for business applications. If we cannot recover function points, we can use alternative formulas in terms of project duration (see, e.g. [35, p. 46, formulas (29) and (31)]). Similarly, we calculate for each element in the IT-portfolio the chance of late projects. Then we take the average, by summing and dividing by the number of entries in the IT-portfolio database. You can use this number as a premium on top of the WACC. So the discount rate to use in discounted cash flows is .
If you cannot perform a quantitative IT-portfolio analysis to approximate the WACIT, here are some alternative techniques. If you are to act risk-averse, you could use the 80% as indicated by Standish, but we have never seen WACITs that high. You can also use different approximations. For instance, the average size of in-house built MIS systems is 950 function points [21, p. 185], and the chance of failure for such projects is 16.48714%, and the chance of serious cost overruns is 18.11008%. We calculated this using the formulas below (taken from ):
So, then the WACIT for an in-house IT-portfolio can be set to 34.59722%. We can do the same thing for an outsourced IT-portfolio. The average size is there 2750 function points [21, p. 269], which yields using formulas 8 and 9: . But of course, no IT-portfolio consists entirely of in-house, or outsourced projects, the portfolios we analyzed contain many small investment proposals and only a few very large ones. To give you an impression, in  a realistic IT-portfolio sample is given. This sample portfolio has a chance of failure of 13%, and a 14% chance of serious cost overruns [35, p. 49]. For that portfolio we take a WACIT of 27%. A final rule of thumb for approximating the WACIT is to calculate the individual risks of the investment, add them, and take that as the WACIT. We will do this in the running example, so the WACIT for that investment is: . For the WACC we assume the 10% as in the original example. When additional risks emerge, we adapt the WACIT with an extra premium. But, of course, it is better to carry out an IT-portfolio analysis, and calculate the overall WACIT.
We have now discounted for failures and cost/time overruns. But there are more IT-specific risks that can influence the value of an IT-investment significantly. These risks are the requirements creep risk, and the time compression risk. You can choose to incorporate them into the WACIT, by doing an IT-portfolio analysis to estimate the requirements creep risk at the portfolio level, and the portfolio time compression exposure. But these risks can also accumulate, making the portfolio calculations hard. Instead, we opt for a scenario-based valuation, where we conduct a discounted cash flow analysis for 4 scenarios: one in the absence of requirements creep and time compression, one for each separate risk, and one when both risks are present. Moreover since the risk of failure and cost overruns increases when time compression and/or requirements creep play a role, we add a 10% to the WACIT.
where e stands for effort, and d is again the duration of a project. We use this empirically found relation to estimate the effect of a shorter deadline than would be normal according to benchmark. In Table 1 we can find the numbers for the normal effort and duration. From that we can calculate the constant, let's call it . Using this constant c we can estimate the effort if the duration of the development is different than our technology-driven estimate. Recall that the running example assumed that not only development, but also installing, training, connecting, etc were done in 12 months. Therefore, the time to implement the system is going to be less than 12 months. We conservatively set it to 11 months. Let us now calculate the increase in effort by having an 11 month deadline. This is calculated as follows: e = 99659480/113.721 = 13289.13 working hours. So, 3689.13 additional working hours are required, just to make the deadline of 11 months. The cost per working hour is 125 dollar, which implies an additional cost of 461141.2, yielding a total cost of development of 1,592,391 for the first estimation method, and $1,661,141 if we use the development cost estimation formula 5. We know that the operational costs will probably be higher, since rushing an IT-project seldomly increases the quality of the delivered product. To compensate for higher maintenance costs, more delivered defects per function point, and other risks, we add 10% to the discount rate for a time compression-adjusted WACIT.
So, an increase of 123.9665 function points. This increase has an impact on the development schedule, number of working hours, cost of development, operational cost, the lifespan, the risk of failure, risk on serious overruns, and can induce other risks. We summarized the impacts in Table 1 under the scenario name req. creep. The numbers are found by filling out the formulas for the requirements-creep adjusted function point total.
In Table 1 we calculated various alternatives, where we adjusted for the requirements creep risk, the time compression risk, and their combination. The cost difference between the least risky scenario and the most risky scenario is about 90%. This is why we separated requirements creep and time compression from failure and challenged projects. We need to know whether we should mitigate the risks, and this can be done via DCF appraisals: if the value is too low with a risk, but okay without it, it is worth mitigating it. Of course, this comes at a cost, too, but often a very low cost: a change control board, or a less tight deadline.
We need the business case to obtain an idea of the value of the 4 scenarios. In this section we will use the business case of the original example for calculating the NPVs for the various scenarios.
For the sake of comparison, we display the calculations of the original example [10,9] in Table 2. In the first column the meaning of the numbers in the rows is explained. We have benefits, operational costs (ops.), gross earnings, tax breaks, net taxes, the cash flows, the discount rate of 20%, and the NPV. In the tables to come, we use the same notions in the first column. The other 4 columns show from year to year what happens to the numbers. In the first row we see the expected benefits. In year 1 (Y1), there are no benefits, since this is the investment period. Y2, gives a first small benefit, and this grows to almost ten times more in 2 years to $7.4 million. In the second row the operational costs are listed. The strange thing about this is that also during the software construction phase, where the system is not operational (hence the zero benefits), operational costs are taken into account. In our calculations we will leave out these costs during development, since they are not made. The next row shows the investment of $1.2 million, and no additional investments are necessary, so the rest of the columns are empty (meaning zero). The tax break is calculated as follows in this example: the tax rate is 32%, and for the investment this means a 384000 tax benefit over four years. This is amortized evenly over that time frame leading to an annual tax break of $96000. The net taxes are then calculated by taking 32% of the gross earnings and subtracting the tax break. For the first column this amounts to -195200-96000=-291200. The other cells in this row are calculated analogously. In the next row, we subtract the investment costs and the net tax from the gross earnings, yielding the cash flows: -610000-(-291200)-1200000=-1518800, and so on. In the next row we give the discount factors: (1+0.20)n, for (in the original example these numbers are rounded to 2 digits). In the final row we adjust the cash flows with the rates calculated in the row above it: -1518800/1.2=-1265667 etc. If we total the annual present value we obtain an overall NPV of $2382686. The example assumed 23.5 million outstanding shares which leads to a 10 cent impact per share.
In Table 3, we display similar calculations as in the original example. Based on our quantitative analysis we found different numbers for development costs, different operational costs (much lower than the original example), a longer expected lifespan of the operational life of the proposed investment, and different discount rates. A longer lifespan implies potential longer benefits. For the sake of ease, we assumed a sustainable profit once the full cost savings of $7.4 million is reached in year 3.
The first row represents a time line in years, the second entry in this row is not a year, but is taken to be the development time (coincidentally a year), then we see five 12-month periods, and the final entry does not comprise a total year as well: 0.526649 of a year, which is the remaining fraction of the benchmarked lifespan for this scenario. We separated the investment period from the operational period. In the development period there are no operational costs, since the system is not operational. This means that these costs will only be taken into account after the system is operational. The tax benefits on the investment are amortized over the entire life cycle: development time plus operational phase. For the rates we used (1+r)t+d/12, for ; where d is the development time in months, r is the rate, and y is the operational lifetime.
Tables 4-6, represent the same calculations as the scenario 1 case, but with different input parameters. Table 7 summarizes the cumulative NPVs and their impact per outstanding share for the original example, and the 4 scenarios. The numbers in the second column are found by summation of the NPV rows in the previous tables. The third column is found by dividing the NPV by the number of outstanding shares (23.5 million).
The original example and scenario 2 (fourth rank) are very close, the original being slightly better off: ranked 3rd. We note that the lower operational costs and the longer operational phase (plus benefits), cancel out the higher fixed price contract and shorter life time. Obviously, if you not only negotiate a better price in your outsourcing deal (see  for help with that), but also take the life expectancy benchmarked operational phase into account, the investment scenario 1 is much more valuable than the original example.
The two lowest ranking scenarios, both suffer from time compression. The often heard business demand for speed-to-market does not pay off in this case, as our quantitative analysis shows. Although the benefits come earlier, the incurred cost and additional risk turn the investment into the lowest ranking one if you look at NPV. This implies that when an IT-investment is time-critical, this will come at a cost. And maybe the cost and risks are so high, that a little bit more relaxed development schedule turns out to be much more valuable. Of course, when market share is at stake, the costs can be justified. The nice thing about analyses like the one we discuss in this paper is that you can now opt for a strategy: if lower value compensates for, say, loss of market share, then a time compression risk should be accounted for. Otherwise, we think it is better to slow down on development, and speed up on value.
The internal rate of return (IRR) is the discount rate such that the net present value in a discounted cash flow analysis is zero. You can use it to see how sensitive the used discount rate is for unforeseen risks. If the used rate is close to the IRR, this is riskier than if there is a certain gap. You can rate different investment proposals to their gap between IRR and the actual discount rate. Or you can formulate a simple IT-governance rule that the IRR should be 30% higher than the discount rate, but the exact numbers should be based on an IT-portfolio analysis of a mature IT-portfolio database.
For the original example, the IRR is 83.4%. We will show how to calculate this rate at which the invested amount of money is precisely expected to come back. For the original example this amounts to solving the following mathematical equation:
You can use a spread sheet program and find the rate r by trial and error. We used the computer algebra system Mathematica  to solve this equation. For that you have to give the computer algebra system a first guess. In all scenarios we used r=0.5 as an initial value, which converged to a solution. The outcome of this exercise is r= 0.833688, so indeed 83.4%. We did not use pure years in the other four scenarios, but the development time di, for scenarios , and in the last time period we used the expected operational lifetime: yi, for scenarios . As an example we give the equation for scenario 1:
We solved equation 15 using Mathematica. The rate turns out to be 1.32909, so the IRR is 133%. In Table 8 we summarized the used discount rate, and the accompanying IRR for all the scenarios. The difference between the used discount rate and the IRR gives you an impression how much risk you can take before the net present value becomes negative. According to our simple IT-governance rule, all scenarios are okay. But of course, IRR is not the only indicator, and the next section shows another important one.
The payback period is the time it takes for an investment to become cash flow positive. It is an important economic indicator providing insight in the time it takes before value creation can commence at all. A related number is the break even point: the amount of money that is invested up to the time of the payback period. In , we defined the payback period risk which is the risk that the payback period is so long after the initial investment that the chance the environment has changed is substantial. This implies that you probably have to invest more before you can create value with the investment; this in turn will prolong the payback period even further, up to a point where a positive cash flow is never generated. Sometimes the phrase hockey stick effect is used for this phenomenon, referring to a J-curve on the side, so no positive cash flows will ever emerge (we will come back to J-curves later on). Mitigating this effect by only allowing short-term value-creating investments is usually not recommended, since long-term investments are opportunities enabling sustainable growth and business continuity. Therefore a balance between long-term and short-term investments is necessary. Finding such a balance is out of scope for this paper; it comprises an IT-portfolio analysis  and more.
We will calculate the payback periods of each scenario, and compare them in terms of the payback period risk. For the original example, there are no benefits when development ends, but one year after its launch, the benefits are $850000, and so on for the other years. At the end of year 4, the cumulative benefits are $11.8 million. Similarly, at the end of the development period (1 year in this case), we spent $1.2 million, plus 610000 on operational costs, accumulating to the end of year 4 into $3.64 million.
We display the cumulative amounts in Figure 1. Along the vertical axis we set out money in millions of dollars, and the horizontal axis represents elapsed time in years. For cash flow rates we assume a smooth continuous rate, which is, in our viewpoint, nicely approximated by cubic splines [2,16]. As an alternative--easier--approximation you can connect the points in Figure 1 by line segments, e.g., using a simple spread sheet program (then you assume linear cash flow rates with intermediate jumps). No matter what approximation you choose, for comparison purposes you need to be consistent and apply one method for all scenarios. The solid spline in Figure 1 is the cumulative benefit curve, and the dashed one represents the cumulative costs. We used Splus [33,26] to derive the cubic splines and to calculate the intersection point, which gives us the payback period and the break even point. For the original example the payback period is 2.7 years, and the break even point is $2.8 million.
An IT-portfolio analysis can reveal how large the risk of long payback periods is, and how it affects the overall created value at the portfolio level. From that you can derive guidelines with respect to payback periods and break even points. For instance, IT-governance rules regarding these aspects could look like this:
According to the above IT-governance rules, the investment plan laid out in the original example should be sent back to the drawing board. For, the payback period is more than half the total lifespan, and the break even point is more than twice the initial investment ($1.2 million). So, having a positive NPV is not necessarily the sole decision making criterion.
Now let us look at these economic indicators for the other scenarios. In Figure 2 we derived cubic splines for scenario 1. The payback period for this scenario is 2.3 years, at a break even point of $1.4 million dollar. So we see that the lower and later operational costs and the longer expected lifespan contribute to a payback period and break even point that are in accordance with the above IT-governance rules.
We carried out these inferences for all scenarios, and summarized the results in Table 9. We also calculated the data necessary to decide whether or not the scenarios satisfy the IT-governance rules. The original example and scenario 4 (time compression and requirements creep) are not satisfying the criteria. These scenarios should not be approved. For instance, the original example needs a better outsourcing contract, and scenario 4 shows that you need to mitigate both exposures first.
To gain a little bit more insight, we depict in Figure 3 the connection between the break even points and payback periods of the different scenarios. So, for the same IT-investment you can either end up in the upper-right corner: the longest payback time and highest break even point. And with a different scenario, you can be at the lower-left corner: the fastest payback and lowest break even point. The original example ends up in the bad corner, scenario 1 in the good corner, and the other three scenarios somewhere in between. The numbers attached to the dots in the curve represent the different scenarios. Depending on the business landscape you can opt for a good, bad or ugly scenario. But then at least you have an idea of the potential economic implications.
If we subtract the benefit spline from the cost spline, we obtain the characteristic J-curve: showing the net cash-flow over time. The payback period is then the intersection of the J-curve with the horizontal axis. In Figure 4 we displayed the J-curves for all scenarios.
It is hard to see differences between the various J-curves--they all dive under zero for some time, and then resurrect and move up. Note that the solidly plotted J-curve ends at year 4. This is the original example. The other scenarios have longer tails, since a longer benchmarked life cycle was assumed. We already gave more insight in the payback periods by showing the serpentine line in Figure 3. It is also interesting to understand the maximum negative cash flow, and when the largest negative flow is due. This amounts to finding the minimum of a J-curve. We approximated these points numerically using Splus. In Figure 4 we plot those points, and we summarized their numerical values in Table 10.
To gain more insight in these numbers, we plotted another serpentine line in Figure 5. This wavy line shows that for scenario 4 most money is burned in a short time frame: more than 2.3 million dollar negative, in 1.2 year. Indeed this scenario suffers from compounded requirements creep and time compression risks. Then the original example is next with a maximum negative flow of almost 2 million dollar. but it takes slightly more time to burn that. Then scenario 2 follows: about 1.7 million is the lowest point, which is like the other time compressed scenario burning the fastest of all other scenarios. Then follows scenario 3 with an even less negative minimum, taking more time than all the others, except the original example. Finally, scenario 1 has the lowest negative cash flow, which is reached at almost the same time as scenario 4. Knowing the low end of the negative cash flows is important, since when the business case turns out to be not as solid as expected, it can be the case that no or much less value creation will be created after the IT-investment has become operational. A very low negative cash flow takes then substantially more time to recover than otherwise, since you have to recover more costs.
The return on an investment (ROI) is defined as its net benefits divided by its total cost. Although this is a simple metric, there are more sophisticated variations of the classical definition necessary for IT-investments, due to the high risks involved.
You can risk-adjust benefits, the necessary capital, or both leading to the variants RAROC, RORAC, and RARORAC. RAROC means risk-adjusted return on (economic) capital. RORAC is the return on risk-adjusted (economic) capital. RARORAC is the combination: risk-adjusted return on risk-adjusted capital. We will restrict ourselves to a discussion of ROI and RAROC, and not dive into financial risks (is the money borrowed by a bank, or via a venture capitalist?), since this is out of scope for our paper. Needless to say that if an appraisal of an IT-investment proposal involves a financing strategy that bears financial risks deviating from the nominal WACC, you should risk-adjust for that, too.
To calculate the ROI for the original example, we took the necessary data from Table 2. We accumulated the benefits (11750000), and costs (3640000), and subtracted them for the cumulative net benefit, which is $8110000. The NPV is also taken from this table: $2382687. We discounted the cumulative costs with a rate of 10%, leading to an NPV of the costs of $2579232. Now the ROI is the division of the cumulative net benefits and the cumulative costs: 8110000/3640000=2.23. The risk-adjusted version that we use takes the NPV of the benefits, and the NPV of the costs, and divides that. This leads to a RAROC of 2382687/2579232 = 0.92. In the original example a discount rate of 10% was used for the benefits, and we used the same rate for the costs. We summarized these numbers in Table 11.
For scenarios 1 to 4, we used a slightly different approach. We used different discount rates: for the NPV of the benefits we used the WACC plus the WACIT, and for the costs, we only used the WACC. This is because the benefits bear an IT-risk, whereas the cost of capital is assumed to satisfy the normal criteria of riskiness, so that we can use the WACC-rate. Of course, when the cost of capital is also bearing additional risk (maybe via venture capital, or expensive up-front financing constructs) the discount rate for capital should be adapted accordingly.
We summarized the results of these calculations for all the scenarios in Table 11. An issue that is worth mentioning, is that the difference between ROI and RAROC is substantial. This shows in a quantitative manner the risk profile of IT-investments. For scenario 1 this differs by a factor of more than 5. We also see that the original example has a very low RAROC, but still higher than the time compressed and creep exposed scenario 4. To gain more insight in the various scenarios we will show a connection between RAROC and the payback period.
Our valuation approach is based on the cash-flow predictions by the business, and benchmarked relations regarding costs, durations, and risks. Until now, we investigated different risk scenarios and their impact on the value, by varying the IT-side of the equation. Indeed we found these scenarios will affect a valuation significantly. In this section we explain how we vary the business-side of an IT-valuation.
For a start, it is important to know the difference between the estimated benefits and the actuals so that we can adapt the proposed business case with this factor. We call this the ROI IT-portfolio's organization-wide fantasy factor, abbreviated RIPOFF. This is the factor with which the estimated benefits differ from the actual benefits. If you have historical data, and a good reporting system, you can measure the RIPOFF. Namely, the IT-investment plans project certain benefits, and by measuring the IT-performance of the materialized IT-assets, the actual benefits are known, and their quotient is the RIPOFF. Unfortunately, this is an ideal situation so you have to approximate the RIPOFF. For instance, by looking at a few large investments and their estimated and actual value creation. Or you can define a simple IT-governance rule stating that a business case should be beneficial even if we divide the benefits by 2 (but this has its own issues, as we will see later on).
Even without proper data, you want to know how sensitive an IT-investment is to lower returns than projected. To obtain an idea about this, we use a similar idea as calculating the internal rate of return. There we calculated the discount rate for which the NPV becomes zero, and compared it to the original discount rate. This gave an idea of the sensitivity to higher risks. So, you challenge the riskiness as perceived/used for constructing the information technology. Now we will challenge the business case: by discounting the cash flows with an amount of money such that the NPV becomes zero. So that we can see how sensitive the business case is for disappointing returns. To do this, we need to solve the following equation:
In equation 16, there are n+1 time units , cash flows ci, , and r, is the used discount rate. For all i, where ci contains nonzero benefits, we take Ri=R, and for the other i, we set Ri=0. So, for the original example, equation 16 is instantiated as follows:
The discount rate is r=0.2. Now we solve equation 17 using Mathematica . Therefore, we have to make a first guess, and we used a million dollar for R. The solution with this initial value for the root finding algorithm is then: R=1355879.6. We correct for the tax rate leading to 1355879.6/(1-0.32) = 1993940.5million dollar per year. If we miss this amount of benefit per year the NPV will be zero. The estimated cumulative benefits for this investment are 11750000, and the zero NPV benefits are this amount minus 3 times the 1993940.5, which is 5768178.4 dollar. This means that the RIPOFF should be smaller than 11750000/5768178.4=2.037. In other words, if the business is exaggerating with a RIPOFF of 2, and you correct for that in the business case, then the investment is doubtful.
For the first scenario, equation 16 looks similar:
In equation 18 we use the discount rate r=0.3473669. Again, using Mathematica, we find that R=2254359.1 dollar, the tax corrected R is then 3315233.9 dollar. If we subtract this amount per year plus its appropriate fraction in the last year, the NPV will turn out to be exactly zero. Since there is 5.526648671 years of operational life, we have a cumulative R of 18322133.0 dollar. If we subtract that from the estimated cumulative benefits (30447200), we find 12125067 dollar, and the RIPOFF should not exceed 30447200/12125067 = 2.511. So in this scenario, if the business is boosting its proposals with a fantasy factor of 2, then still this scenario will have a positive NPV, so this scenario is less sensitive to disappointing benefits, than the original example.
We summarized the results of the maximally permissible RIPOFFs for all scenarios in Table 12. According our fictitious IT-governance rule that the zero NPV RIPOFF should not exceed 2 you can conclude that scenarios 1 and 3 are acceptable, that the original example is at the edge of being acceptable, and that scenarios 2 and 4 are not acceptable.
Equation 19 expresses that if the estimates are at all times exactly a, the estimating quality factor becomes infinite. So, in practice, the closer an estimate approximates the actual value, the higher the EQF will become. You could use this trick to prevent people from compensating for this governance rule, since it will in the end be exposed by the estimating quality factor for the RIPOFF, which is what the incentive is based on. Apart from this potential side-effect, we think that the RIPOFF calculations give a good impression of the sensitivity for a business case for disappointing returns.
In this paper we illustrated how you can appraise IT-investments. We explained our approach using an existing published IT-investment proposal, and we adapted and extended this example to illustrate how to obtain the most prominent quantitative aspects of estimating net tangible benefits of IT-investment plans. Our approach extends existing methods known from financial theory on the one hand, and on the other hand makes use of quantitative IT-portfolio management to supply important input to conduct the economic calculations. Importantly, based on minimal data points, we are still able to carry out a credible financial analysis of the costs, duration, and financing of IT-investments, based on benchmarks. Moreover, we use benchmarks to risk-adjust costs, durations, and financing of such investments. Thereby, we are in a position to provide insight into the standard economic indicators: net present value, internal rate of return, return on investment, its risk-adjusted variants, the payback period, break even points, cost-benefit analysis over time, J-curves, and comparisons of different risk scenarios. We also addressed the idea of discounting the projected benefits, and obtain an impression of how much lower the benefits can become before we have a bad investment. We think that this paper brings us one step closer to a common practice of IT-investment management.
Measuring application development productivity.
In Proceedings of the Joint SHARE/GUIDE/IBM Application Development Symposium, pages 83-92, 1979.
Numerical Analysis and Computation Theory and Practice.
Software Engineering Economics.
Prentice Hall, 1981.
Stock Market Valuation with Real Options: Lessons from Netscape.
European Management Journal, 20(5):512-526, 2002.
Statistical Models in S.
Wadsworth & Brooks/Cole, Pacific Grove, CA, 1992.
Controlling Software Projects - Management Measurement & Estimation.
Yourdon Press Computing Series, 1982.
Function Point Analysis.
Prentice Hall, 1989.
Nederland in de grote dynamiek van electronisch betalingsverkeer: Demarreren of bijblijven? - Internationale ICT-toets bancaire sector 2000: electronisch betalingsverkeer.
Technical report, CMG Finance, 2001.
For the Ministry of Economic Affairs of The Netherlands. In Dutch.
How Amalgamated Widget Determined Its Benefits Stream, 2002.
How to Determine the Value of a Project, 2002.
Function Point Analysis - Measurement Practices for Successful Software Projects.
Probability Methods for Cost Uncertainty Analysis - A Systems Engineering Perspective.
Marcel Dekker Inc., 2000.
Retrievable via: standishgroup.com/visitor/chaos.htm (Current February 2001).
CHAOS: A Recipe for Success, 1999.
EXTREME CHAOS, 2001.
Numerical Methods for Scientists and Engineers.
McGraw-Hill, 2nd edition, 1973.
Stastical Tools for Nonlinear Regression - A Practical Guide with S-Plus Examples.
Springer Verlag, 1996.
Chaos: The dollar drain of IT project failures.
Application Development Trends, 2(1):41-47, 1995.
Assessment and Control of Software Risks.
Estimating Software Costs.
Software Assessments, Benchmarks, and Best Practices.
Information Technology Series. Addison-Wesley, 2000.
Reliability of Function Points Measurement - A Field Experiment.
Communications of the ACM, 36(2):85-97, 1993.
Improving the Reliability of Function Point Measurement: An Empirical Study.
IEEE Transactions on Software Engineering, SE-18(11):1011-1024, 1992.
IT Portfolio Management: A Banker's Perspective on IT.
Cutter IT Journal, 16(4):34-40, 2003.
9210: the zip code of another IT-soap, 2003.
Basics of S and S-Plus.
Springer Verlag, 2nd edition, 2000.
Information Technology Investment Management - A Framework for Assessing and Improving Process Maturity, 2000.
Mixed-Effects Models in S and S-PLUS.
Springer Verlag, 2000.
IT Value Chain Management - Maximizing the ROI from IT Investments, volume D10 of Digital Publications from The Information Economics Press.
The Information Economics Press, New Canaan, Connecticut, USA, 2003.
Metrics: Problem Solved?
Measures for Excellence - Reliable Software on Time, Within Budget.
Yourdon Press Computing Series, 1992.
A Data verification of the Software Fourth Power Trade-Off Law.
In Proceedings of the International Society of Parametric Analysts - Sixth Annual Conference, volume III(I), pages 443-471, 1984.
Modern Applied Statistics with S-PLUS.
Springer Verlag, 3rd edition, 1999.
Getting on top of IT, 2002.
Quantitative IT Portfolio Management.
Science of Computer Programming, 45(1):1-96, 2002.
Quantitative Aspects of Outsourcing Deals.
Science of Computer Programming, 2004.
To Appear. Available via:
Cambridge University Press, 4th edition, 1999.