Capital Budgeting: Managing Efficient IT Project Portfolios

Wednesday Mar 29th 2006 by Marcia Gulesian
Share:

See how collaboration among IT, Accounting, and Finance personnel is an important part of the project portfolio management process because issues usually understood best by Information Technology (IT) can influence the bottom line of accounting, financial, and tax reports prepared by other departments.

This is the first in a series of articles that will examine some of the most commonly used decision-making methods for the selection or rejection of individual projects throughout the project portfolio management process. These methods determine whether or not a given project (either proposed or in process) should be included in your next capital budget. After a brief discussion of the economic theories upon which these individual methods are based, I'll cite the rationales for (1) not relying on these theories alone and (2) using as well, and sometimes instead, practical rules of thumb in real-world decision making.

Although no specific background is assumed, a little prior knowledge of project management and corporate finance, including probability theory and statistics, will facilitate your reading of the articles. For those readers wanting or needing up-to-date tutorials on these subjects, the References provide pertinent information. In addition, the appendixes at the end of this article contain supplementary material for the reader interested in further insight into these topics. And, throughout this series, I'll illustrate how commercial, off-the-shelf (COTS) software tools can aid in the management of larger, more complex portfolios. In short, these articles will be about computer-assisted common sense.

Overview

Projects—sometimes a mix of large-scale, mid-size, and small ones—are selected by senior management according to a variety of criteria, by a variety of techniques, and for a variety of reasons. Companies have begun to realize the value of using portfolio management principles and processes to select, prioritize, and manage both internal and external IT projects and the resources to execute those projects. Project portfolio management includes the processes to determine which projects should be started, stopped, or continued and to ensure that the projects selected and prioritized are in alignment with corporate objectives; and once selected, proper allocating resources among the projects within the portfolio to ensure maximum utilization of these resources. The primary objective of project portfolio management is to identify the proper mix of strategic and tactical projects that will enable an organization to meet or exceed the expectation of the organization's investment strategy.

Making investment decisions about proposed or in-process projects would not be a perilous matter if the future could be known with certainty; but, it cannot. In this connection, I'll discuss three separate types of project risk/uncertainty:

  1. Stand-alone risk, which views the risk of a project in isolation, and hence without regard to portfolio effects.
  2. Within-firm risk, also called corporate risk, which views the risk of a project within the context of the firm's portfolio of projects.
  3. Market risk, which views a project's risk within the context of the firm's stockholders' diversification in the general stock market.

As you will see, a particular project might have highly uncertain returns, and hence have high stand-alone risk, yet taking it on might not have much effect on either the firm's corporate risk or that of its owners, once diversification is taken into account.

