Solution Matrix Limited has worked with many dozens of CIOs, IS/IT directors, and financial executives, worldwide, building the business case for planned IT actions and acquisitions. This article presents some practical findings from this experience—proven techniques for bringing credibility and accuracy to the IT business case.
These managers started with a wide range of personal motivations and needs. Some focused on getting funds for specific IT projects, others wanted high level “buy-in” for strategic decisions, a few needed to justify their stewardship of IT money over the last few years. What they had in common was a need to build an accurate, credible business case. Most had already developed positive ROI figures of their own before we started working together (few had started out expecting to show a net loss). To an individual, however, they reported frustration in trying to “sell” the business case inside their own organizations. Few were truly comfortable with their own ability to estimate IT costs and benefits in advance.
A short list of what it takes to produce a good IT business case holds few surprises:
- The business case author needs to be:
- Thorough (track down all possible impacts, costs, and benefits),
- Clear and logical (articulate the cause and effect chain that leads to each cost/benefit impact)
- Objective (unbiased, including everything that is material, good or bad)
- Systematic (have good models and rules for finding and summarizing values).
- Financial talent also helps as does a solid grasp of the interplay between IT capacity, service levels, user needs, and IT resource requirements.
Intelligent managers appreciate this much already and—as you know if you’ve heard from the IT consulting community lately—there are methods on the market claiming these virtues. Yet IT ROI figures still fail to “come true,” still raise cries of “Soft Benefits!” and still fail to instill confidence in senior management. Why? What can be done about it?
Following are nine key contributors to business case success—requirements for success in many cases—that are not always present. If you have ever proposed an IT investment and then failed to gain approval, or failed to deliver expected returns, you may find here just what was missing. If you are about to propose an IT acquisition or action, consider carefully how you would address the issues behind each item.
The nine keys below can be used with most good approaches to business case building. They are especially applicable, however, with the business case structure and content presented in Business Case Essentials (www.business-case-analysis.com/business-case-essentials.html).
- Key 1: Recruit and use a reference group
- Key 2: Agree on the cost model for the IT business case
- Key 3: Include all the benefits
- Key 4: Try to value every important IT benefit in financial terms
- Key 5: Understand the difference: Full value vs. Incremental scenarios
- Key 6: Put your analysis into the long term view
- Key 7: Keep individual risks in view
Key 1. Recruit and use a reference group
Don't do it all yourself
If you are preparing a business case for your own management, and your own organization is the primary beneficiary of the proposed technology, it is tempting to take sole responsibility for building the case that will justify it: have your staff find all the costs and benefits, give yourself the job of adding up their cost/benefit lists, and then present the results to your manager or the Capital Review Committee. If you are a consultant building the case for a client, it is also tempting to do the case yourself—to be sure it comes out “right” and to highlight your own expertise and value. There are serious risks, however, in the “solo” approach to building an IT business case.
The problem is the nature of information technology in business today: IT is integral to almost every functional area and IT actions have financial consequences that cross boundaries of all kinds (organizations, management levels, budget categories, planning periods). All of this adds to the reasons for recruiting and cultivating a cross organizational, cross functional “Reference Group” to help you design the case and establish credibility.
This group is not the project team that actually does the hard, time-consuming work (digging into databases, interviewing experts, analyzing workflow in detail, and so on). The Reference Group might be also be called the “Review Committee,” “Steering Group,” or something similar, because it has a very specific “executive” role to play.
When recruiting a Reference Group, try to include IT users and their managers, senior financial managers, and other high level executives directly responsible for the company’s financial performance. Look especially for senior managers in organizations and functions outside your own that will be impacted by your proposal: these people are truly “stakeholders” in your proposal. Also try to include subject matter experts in areas such as finance and human resources.
Add Authority and Credibility and spread the sense of ownership
Here is what the reference group can accomplish for you in perhaps three or four meetings over the course of the IT case-buidling project. The first kind of team contribution is obvious to all:
Add authority and credibility
The Reference Group will help fill in the cost and benefits models with line items and ideas you may otherwise overlook. The team can also bring other critical expertise and information to the table. Their contributions add authority and credibility that will be difficult to achieve if you “do it yourself.” For instance:
- Line managers on the team can help “cost” and “value” the operational impact of IT actions in their own areas (manufacturing, procurement, marketing, sales, customer service, facilities, shipping, etc.).
- A financial expert can help connect the IT business case with the organization’s long-range business plan—a great aid to “sizing” IT contributions to expected business benefits.
- A Human Resources expert can help identify and gauge the “people costs” of the action: job levels, salaries, overhead, training requirements, hiring and relocation, and so on.
- Very senior managers should be able to help prioritize, legitimize, and assign value to any IT contributions to the organization’s strategic business objectives.
That much of the Reference Group’s role is obvious. Some other roles for the team are less obvious but equally valuable.
Spread the sense of ownership
The Reference Group can be the vehicle for spreading a sense of ownership for the business case. Those who get involved with producing a business case naturally develop a sense of ownership for it.
In meetings and discussions, team member contribute to case design and development. Inevitably, it becomes their case coming up for review as well as it is yours. That is an advantage for you, because most people do not want something they work on, and own, to fail.
Communicate rationale and expectations for outcomes
In a competitive or critical setting, your case design methodology and major assumptions will not have to be announced and defended at the same time—if they are worked out early and communicated widely by the Reference Group.
The IT business case report has a lot to communicate, in fact, usually too much to get across in a single reading of a report or a single slide presentation. The Reference Group can serve as an effective communications channel between the case building team and the people and organizations who will be impacted by the proposed IT action.
By opening the communication channel during case building, before the final report is delivered, Reference Group members can help set expectations for the business case results and establish the rationale that legitimizes benefits for the case (see Keys 3 and 4 below). When review day comes, critics may still argue your interpretation of case results, but you leave them little room to question your methods or data, and you avoid critical surprises late in the game.
Provide access to people and data
If the IT action analyzed in your business case has cross functional, cross organizational impacts (and most IT actions do), you will very likely have to check assumptions, research impacts, and gather data from sources outside your own organization. Reference Group members can help “open doors” and direct you to the right people in their own organizations who can provide that information.
Handle criticism and critics
Finally, you may be able to use the Reference Group as an effective tool for handling people who are seriously difficult critics of your proposal. If you face people who fit that description, it may be advisable to bring one or more of them onto the Reference Group at the outset.
The critical word here is "may." You must judge the wisdom of taking this step, based on your knowledge of the individuals in question. As members of the Reference Group, they will have objected and contributed everything they have to say before the final review, assuring them that their positions are “on the record.”
Key 2. Agree on the cost model for the IT business case
Expect the cost questions
You may be writing the IT business case to support a request for a new hardware or software system. You be writing to support a proposed infrastructure upgrade, migration to new operating environment, or for some other action. Regardless of the case subject or purpose, however, those who review the case are no doubt aware that IT actions are famous for bringing so-called “hidden costs.” You can expect critical cost questions like these:
- How do we know the business case includes all the costs we’ll actually incur over the next few years?
- How do we know that alternative options for action are compared fairly?
- How do we keep the lifetime costs of this investment under control? How do we avoid unpleasant cost surprises later?
A good IT cost model for the business case will help you address all three kinds of questions. In fact, one of the first tasks for the case-building team should be to design and agree on the structure of the cost model. A good first task for the Reference Group is to complete and approve the structure of cost model for the business case analysis.
The cost model is important because the link between technology and specific costs (and benefits) is often unclear or hidden, and because you need a rational system for deciding which cost items belong in the business case and which do not.
Build a cost model with self-evident completeness
Cost model objective: Be complete
The first purpose of the cost model is to help the case builder and Reference Group identify all relevant costs for the case and reach a high comfort level that the cost side of the analysis is complete.
A good model shows every possible place to look for relevant cost impacts from the IT action. It clarifies which items and data to omit, as well. Should your IT business case include the cost of user training? Should it include outside consultant fees? You won’t have to anguish over a response if you have already established a cost model that is clear, appropriate, and unquestionably complete.
Cost model objective: Communicate completeness and fairness
The second purpose of the cost model is to communicate completeness and fairness to all who read and use the case.
When a model’s completeness is self-evident and its boundaries are clear, it becomes a vehicle for assuring others that you have been complete, and your case is free of personal bias in deciding what to include and what to exclude. For the cost model example in Figure 1 below, completeness should be self-evident: Anyone familiar with the IT proposal should be able to judge the selection of categories on both axes and agree that each axis covers all relevant categories for that dimension.
Figure 1. A simple sketch of the cost model categories helps communicate exactly which costs are included in the IT business case. The yellow cells in this example represent IT cost categories that are obvious and easily anticipated, while the white cells represent cost categories that are sometimes overlooked or "hidden" when analyzing the full range of IT costs.
When the business case compares alternative IT actions, the cost model can also demonstrate clearly that costs in different action scenarios are compared fairly. The same cost model is used to identify cost impacts in all scenarios. If the choice of cost categories for the model unfairly favors one alternative over another, that should easier to see in the cost model structure, than it would be in simple lists of cost items.
Your IT business case may include hundreds of individual cost items, but you should be able to sketch the cost model in simple terms and use it demonstrate that all the relevant cost categories have been included.
Build the model, identify the costs
Table 1 below is a more detailed version of the cost model in Figure 1. This in fact serves as a generic IT cost model that has proven very useful across a wide range of industries and IT actions. It is a “Resource-based” cost model, because it shows us all IT cost impacts in terms of resources used.
Table 1. An IT cost model that can be adapted to estimate total cost of ownership (TCO) for a wide range of IT actions. Rows represent IT resource categories, and columns represent different kinds of IT life cycle events, or life cycle stages. Each cell holds cost impact items that are planned and managed together, and which may have common cost drivers.
This approach to cost modeling is called "resource-based" cost modeling because the vertical dimension of the model matrix presents all of the IT resource categories to be costed.
- Personnel labor (here divided into sub-categories, “IT Staff” and “Users”)
- Networking and Communications
- Other Resources.
Potential IT cost categories are also represented by the column headings. On the horizontal dimension, cost categories are organized in terms of major kinds of IT life cycle events, or stages:
- Acquisition and Implementation
- Ongoing Change and Growth Costs
A cost model built this way is nothing more than an organized list of all possible cost impacts. The key to its value is in the organization: each cell is a set of related cost items. Items within a single cell are generally costs that change together, need to be managed together, and need to be planned together.
The cost model is in fact is designed to capture “total cost of ownership” (TCO) for the IT action, across a 3-5 year period. Cost categories are included so as to capture “obvious” IT costs (HW and SW acquisition, for instance) as well as IT cost impacts that are real but often overlooked, or “hidden” (such as the full range of personnel cots, or ongoing growth and change costs).
Agree early on the cost model
The cost model sets the rules for which costs belong in the case and which do not. The cost model design, therefore, should be completed before anyone on the case building team begins attempting to project cost or benefit consequences. Once the subject, purpose and scope of your case are defined, priorities on the case building team should turn to designing the cost model.
When the case building team agrees on the appropriate rows and columns for the model and begins to identify some of the cost line items, the Reference Group should meet to suggest any adjustments they feel necessary, than agree and approve the design for the business case.
Use the cost model for management and control
The third purpose of the cost model is provide a vehicle for cost analysis, cost management, and cost control.
The model provides a basis for analyzing IT spending, to ask questions that are not easily addressed with the business case cash flow statement. Once the cost model is completed, we can begin projecting actual cash flow estimates for each cost item, across the business case analysis period—usually 3 to 5 years. The business case cash flow statements will show how cost and benefit projections come together across this time period, but the cost model itself provides another view of anticipated spending that can be very useful for managing and controlling spending.
Besides putting the cost estimates into cash flow statements, we can also fill in the cells of the cost model with the total 5-year (or 3- or 4-year) spending expected for the items in each cell, and then create totals for each cell, each row and each column. Table 2 (below), for instance, shows one company’s five-year cost estimates for an IT infrastructure upgrade, with cell totals and marginal totals.
Table 2. One comapny's 5-year cost projections for an IT infrastructure upgrade. The real value of the model lies in the story told by the marginal totals. For instance, more than 73% of the cost impacts come after acquisition.
Bringing marginal totals into the picture adds to the model’s value as a tool for financial control. Here, marginal totals show costs by IT resource category (vertical dimension) and life cycle stage (horizontal dimension). Several messages from Table 3 stand out. “People costs” (IT Staff and IT Users together) make up 48.5% of the 5-year cost picture, for instance. Post-acquisition costs make up 73.9% of the total cost story.
When planning such a move, the normal temptation is to focus on Hardware and Software acquisition and operation costs (the four cells in the upper left corner of Table 2). Real cost control, however, depends on understanding the implication of these choices on the other cost impact areas , the so-called “hidden costs” of computing.
For examples and more on building and using the IT cost model, see Business Case Essentials.
Key 3. Include all the benefits
There is more to life than cost savings
Usually the easiest IT benefits to find, quantify, and defend, come from cost savings and avoided costs—benefits that appear when the cost analysis under a Proposal scenario is compared to a cost analysis under a “Business as usual” scenario. These kinds of benefits are usually tied more or less directly to various kinds of IT resource usage. The largest business benefits from an IT action, however, often lie elsewhere.
When searching for potential business benefits from an IT action, it is helpful to keep two ideas in mind:
First, "Benefit" should be defined as an outcome from an IT action that contributes towards meeting a business objective of the company or the organization. Reaching objectives has value. Action without a clear business objective in mind does not necessarily have value.
Secondly, when IT actions are first proposed to IT management, in fact, the proposals should clearly identify the business objectives addressed, how progress towards the objectives is measured, and target levels for the objectives.
There are primarily four ways the outcomes of IT actions can contribute to meeting business objectives (and thus qualify as business case "benefits"):
- First, the IT action outcomes may improve efficiency (accomplishing certain work at less cost) or productivity (accomplishing more at the same cost).
- Second, the IT action outcomes may improve the quality or effectiveness of work results (e.g., customer service delivery is improved, product design quality is improved, or advertising is more effective).
- Third, the IT action outcomes may enable people or organizations to innovate, that is, engaging in valuable activities they were not able to do before.
- Fourth, the IT action outcomes may reduce risk (e.g., lowering the risk of service unavailability, lowering the risk of employee accidents, or lowering the risk of losing competitive advantage).
With these two ideas in mind, IT management and IT users are prepared to search for and identify the full scope of potential business benefits from a proposed IT action.
Whose costs and whose benefits belong in the case?
Consider carefully the scope of the case: whose costs and whose benefits are to be included. This is an issue you must settle with your business case audience or reviewers before presenting final results. In any case, the appropriate range of beneficiaries might properly extend further than you initially think. For example:
- In many government IT business cases, the case developer is mandated to consider benefits to the population served, as well as cash inflows and outflows to the IT organizations and agencies involved.
- IT actions in a large health care delivery system may have impacts far beyond the IT organization: efficiency and accuracy of billing and record handling may improve throughout the system, professional service delivery may be better or more timely, the range of services may be extended, system-wide operating costs may be reduced, staff professionalism may be enhanced, and so on.
There is no question that IT actions can have beneficiaries beyond IT itself. However, it is the case developer’s responsibility to extend the scope of beneficiary coverage appropriately, by agreement with case audience or recipients. For this purpose, Reference Group members can play a critical role. The crucial point is that beneficiary scope is not set automatically by defining the subject of the case. Nor does the cost/benefit analysis itself determine where to set the boundaries of coverage.
Don’t omit a benefit because It Is hard to quantify
Using the above characterization of IT action benefits, the case builder must judge which benefits to include and which to exclude from the IT business case. Some "Dos" and "Don'ts" in this regard include the following:
- Do not omit a benefit from the business case simply because it is hard to quantify.
The goal is to quantify beneficial outcomes, either as financial outcomes, or as tangible non financial incomes (e.g., in terms of impacts on tangible key performance indicators).
It may be difficult in some cases to reach agreement on an acceptable quantitative measures of the benefit, but if the outcome truly contributes towards meeting an important business objective, it belongs in the case.
- Do not omit non financial benefits simply because they cannot be given financial value.
An IT outcome may contribute towards meeting an important business objective that is defined and measured first in non financial terms. Objectives for customer satisfaction improvement, or branding, or reduced risks, for instance are usually defined and measured first in terms of non financial but tangible key performance indicators. IT action outcomes that contribute towards meeting these objectives are legitimate benefits for the case, even if they have to be included without receiving financial value.
- Do omit a benefit if it is unlikely or its probability is unknown. If the best you can say is that an outcome "might" contribute towards meeting a business objective, do not include it in case. The presence of "weak" benefits can make the entire case look weak.
Step 4. Try to value every important benefit in financial terms
Which business objectives does the benefit address?
If you assign no financial value to an agreed benefit, that benefit contributes exactly nothing to the financial analysis. Is this really appropriate? Often it is not. The company may invest in technology in order to improve its professional image, improve customer satisfaction, or create a more professional work environment. But how much credit do these benefits deserve in real money? They will contribute 0 to the case financial summary if an acceptable valuation is not agreed.
Consider, for instance, a few strategic objectives at a large commercial bank:
- Increase market share
- Increase revenues
- Move business into more profitable financial services (i.e., change the business model)
- Decrease loan losses
In a large bank, these objectives refer to vary large cash flow streams. If an IT investment improves performance in any, even by just a few percent, the benefits of the IT investment can be massive. A few percent of a very large number is a large number.
Nevertheless, a bank IT director may attempt to cost-justify the investment in terms of cost savings and cost avoidance (displacement of data entry clerks, for instance, or lower expected hiring rates). The latter benefits are smaller but easier to quantify. A good IT business case needs all true benefits of both kinds, but often, the large strategic benefits fall to criticism and get left out. Top-level management may be reluctant to credit IT for reaching strategic business objectives, probably because IT alone may not guarantee the objective.
A new network architecture for the bank might help reduce loan losses, or help sell more profitable financial services (perhaps by providing timely access to critical customer data), but it is not the only requirement for reaching these objectives. Reducing loan losses may also require changes in the way professional staff are trained and managed, or changes in loan decision criteria, for instance, However, if the IT action is necessary for reaching the objective, or if it clearly contributes to getting there, IT deserves some of the credit in the business case. That credit will not show up in the case financial summary, unless the contribution is quantified in monetary terms.
Tactics for assigning financial value to benefits
Not every benefit will be quantifiable to everyone’s satisfaction, but there are some well-tested methods that often work to produce an acceptable value. There is not space to cover these methods here1 but, in a nutshell, many of them are based on strategies for:
- Quantifying the value of the benefit’s effects. For example, a “more professional work environment” (the it action outcome) may have a highly quantifiable effect on such things as employee turnover—in terms of recruiting costs, training costs, and productivity.
- Setting the value equal to the cost of alternative solutions. For instance, a commercial bank loan officer must have access to customer credit histories and other business and economic data. Technology brings that information to the desk within a few minutes. What is the value of that IT benefit? Consider the cost of the next most cost-effective means of getting the same results.
- Setting the value equal to the cost of not providing the benefit.
Do everything you can to quantify every important benefit in financial terms, but include only those that you or your audience can accept with confidence.
Key 5. Understand the difference: Full value vs. incremental cash flow
“Savings,” “Improvements,” and “Increases” are relative terms
IT business case builders sometimes stumble when they discover they are not prepared to answer questions like these:
- Where does a cost savings go in the business case cash flow summary? Is it a positive inflow appearing under “Benefits”? Or is it simply a reduced cash outflow under “Expenses”?
- How should you measure projected improvements in the IT business Case? If engineering productivity is expected to improve by 30% with a new software design system, where does the case capture the improvement?
- How should increases enter the business case? If a new Customer Relationship Management (CRM) system is expected to lead to sale revenues increases of, say 20%, where do we capture those increases? Do we include the expected new sales revenue figures? Or do we include just the increase?
Many IT actions are undertaken for the purpose of saving money, improving productivity, or increasing sales. Notice that saving, improving, and increasing are relative terms. We have to ask: “Savings, relative to what?” Improvements, or increases, relative to what?
The “what” is a baseline scenario, which we call “Business as Usual” (Other case builders may use the terms “As Is” and “To Be” to distinguish between “Business as Usual” and Proposal scenarios). In any case, savings, improvements, and increases will only show up as such if we have two scenarios to compare.
Knowing how to compare two business case scenarios, moreover, requires an understanding of the difference between incremental and full value cost and benefit projections.
Incremental vs. Full Value Cash Flow Projections
Consider the two simple cash flow scenarios shown at left in Table 3 (below). Each represents a different business case scenario, “Business as Usual” or Proposal. These are full value scenarios showing the actual total cash flow values for each benefit and expense item. Sales revenues under the Proposal, for instance, appear at their full value, $150.
Table 3. Cash flow values for several scenario line items, using a full value approach (left) and a full value approach (right). Figures in parentheses are cash outflows.
At the right is an “Incremental” scenario, which shows only the differences or “deltas” between the two full value scenarios. The sales revenue delta is calculated as:
Sales delta = Proposal revenues – “Business as Usual” revenues
= $150 – $120 = $30.
From these projections, it looks like there will be a cost savings in “Customer support” under the proposal scenario. How does the business case author identify and communicate the savings?
One approach is to present both full value scenarios (at left) and describe the differences between corresponding line items on both financial scenarios. We can see for instance, that customer support costs are $20 less under the Proposal Scenario. In the Net cash flow figures at bottom, we can also see that “Business as Usual” is losing money right now, whereas the Proposal scenario looks forward to a net gain.
The case builder can also lead with a different presentation, however, as shown in the deltas at right. This is the “Incremental” approach. The data for each line item are only the proposal changes from business as usual. The customer support delta calls for subtracting a larger negative number from a smaller negative number, giving a positive result:
Service delivery delta = Proposal customer support –“Business as Usual customer support
= ($30) – ($50) = $20
Notice how “Customer Support” costs are positioned differently under the two different approaches. On both full value scenarios, “Customer Support” is an Expense or cash outflow. We know that support costs are lower under the proposal because we can compare scenarios. Under the incremental approach, however, “Support savings” appear under “Benefits” as a cash inflow.
Many people (including your case audience) may look at the full value approach and incremental approach and say “What’s the difference? Don’t both approaches really say the same thing?”
Failure to appreciate the difference is the root cause of many business case confusions. One confusion of course is the question of what to do with cost savings: Do they go under “Benefits” or “Expenses”? More pervasive, however, is the problem of mixed data: case builders often err by including full values for some line items and incremental values for others in the same cash flow statement. This mistake is so easy to make that it is always wise to review your own cases or those of others to be sure that all data are one kind or the other.
Which Approach Should You Lead With?
Which approach is preferred in the IT business case? First, remember that you will have to create both full value scenarios even if you are going to lead your presentation with the incremental approach: the incremental deltas are derived from the full values.
When discussing business case results, however, a discussion focused on the full value approach is generally preferred when:
- The case is meant for budgeting or business planning purposes. Here, you need to see the total magnitudes of line item numbers as well as the difference between scenarios.
- There is no viable “business as usual scenario,” or there are many different proposal scenarios to compare.
- The “cost” side of the cost/benefit case will go into a “Total Cost of Ownership” analysis of its own.
On the other hand, the incremental approach may be more appropriate focus for discussion when:
- The action scenario is viewed more as an investment decision, and management truly wants to weigh costs and expected returns of the action itself, independent of other financial factors in the environment.
- The incremental costs and returns of the action are small relative to total inflows and outflows.
Key 6. Put your analysis into the long term view
Show the timeline
When presented with an IT business case analysis of any kind—ROI, cost/benefit, Total Cost of Ownership, financial justification, or something else—you should look immediately for several key business case elements: a clear statement of case subject and case purpose, the complete cost model for the case, the rationale for valuing benefits (if benefits are included), and a time line.
Figure 2. Projected IT business case results organized along a time line. Those who read the case or make decisions based on its results will want to know when cash flows and outflows occur in the analysis period.
The time dimension should also be visible for individual line item inflows or outflows, arranged perhaps in spreadsheet-like columns or tables. The author may know very well when individual inflows and outflows occur, or when the net impact reaches a “break even” point, but the audience and readers also need to see how they occur in time in order to judge the validity of results and to know best how to apply financial tactics during implementation (reduce costs, accelerate gains, postpone costs, or increase gains).
How long is long enough?
The business case time line extends throughout the whole analysis period—five years, in the Figure 2 example. How long is an appropriate analysis period? Major IT actions usually have cost and benefit consequences that extend across years, sometimes long after the original hardware and software purchases have been written off and replaced.
When an organization chooses a new operating system, or a different database architecture, for instance, the choice may limit or direct IT planning choices through several cycles of CPU upgrades or software versions, a period of impact that covers 3-5 years at least.
Key 7. Keep individual risks in view
Uncertainty is inevitable
Business case results are always uncertain to some degree because they project events into the future. They are estimates based on other estimates: IT cost projections for the next several years may derive from estimated capacity growth, estimated transaction volume, and predicted future prices, for instance. Your estimated benefits may reflect expected business performance, market changes, and competitor actions that haven’t happened yet and which are controlled by many factors.
When you present business case results, your audience—customer, client, or management—will very likely have questions like these:
- How likely are other results besides your main predicted outcome?
- What are the risks to achieving these results?
- What can we do toamximize the results?
A common approach is simply to set higher “hurdle” rates or require shorter payback periods for proposals under consideration. If this is done without an eye on the individual risk components, the accuracy of the business case and the ability to control risk suffer.
Measure the risks
Risk management methods are beyond the scope of this paper, but we can point out here why the case builder will benefit from learning and using well proven approaches, risk analysis using Monte Carlo simulation. In a nutshell, Monte Carlo asks you to identify the important “input” factors (variables) that impact bottom line results, assign minimum and maximum possible values to each factor, and then describe the likelihood the variable will have different values between its minimum and maximum (in statistical terms, describe the probability density function for the input variable).
Monte Carlo’s main output is a probability “curve” such as Figure 3 (below), that lets the business case author make statements like these:
- “We have a 90% chance of realizing a net gain of at least $2 million."
- We have a 50% chance of gaining at least $5 million and a 10% chance of gaining $7.5 million.”
Figure 3. Probability curve from a Monte Carlo simulation analysis on the financial model underlying the IT business case. The curve shows the probability (vertical axis) that cash flow results will equal or exceed a given cash flow total (horizontal axis).
The simulation analysis also let’s you make confidence interval statements like these
- “We are “90% confident that the net results of this investment will be a cash flow gain of $2,500,000 to $7,500,000.
- “We are 50% confident that the net results will total “$4,000,000 to $6,000,000.”
Such statements may be more useful to management than a single “best estimate.” If a gain of $2 million is as a “good” result, and there’s a 90% chance of achieving it, the decision to go forward may be easy. If the action absolutely must return $5 million or more, than a 50% risk may be unacceptable. It is possible to develop this kind of information about overall results only when you know something about individual risk factors.
Should you or your audience believe such results? Like all statistics, of course, the simulation output (the curve in Figure 3) is no better than its input. The “input” to the analysis includes the financial model behind your cash flow projections, and the level of uncertainty that you assign to each assumption. If you can make plausible assumptions about the possible and likely values of individual risk factors, then the resulting results curve is a significant contribution to the validity and practical value of your case.
Sensitivity analysis: What happens if assumptions change?
With or without this kind of risk analysis, however, every business case, however, deserves some form of sensitivity analysis, even if very minimal—perhaps nothing more than a set of best case/worst case scenarios. Sensitivity analysis asks the question: “Which assumptions or input data are most important in controlling overall case results?”
This is usually easy to create once you have completed your “best estimate” business case, if your case cash flow model is in spreadsheet form. The first step is to find out which cost/benefit line items and which individual assumptions or inputs have the most impact on overall results. Once you know which of these largely control the “bottom line” you can create plausible pessimistic and optimistic combinations of the input factors and test their impact on the case outcome. More sophisticated statistical-based sensitivity analyses will adjust results automatically, recognizing that some of your assumptions are correlated with each other (expected inflation rates, price changes, and salary increases might be such an example).
When discussing risk and the sensitivity of your results to different assumptions, you can make the business case a more useful management tool by dividing important risk factors or dependencies into two groups:
- Those completely outside your control.
These might include such things as: the rate of inflation, competitor’s actions, foreign currency exchange rates, natural disasters, acts of war, or government regulation. These factors need to watched.
Management intervention (changes to the implementation plan) may be called for if these factors change in a way that puts the predicted results at risk.
- Those which you can influence or control to some degree.
These might include such things as: skill levels of your professional staff, timely completion of related projects, achieving cost control goals, recruitment and hiring of key individuals, and many others. These factors need to be managed
Key 8. Keep non financial benefits in view
You may not succeed in giving financial value to every benefit
No matter how hard you try to put a value on every IT benefit (see Key 4 above), some will probably remain unquantified, at least in financial terms. Such benefits may include improvements in corporate image, customer satisfaction, or employee morale. These may represent major corporate objectives, and reaching them will no doubt translate into lower costs and increased revenues. Nevertheless, you and your audience simply may not be ready to accept monetary estimates for them with confidence. These benefits will not enter the business case financial summary or cash flow statements, but they may still deserve consideration in the proposal.
If you cannot put a financial value on beneficial impacts, should you say anything about them? We recommend answering “yes” if these conditions are met to your satisfaction: The impact…
• Is real (it is likely)
• Contributes to an important business objective.
• Is large enough to matter.
Make it tangible and connect it to business objectives
For non-financial benefits that meet these criteria, here are some brief guidelines on how to use them effectively in the IT business case.
• Make the impact tangible.
Describe the benefit in ways that can be seen and verified, even if not in monetary terms. You may expect a real “improvement in staff professionalism,” for instance, but you may not be able to evaluate the value of that in monetary terms. You can, however, describe the likely effects of that benefit in other observable terms, such as lower staff turnover, easier recruiting, less absenteeism, or the appearance of the workplace to customers or clients.
• Connect the impact with business objectives and business case results.
Ideally, your business case document should start with an introduction that clearly presents the objectives, opportunities, or problems addressed by the subject of the case. When you identify the non-financial benefits of your proposal, connect them directly to this introductory material, especially in the “Conclusions and Recommendations” section of your business case report or presentation.
• Emphasize the financial or other business value of the objective, even if you cannot assign a known fraction of that value to the benefit.
By taking these steps, you are in simply reminding your readers or audience, in effect, that good business decision making is often more than a simple matter of weighing financial sums.
Key 9. Use the IT business case for management and control
improvement requires experience to every benefit
No matter how well you prepare yourself or your case-building team, your next IT business case will probably not be your best one. The case after that will probably be better—easier to build, easier to understand, and more accurate. Individual and organizational learning are requirements for perfecting the case-building process, and some of that learning has to come from experience.
From repeated trials over time, you will learn how best to refine the cost model and how to assign cost and benefit values to IT actions appropriately for your situation. By consistently using the same approach to business case design, over time, your organization should improve its ability understand and use case results effectively, and with confidence. Unfortunately, too many people and too many organizations begin each case-building project starting from 0.
Validate costs, benefits, and assumptions
One way to learn from experience—and establish a consistent approach to case design and case methods—is to use the case as a financial control tool throughout the lifetime of its subject. The business case that justified an IT acquisition or action can live on, long after the initial decision, as the heart of a powerful tool for managing the consequences of that decision. Expected cash flow items and other elements can be linked into a dynamic business model for tracking, controlling, and measuring IT costs and benefits.
Some specific goals for using the case this way include:
- Validate assumptions.
Cost and benefit cash flow estimates are based on assumptions,in some cases, many assumptions, about such things as future labor costs, business volume, transaction volume, service provider prices, insurance premiums, and so on.
As time progresses, these will almost certainly change from the values assumed when the business case was first delivered. Regular updating of the assumptions underlying cost and benefit estimates will keep cash flow projections more accurate.
- Validate the cost model structure and contentl (see, for example, Table 1).
You will want to pay attention to questions like these: Do cost line items in the same cell really change together? Are they really planned together? Are some rows and columns of the model so insignificant that they can be dropped or merged with others? Are there significant cost categories that were omitted from the original model?
- Validate costs.
Where there is a gap between prediction (the business case) and actual results, determine whether the resource itself was estimated poorly (e.g., underestimating the need for disk capacity) or whether the costing of that resource was off the mark (e.g., not anticipating hardware price changes).
- Validate benefits.
Pay attention especially to the timing of benefits and their actual arrival. Was everything on line and running as planned? Did productivity “ramp up” as expected?
Of course specific figures will be adjusted as plans turn into history but the underlying framework for evaluating the IT business performance impact should not change much over several years. This makes it possible to accomplish many of the objectives discussed in Keys 1-9, above: keeping individual risks in view, reducing costs, increasing gains, accelerating gains, and tactfully keeping your Reference Group and other managers aware of their joint responsibilities in delivering IT business benefits.
Your next steps
The nine keys above can be used with most good approaches to business case building. They are especially applicable, however, with the business case structure and content presented in Business Case Essentials (www.business-case-analysis.com/business-case-essentials.html).