As you remember, we have calculated our benefits (financial, strategic impact, technological impact, and organizational impact) earlier in the planning process and, by now, you'll have your project schedule and your estimates of people costs.
As shown in Figure 16.2, the cost and return (benefit) estimates will be initial estimates that, as your project proceeds, will be refined as your estimate accuracy improves and you select your final development option or scenario and technology.
Figure 16.2. Cost “benefit and project lifecycle
Again, as for benefits analysis, most organizations have specific guidelines for costing models, so we'll examine the basic framework for costing ROI in this chapter.
There are some fundamental issues that you should consider before you commence your ROI analysis.
ROI and Risk
The impact of project risk on ROI is simple but important. As in other investment decisions, the higher the risk of the investment, the higher the ROI the investor would expect.
Many organizations use different hurdle rates  or discount factors depending on the risk of the project. For example, if the project was assessed as low risk, a low-risk discount rate such as the 10-year government bond rate (around 6% “10%) would be used. If the project is assessed as a medium risk, a rate of 150% the low risk rate would be applied. For high-risk projects 200% of the low risk rate (16% “20%) would be applied to the present value calculations.
The risk weighting of discount rates is organization-dependent but, whether the organization has such guidelines or not, the project manager should ensure that the risk of the project is reflected in the ROI calculation.
Sensitivity Analysis and ROI
As we discussed in Chapter 13, it is impossible to produce an accurate single-point estimate for effort and costs. As a result, it is preferable to state estimates in three ranges:
The optimistic estimate would be based on everything going better than expected, the realistic estimate would reflect the likely situation, and the pessimistic estimate would be based on the worst case scenario.
At the beginning of a project, it is essential that the costs and benefits be presented using a similar model. As a result, you develop the following matrix for ROI:
A high-risk project should be justified on worst case benefits and worst case costs, whereas a low-risk project would be justified on best case benefits and best case costs.
Benefit Curves and Calculation Periods
This is a complex and, generally, organization-specific issue. However, given the life-cycle model of project management advanced in this book and the need to estimate the ongoing support costs for full added-value analysis (see later), the need to determine an appropriate support and investment period and the impact of technology and rates of competitive change is very important.
In traditional accounting practice, payback periods were determined by considering factors such as taxation depreciation rules currently in force, the expected useful life of the equipment, and similar factors. In addition, consideration was often given to the financial situation of the company. For example, a company that had a policy of immediate payback to shareholders would often give priority to projects with shorter payback periods and as a result would set arbitrary limits such as "All projects must pay back in two years to be considered viable."
Some organizations have fixed rules such as "All projects must pay back in two years or less" and others vary the payback calculation period by the technology involved (e.g., PC projects are calculated over three years, minibased projects over five years, and mainframe projects over seven years). As shown in Figure 16.3, these simplistic models are not realistic and, in general, the project ROI calculation period should be contingent on the nature of the project, the proposed benefits and benefits curve, and, in some projects, the technology.
Figure 16.3. Alternative benefit curves
There are three basic benefits curves:
If, for example, a two-year ROI rule is in force, the projects with long-term benefits curves would not be viable, yet the organization could have a substantial payback of benefits in the third year.
The selection of ROI calculation period also has an impact on issues such as strategic planning. For example, a project with a strategic impact of five years out would probably not begin to pay back until after five years. The benefit curve would again be similar to that in Example (c) in Figure 16.3. If the organization had a two-year payback rule, many strategic projects would not be approved.
The estimation of support costs is extremely difficult but critical for professional ROI analysis. The effort and cost of support work is highly dependent on the delivered quality of the system or product.
The first issue in accurately estimating and tracking support costs is to clearly distinguish among support, development, and enhancement work.
Any activity that alters (adds or subtracts) the system's data, function, technical infrastructure, or documentation is treated as a project or, as it is more commonly known, an enhancement project. The maintenance of the system at the status quo is production support and includes the following categories of work:
Many organizations simply track support work as a single category (with some tracking of system education and consultation via a help desk). In fact many organizations include small enhancements as support work. In both cases, the real cost of support and the delivered cost of quality cannot be determined, as all the categories of postimplementation work are mixed together. Later in this book, we revisit the support issue.
Based on metrics kept by some of our clients, if the real support work is recorded and separated from enhancements, the following costs are a reasonable rule of thumb for systems that are of average quality:
Of course, these percentages are indicative and the relative effort or cost across the categories depends on many factors. However, to develop a first-cut ROI that includes support costs, you could assume that the estimated ongoing support costs should be equal to the estimated development costs.
For example, if a system is estimated to cost $1,000,000 in development and it is estimated that the system will be in production for five years, then the estimated ongoing support costs would be $1,000,000, or $200,000 per year. Of course, detailed tracking of actual support costs would quickly confirm these initial estimates.
All enhancements to the production system should be treated as new projects and be subject to ROI and project value analysis as a stand-alone project.