Diversification (Don't Put All Your Eggs in One Basket)

Corporate diversification involves investing in projects whose returns are not highly correlated with the firm's other assets. With diversification, the poor performance of one project will sometimes be offset by the good outcome of another. The major stated objectives of corporate diversification are to stabilize earnings and reduce corporate risk. (Stockholder diversification occurs when stockholders hold a well-diversified portfolio of many dissimilar companies. There is some disagreement over the benefits of corporate diversification to reduce risk when investors can accomplish the same result more easily.)

The expected rate of return and the standard deviation (a measure of risk or uncertainty) provide information about the nature of the probability distribution associated with a single project or a portfolio of projects. However, these numbers say nothing about the way the returns on projects interrelate. A statistic that provides some information about this question is the correlation (ρ) between two projects, which varies in value between + 1 and - 1. When ρ = +1, the two projects (investments) are perfectly correlated and they rise or fall together; when ρ = 0, they're independent; and, when ρ = -1, the rise of one occurs with a decline of the same magnitude in the other.

Most projects are positively correlated with the firm's other projects, with the correlation being highest for projects in the firm's core business and less high (but still positive) for investments outside the core. However, the correlation is rarely +1.0. This being the case, some of the project's stand-alone risk can be diversified away to determine its within-firm risk.

Examples of IT projects not likely to be highly correlated with one another (and likely to have different risk-return distributions) are:

  • Develop custom-made software internally
  • Develop custom-made software by outsourcing
  • Buy existing generic commercial software
  • Create new Project Management Office
  • Deploy new technology (for example, VoIP)
  • Upgrade network and/or servers

One approach to determining which projects to invest in is to choose a desired level of expected return for your portfolio of projects and then pick those projects that minimize the risk (standard deviation or its square, the variance) of the return on the resulting portfolio. The discussion below will follow this path, which is described mathematically in Figure 1.

Fully understanding these equations is not a prerequisite to reading the rest of this article: Complicated as the equations shown at the top of Figure 1 may seem, they can be modeled fairly easily by using a spreadsheet such as Microsoft Excel. Then, using an optimization tool such as Palisade Evolver (an add-in for Microsoft Excel), you can minimize the portfolio's standard deviation (or its square, the variance) for different rates of return, subject to certain constraints.

The model as stated in Figure 1 is in its bare-bones form. However, you can extend it by adding any number of additional constraints: For example, you may want to add the constraint that your firm cannot spend more on any alternative portfolio than its expected budget. In general, firms will have a hard capital constraint that limits their ability to pursue additional projects that require additional capital. I'll have more to say on this last point—capital rationing—in a future article.

Figure 1: Modern project portfolio selection – Efficient Set Method

Note: I have equated risk with portfolio variance. Actually, the only part of the variance management (and stockholders) dislike is downside variance. There are portfolio optimization models that minimize only the downside variance, but they're beyond the scope of this article. Such methods are, however, described in Chapter 10 of Reference 6.

Figure 2 shows the results of this modeling/optimization process: of the ten proposed projects (A, B, C, D, E, F, G, H, I, and J). Six projects (A, C, D, H, I, and J) have been selected automatically by Evolver because, of all possible portfolios having a mean return of 7.5, these six projects create a portfolio with the minimum variance (shown in cell D21). This optimization is achieved after Evolver repeatedly adjusts the proportion of your capital budget allocated to each project included in the portfolio of projects (as shown in cells G3:G12) until the optimum solution (minimum variance) is reached. These values correspond to wi in Figure 1.

Figure 2: Computer determination of an efficient portfolio

Figure 3 shows the dialog box by which you "link" the Evolver optimizer to the Excel spreadsheet.

Figure 3: Specifying the goals, variables, and limits used by optimizer.

When the optimizer is run for different minimum expected returns (set in cell F17), the model gives you a family of minimum variance points that are located on the solid line (also known as the efficient frontier) drawn in Figure 4.

Figure 4: Graph of possible portfolios: Efficient—blue; Inefficient—maroon

The solid line in the graph shown in Figure 4 represents the efficient frontier or the efficient set and is the result of plotting the expected returns vs. standard deviation for different portfolio weights (wi) found by the algorithm outlined in Figure 1. The dashed line is also derived from the same computation, but for any portfolios on this portion of the curve with a given standard deviation (risk) there is another portfolio on the solid portion of the curve above with a higher expected mean. Figure 4 shows that, as long as there is less than perfect correlation (as long as ρ<1) between pairs of projects, the diversification effect applies; that is, as seen in Figure 2, the standard deviation of a portfolio of many projects is less than the weighted average of the standard deviation of the individual projects. A detailed explanation of this result can be found in Chapter 7 of Reference 4.

There may be multiple portfolios that have the same standard deviation. Modern portfolio theory assumes that, for a specified standard deviation, a rational investor would choose the portfolio with greatest return. Similarly, there may be multiple portfolios that have the same return and modern portfolio theory assumes that, for a specific level of return, a rational investor would choose the portfolio having the lowest standard deviation. A portfolio is said to be efficient if there is no portfolio having the same standard deviation with a greater expected return and there is no portfolio having the same return with a lesser standard deviation. The efficient frontier is the collection of all efficient portfolios.

In general, the area on and to the right of the curve represents all the possible combinations of expected return and standard deviation for a portfolio of any size. For example, in a firm with 36 projects, one portfolio might be made up of, say, 25 projects. Another portfolio, of 18 projects. A third portfolio, a different set of 18 projects. Obviously, the combinations are virtually endless. But, those off the solid line are not optimum, as defined above.

The Devil Is in the Details

The major benefit that Evolver brings is its simplicity of use. The major downfall that it brings is also its simplicity of use. That's because this application is not immune to the venerable axiom: garbage in, garbage out!

In the capital budgeting process described above, you first need to estimate the expected rate of return (μ) and the standard deviation (σ) of the individual projects. Then, you need to estimate the way the returns on these projects interrelate (ρij). With these data, you can construct the efficient frontier of all risky projects.

Unfortunately, estimating these project variables is the involved process of forecasting, where it is unlikely that historical average values will be appropriate. In real life, you never actually know the means, standard deviations, and correlations of future events. So, the experience-based judgment and intuition of individuals familiar with the project (in other words, its technology, resources, and so forth) must be relied on for these figures.

So, using these subjectively obtained values for, say, 40 projects can easily lead to unexpected results. That's because, for one reason, there will be almost 800 imprecisely known correlations between pairs of projects. (Recall the formula: number of relationships among n entities = (n2 - n)/2.

Furthermore, there is another significant shortcoming to the theory presented so far when it is applied to project portfolio management; namely, you have gone to all this trouble on the assumption that the element of time could be ignored. However, because capital budgeting typically deals with multi-period investments, some of which constitute mutually exclusive alternatives, expected net present value (NPV)—the discounted sum of the annual cash flows—should be substituted for expected return as your measure of a project's profitability, and by analogy the variance of net present value—the discounted sum of the annual variances—should be used as the risk indicator. NPV will be discussed at some length in the next article of this series. However, a brief introduction to this topic is given in Appendix A.

And, there's another catch. You've assumed for simplicity that the project's cashflows in successive years are statistically independent. In reality, this is not often the case. For example, when a firm invests in the development of a new software application, success in the first year is more likely to be followed by success in the second year. Similarly, a failure in the first year is often the harbinger of bad news in the second year. Thus, in general, you expect the cashflows of a project across years to be positively correlated. But, typically, this association yields a correlation between any pair of years of considerably less than + 1.

Preference Theory, Utility Functions, and the Like

It may have already occurred to you that nothing in the discussion so far tells you which portfolio among the efficient set to pick. The selection of a particular optimal portfolio from among those on the efficient frontier has to be determined by a decision maker familiar with the firm's attitude about taking financial risk. And, like all human activity, this can be very inconsistent. However, Preference Theory, by taking information about this risk tolerance into account, can be used to modify the equations in Figure 1. Then, when implemented by an optimization tool, this model also serves as a proxy for the psychological makeup of the decision maker.

The modification of the equations in Figure 1 can be accomplished by utility functions; these are mathematical expressions that assign a value to all possible choices. In portfolio theory, the utility function expresses the preferences of economic entities (you or your firm) with respect to perceived risk and expected return.

Rational decision makers are usually willing to accept a lower return to reduce risk when large amounts of money are at stake. These risk-averse individuals or firms then maximize expected utility (expected subjective satisfaction) instead of expected monetary value. One position in the efficient frontier cannot be considered superior to another unless some decision-maker utility is incorporated. Adding utility to the equations in Figure 1 gives you a consistent way to pick the best point on the efficient frontier—you ask your optimization tool to maximize utility.

Established firms tend to be risk averse, for the most part, whereas startup firms are frequently risk seeking. There are no right or wrong answers. Thus, if you are asked what amount you will accept for certain instead of engaging in a lottery involving a 0.5 probability of losing $500 and 0.5 probability of winning $1000, the answer is a personal preference rather than a mathematical calculation. (In a group of fifty individuals it is likely that nearly fifty different answers will be obtained.)

Finding a utility function that leads to the best outcome possible for an individual or firm is a process requiring a good deal of knowledge and experience. Doing so for a group of individuals with different preferences (as in the case of a corporation) is even more difficult. Nonetheless, the decision maker must take both risk and attitudes toward risk into consideration.

Further discussion of preference theory and utility functions is beyond the scope of this article. However, the References include a good deal of material on this subject including how to incorporate utility functions into the equations of Figure 1.

Conclusion

This article discussed the portfolio diversification approach for selecting projects (developed by Nobel-laureate Harry M. Markowitz in the 1950s) and how one implicitly or explicitly uses preference theory (developed by John von Neumann and Oskar Morgenstern in the 1940s) in the process. But, basing your decision on a single methodology is a little like a physician basing his or her diagnosis on just a single symptom (for example, fever, which accompanies both influenza and acute appendicitis). So, just as the physician should consider a number of symptoms when making a differential diagnosis, the corporate decision-maker might want to use the methodology presented above in combination with one or more other methodologies when deciding which projects to include in a portfolio (budget). Subsequent articles will examine some of the other methods commonly used for this purpose.

Finally, the small to medium-size project management office (PMO) may not have the resources to acquire the reliable input data needed for the methodology described above. However, you can sometimes gain valuable insights, after plugging very imperfect data into your spreadsheet/optimizer tools, by thinking about the outputs in what-if terms.

Appendix A: Net Present Value

Net present value (NPV) is a project's net contribution to wealth (or, in the context of this article, the value of the firm). NPV is the present value of future cash returns, discounted at the appropriate interest rate, minus the present value of the cost of the investment. When this model is used in capital budgeting, it is applied to a single project (or portfolio) rather than to the firm as a whole. In brief, the procedure is as described below:

  1. Estimate the expected net cash flows from the project. Depending on the nature of the project, these estimates will have a greater or lesser degree of riskiness. For example, the benefits from replacing a database server used to host a pre-existing data warehouse can be estimated more accurately than those from an investment in a software-development project to produce a new and untried application.
  2. Estimate the expected cost, or investment outlay, of the project. This cost estimate will be quite accurate for purchased equipment because cost is equal to the invoice price plus delivery and installation charges; but cost estimates for other kinds of projects, particularly those involving human resources, may be highly uncertain or speculative.
  3. Determine an appropriate discount rate, or cost of capital, for the project. The cost of capital is considered in a later article of this series, but for now it may be thought of as being determined by the riskiness of the project; that is, by the uncertainty of the expected cash flows and the investment outlay.
  4. Find the present value of the expected cash flows and subtract the estimated cost of the project from this figure. The resulting figure is defined as the net present value of the project. If the NPV is greater than zero, the project should be accepted; if it is less that zero, the project should be rejected. However, as I'll discuss in a future article of this series, there are many exceptions to this rule! In equation form:

    where CFt is the expected net cash flows at period t, and k is the project's periodic cost of capital. Cash outflows (expenditures on the project, such as the cost of buying hardware and software, salaries, and so on) are treated as negative cash flows.

Note: If the cost of capital is expected to vary over time, this fact could be taken into account by designating k as the cost of capital in the tth year.

In the next article of this series, I'll take a look at how a Monte Carlo simulation can be used to improve on the NPV method, which is based on single-figure estimates of cash flows. I'll point out that the NPV method makes some very strong assumptions about the nature of the decision maker's preferences, which in some circumstances may not be justified.

Appendix B: Optimization

Optimization is the process of trying to find the best solution to a problem that may have many possible solutions. Evolver, the optimization tool cited above, is easy to use because an understanding of the complex techniques it uses is usually unnecessary. Evolver doesn't care about the "nuts and bolts" of your problem; it just needs a spreadsheet model that can evaluate how good different scenarios are. You select the spreadsheet cells that contain the variables and tell Evolver what you are looking for. Using Evolver requires only that the user set the variables (the cells which contain values that can be adjusted), the goal (the cell that contains the output), and a description of what values Evolver may use when searching for optimal solutions.

Appendix C:Statistics

A number of assumptions are behind the theory outlined in Figure 1. One, the assumption of normally distributed returns, leads to problems when trying to extend the analysis to longer time periods or to multiple time periods, because long-term returns are usually far from normally distributed. Although mainstream financial theories and applications assume that asset returns are normally distributed, overwhelming empirical evidence shows otherwise. Yet, many decision makers don't appreciate or have the resources to deal with the highly statistical models that take this empirical evidence into consideration. Reference 10 examines this dilemma and offers readers a look at how portfolio selection and risk management can and should be undertaken when the assumption of a normal distribution for asset returns is violated. "Fat-Tailed and Skewed Asset Return Distributions" provides a bridge between highly technical theory and real-world risk management and investments. Although the material in this book is intended more for the investor in portfolios of stocks and bonds than for the investor in portfolios of IT projects, the book drives home the point that application of the Central Limit Theorem—under certain conditions the sum of independent random variables will tend to be normally distributed—to many real-world situations can be inappropriate because the conditions necessary for its application are not met.

Appendix D: Cash Flow

Cash flow from external projects and cash flow from internal projects come about in different ways although, once determined, they are plugged into the formulas for NPV, IRR, and the like in exactly the same ways. External projects, for example software applications sold to one or more outside customers, produce a revenue stream from payments made to the firm. In contrast, internal projects, for example new collaborative computing software for use by a firms sales staff to provide customer service more efficiently, can produce an ongoing reduction in the cost of business operations when the software materially shortens the time required to book an order and, in addition, more time to book additional orders. But, no matter what the basis for the cash flow, factors such as depreciation method, taxes, and inflation rate can affect them both and should be considered in any estimation of future cash flows. These topics are beyond the scope of this article but are covered in detail in References 2 and 3 and briefly in Appendix E below.

Appendix E: Depreciation, Taxes, and so Forth

At acquisition, many tangible assets—including computer hardware and software—are recorded at cost. But, when these assets generate cash flows over several accounting periods as the assets are used in operations, the firm transfers a portion of the cost of these assets to an expense account systematically over the periods in which the firm uses the assets. The amount transferred to expense each period is called depreciation. The objective of the depreciation process is to match the cost invested in the asset with the benefits derived in the form of revenues or savings. Intangible assets such as patents, copyrights, and trademarks—valuable because of the rights and privileges that they convey to their owner—also can produce benefits over several time periods. Consequently, intangible assets are also generally reported at cost less accumulated amortization, which is the term used to describe the amount of cost transferred to expense each period. And, of course, the amounts of these expenses play a role in determining cash flows that are so important in the project selection/rejection process. For a detailed account of U.S. Tax information on this topic, read Publication 946 (http://www.irs.gov/pub/irs-pdf/p946.pdf) ... and talk with your tax advisor.

Note that depreciation and amortization for tax purposes and depreciation and amortization for financial statement purposes do not always match up, as tax codes may differ from GAAP (Generally Accepted Accounting Principles) and FASB (the Financial Accounting Standards Board) pronouncements. Moreover, how you depreciate software for tax purposes depends on how you acquired it (for example, as a package deal along with a computer), how it's licensed (for example, is it governed by a proprietary or open source license?). Some licenses allow you to resell the software (and therefore depreciate it) whereas other licenses do not.

Statement of Financial Accounting Standards No. 86 specifies that the cost of developing and producing computer software products that will be available for sale or lease should be capitalized and amortized over their economic lives. Prior to this standard, all such costs incurred prior to the development of a prototype were expensed, and many small software development companies claimed that this practice understated net income, making it very difficult to attract outside capital.

Finally, the cost of developing software internally can sometimes be considered a research and development cost and either expensed or capitalized and depreciated over several years, depending on its size and length of service (see Reference 12 for an account of how one institution, Johns Hopkins Hospital, treats these issues). In addition, there's another option exploited by many firms: a tax credit. Unlike a deduction, which simply reduces taxable income, a credit is a dollar-for-dollar reduction of your tax bill. But, there are a few catches: The R&D credit is authorized by Congress on an on-and-off-again basis (it's there when Congress thinks it will stimulate the economy), exists in some countries but not others, and requires detailed record keeping and highly-specialized tax expertise to obtain. However, when the size of your software development project is large enough, the benefit to cost ratio can reward you handsomely for your trouble.

Qualified R&D expenditures include direct labor, outside software vendor implementation costs, and so forth. Examples of qualifying R&D activities for a financial institution would include (but are not limited to):

  • Investment in the development of Internet credit security applications (in other words, smart Internet security credit cards).
  • Investment in the development of wireless banking programs (in other words, PDA applications).
  • Investment in the development of a software program that consolidates various branch and account activities into one, new reporting system (in other words, consolidation of bank computer systems for loans, trusts, deposit accounts, and the like).

For most large companies, an Internal Revenue Service (IRS) agent will refer a Research Tax Credit claim to an IRS engineer, whether or not the claim includes internal-use software. The IRS engineer will begin the examination of the claim by getting an understanding of the methodology used in compiling the data for the claim (in other words, project approach vs. cost center approach, type of development activities, and so forth). After reviewing the taxpayer's work papers supporting the claim, the IRS engineer will want to interview the company IT personnel who were directly involved in the development process of a particular project. As a result, it's important to find the appropriate person within your organization who can address the questions posed during the interview. This person needs to explain the project from an overall perspective, including business purpose and competitive information.

Conclusion: collaboration among IT, Accounting, and Finance personnel is an important part of the project portfolio management process because issues usually understood best by Information Technology (IT) can influence the bottom line of accounting, financial, and tax reports prepared by other departments.

References

  1. Kerzner, H., Project Management, Wiley (2006)
  2. Pratt, J., Financial Accounting in an Economic Context, 6th Ed., Wiley (2006)
  3. Williams, J., Haka, S., Bettner, M. Financial and Managerial Accounting, McGraw-Hill/Irwin (2005)
  4. Brealey, R., Meyers, S., Allen, F., Principals of Corporate Finance, McGraw-Hill/Irwin (2006)
  5. Winston, W., Financial Models Using Simulation and Optimization, Palisade (2000)
  6. Winston, W., Financial Models Using Simulation and Optimization II, Palisade (2001)
  7. Baker, K., Optimization Modeling with Spreadsheets, Thomson (2006)
  8. Myerson, R., Probability Models for Economic Decisions, Thomson (2005)
  9. Author's Note: The chapter on Utility Theory is suitable for advanced readers.
  10. Albright, S., Winston, W., Zappe, C. Data Analysis and Decision Making with Microsoft Excel, Thomson (2003)
  11. Rachev, S., Menn, C., Fabozzi, F. Fat-Tailed and Skewed Asset Return Distributions, Wiley (2005)
  12. Laplant, P., Costello, T. CIO Wisdom II, Prentice Hall (2006)
  13. http://finance.jhmi.edu/finance/Forms/FIN024.pdf

About the Author

Marcia Gulesian has served as Software Developer, Project Manager, CTO, and CIO over an eighteen-year career. She is author of well more than 100 feature articles on Information Technology, its economics, and its management. You can e-mail Marcia at marcia.gulesian@verizon.net.

© 2006 Marcia Gulesian

Share:
Home
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved