Develop Cost and ROI Scenarios

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.

ROI Fundamentals

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 ^[2] 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.

^[2] A hurdle rate is generally a rate of return set as a minimum that all projects must return to be viable . It is set to some other investment benchmark such as investment in low risk shares, for example.

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:

• Optimistic or best case,

• Realistic or likely case, and

• Pessimistic or worst case.

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:

• Best case benefits ”Best case costs. This is the optimal result: The project meets the best case of costs (i.e., the lowest ) and the best case of benefits (i.e., the highest).

• Best case benefits ”Worst case costs. The project meets the worst case costs and the best case of benefits.

• Worst case benefits ”Best case costs. The project delivers the worst case benefits, (i.e., lowest) and the best case (or lowest) of the costs.

• Worst case benefit ”Worst case costs. This is the least satisfactory result.

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."

You Are Not an Accountant

The analysis of costs is highly specific to an organization. Always consult with your finance or accounting gurus in this step of planning. They are the experts; you are the integrator.

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:

• Recurring: The benefit is permanent and grows over time. The most common example of this type of benefit is staff reduction, in which the salary and other cost savings are permanent.

• First-to-market: The benefit is essentially a one-off until competitors match the product.

• Strategic: The benefits are long-term and dependent on a long- term take up by clients .

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.

Support Costing

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:

• Defect repair: The correction of errors in the delivered process, data, function, or documentation.

• Performance tuning: The alteration of process, code, or data structures to improve response times, execution efficiency, and data communications use.

• Perfective maintenance: The engineering or restructuring of existing process, code, data, and documentation to make it easier to maintain.

• Adaptive maintenance: The expansion of data size , alteration of calculation variables (that were correct but need to change), "cosmetic" alteration of screen, and input and output layouts that do not require new data.

• System education or consulting: The provision of help and advice on how to use the production system.

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:

• Development costs: 30%

• Enhancement costs: 40%

• System supports: 30%

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.