By Roy Schuster

So given your CRM challenges, how should your organization proceed? A generic, formal ROI Methodology – with a rigid set of steps and hard timeframes -- is unrealistic for most organizations. There is a great variation across companies in terms of:

• What constitutes a business case?
• How much (and what quality) data is available?
• What does the audience for the business case want or expect?

Because of this, a lean and practical approach, guided by the following steps, will work well in most cases, while allowing your team to appropriately tailor an approach to meet the specific needs of your organization.

An overview of the nine steps appears below, followed by a brief explanation of each step.

1. Determine what type of business case approach is appropriate
2. Define a hierarchy of benefits
3. Define rough costs
4. Gather data
5. Take a stab at quantifying what you can, guesstimate the rest
6. Pull it together
7. Present it (warts and all)
8. Define a process to finish the job
9. Institutionalize the “living” business case

1. Determine what type of business case approach is appropriate
You should begin this process by making some choices about how to structure your business case and what sort of financial analysis is appropriate and/or expected by management. Certainly, precedent is critical – you should gather examples of other business cases (successful or not) that have been prepared and presented in the past in your organization. You may also want to gather examples that are readily available from industry analysts, vendors, etc., on the Web. These can give you useful examples and allow you to define an endpoint target for your deliverables. 

The financial metrics used in your analysis will be elements of the business case that will be most remembered and quoted once this effort is complete. Therefore it is important to carefully choose what measures will be used, since, unfortunately, this might be the only thing some people in your audience will remember about the business case project. Some of the key and often-used (and misused) measurements of return include:

Return on Investment (ROI) – the most common metric used, simply the ratio of net gains (benefits minus costs) to the total costs. ROI gives a clear picture of the net gain to the bottom line of your organization, and is useful for comparing two projects head-to-head.

Net Present Value (NPV) – related to ROI, the NPV calculation gives a measure of that net benefit, not in percentage terms, but rather in terms of the value of a series of cash flows (again, net benefit) in today’s dollars. This can be used as an “absolute” value of the project in an overall sense.

Total Cost of Ownership (TCO) – a comprehensive measure of the overall cost of the project, extremely useful for budgeting but less useful for determine go/no-go since it does not take into account benefits. The TCO is a good compliment to ROI, and provides a good way to compare two solutions that will deliver a similar or equivalent benefit.

Internal Rate of Return (IRR) – this measure is basically the rate of return necessary to make the NPV of a project equal to zero. It is useful for determining the value another investment (say, another project your organization is considering, or even just keeping the money in the bank) would need to return in order to be equivalent to the project being considered. 

Payback Period – this measure has been used traditionally to determine how much time must elapse before project “breaks even”, or returns in benefits and amount that equals the expenditures. Payback is not a good measure, on its own, of whether or not to do a project (i.e. you wouldn’t want to evaluate two project and just decide to execute the one with the shortest payback period, irrespective of net benefit). It does provide a good measure of risk, in that a project with a longer payback period is necessarily more risky than one with a shorter payback (especially true when evaluating technology project, as the useful life of technology continues to decline). 

There are numerous sources of information available (in both finance textbooks and in various sources on the Web) about the pros and cons of each of these metrics, and how to appropriately and correctly apply each. We refrain from making a hard recommendation about which is “best” since this is a context-specific decision – depending on the nature of the business solution being evaluated and the particulars of your organization, including risk tolerance, degree of detail expected, past business case precedents, etc. Each, however, gives a distinct and independent view of the project and its projected value. How they are interpreted for the ultimate purpose, decision-making, is up to you.

2. Define a hierarchy of benefits
To provide structure for the task of data gathering that is to follow, it is critical to build a model of the types of benefits you expect or hope to see from CRM. This model, what we call a hierarchy of benefits, should be driven by the desired outcomes previously discussed, but should be more granular and, at its lowest level, be clearly quantified.

An example of a CRM benefits hierarchy (not exhaustive by any means) might look like this:

Revenue Enhancers

• Increase sales effectiveness
• Add new customers at a higher rate
• Offer new products/services
• Provide a better customer experience
• Increase revenue per customer
• Sell more of current products/services
• Offer new products/services
• Improve customer retention

Cost Cutters

• Decrease cost of sales
• More time to sell, less time on admin
• Decrease cost of service
• Cost per service interaction
• Transition to more self service

IT Benefits

• Decrease in system administration cost
• Reduction in training cost

Intangible Benefits

• Management decision-making

Once this hierarchy is complete, you now have the outline for the benefits portion of your business case and a working structure from which to drive the data gathering, interviews, and analysis tasks that follow.

3. Define rough costs
Similar to the previous step, a rough, hierarchical cost model should be defined to serve as a framework for potential costs and the tasks you will need to complete in order to define or estimate those costs. The cost model (again, an example, not an exhaustive list) might look something like this:

Software costs
Package-related costs.

Is the package selected?

No – then use typical costs or ranges
Yes – use list price from the vendor (be conservative to start – a discount might be likely but is not a certainty, and will only improve the business case later)

Supporting costs of software – expenditures required to implement the package, such as database, middleware, operating system, etc.

Hardware costs

• Direct (servers, workstations, mobile devices, etc.)
• Indirect (supporting infrastructure)
• Implementation costs (typical for your organization)
• Internal team
• External services personnel (consultants, product vendor personnel, etc.)
• Assimilation costs
• Process transition costs
• User training
• Business disruption during implementation / cut-over
• Learning curve cost. One should generally include a net reduction in benefits due to learning curve, phase-in approach, etc. This might be presented as a “scale-in” effect, e.g. only 50% of the benefit is achieved in Year 1, 75% in Year 2, etc. 

4. Gather data
In seeking the data to fill in and complete the business case, you must now enter a period of data gathering and analysis. There are a variety of methods to attain the data. The “best” method(s) will be determined by the timeframe you have to complete the task, the level of detail required, and cultural factors within your organization, such as willingness to share data, the responsiveness of key information providers, etc. Some of the methods you might deploy would include:

• Collection/Analysis of raw data
  Performance information on key customer-facing processes might need to be attained first-hand by observation and analysis. Examples would be a time study of how critical personnel in sales or customer service spend their time; definition of the sales process by documenting a “day in the life” of a sales representative and attaching measurements to the individual components of their step-by-step process; etc. This is the most time consuming method, certainly, and may better fit under the heading of a re-engineering or process improvement project than as part of a CRM ROI analysis.  However, for key pieces of data that are critical to the ROI, it may be necessary to undertake this approach.
• Analysis of Reports
  Clearly if key performance data are being measured and monitored in the current environment, analysis of reports is one of the best and most expedient sources of information for your business case. Be sure that this data (1) is understood in terms of its source and meaning and (2) is, to whatever standard seems reasonable, reliable and accurate.
• Interviews
  One-on-one discussions with key managers in relevant areas of the business are often the first step in gathering data. These discussions generally are an effective way to get data directly or find out where that data is and how to acquire it. Also, these discussions often reveal innovations and ideas, from the field, on how and to what degree CRM could benefit the day-to-day business, thus revealing more categories of benefit than your team might define on its own.
• Facilitated sessions
  This approach is generally less effective in business case development than in other projects where elaborating the business strategy or specific requirements is the goal.  It might be useful to use a facilitated session to define the benefits hierarchy, getting group input on what benefits are desired or expected from CRM. However, data gathering itself – attempting to fill in the blanks in the model – is less effective as a group exercise than one-on-one.

5. Take a stab at quantifying what you can; guesstimate the rest
The process of quantifying each benefit and cost associated with your CRM plan of action is the hardest part of the entire process. It requires both estimating skill and the ability to use the hard data available to your team to project likely results. Each item will have a “degree of difficulty” associated with it in terms the process that is needed to come to a solid quantification.

Areas of cost or benefit that are relatively straightforward to quantify:

• List prices for specific purchases needed to support the implementation
• Costs saved due to closing a physical location
• Headcount reductions that result from efficiency improvements

Benefits realized as a non-value-added task or process is eliminated, and the effort associated with that task, can be shifted to a value-added process (e.g. an improvement that allows sales to spend more time meeting with customers, and less time completing administrative tasks).

Areas that are harder, but not impossible, to quantify:

• Gains in revenue due to higher levels of customer satisfaction
  The logic that is usually followed is that a higher level of customer satisfaction will translate into better retention and more revenue per customer. The hard part of this equation is then explaining exactly:

(1) How that improvement will occur (what aspect of CRM will equate to or result in the improvement in customer satisfaction?)

(2) To what degree customer satisfaction will improve and how it will be measured?

(3) The direct effect that the improvement will have on either retention or dollar value per customer (because they are happier with us, how much more will they buy or how much less likely are they to leave us?)

You can see that the logic here is sensible but difficult to quantify without injecting case-study results from other organizations that have already implemented CRM and seeing the corresponding results they have seen in terms of customer satisfaction and sales. 

• Improvements that result from better customer information and hence better management decision making ability:

(1) Any calculation of cost or benefit that is a function of future business volumes or dependent on an unknown mix of products and/or services that your organization may offer in the future.

(2) Any items that cannot be quantified based on real data can be estimated (based on “typical” and/or conservative input parameters). However, it’s very important to (a) identify your guesstimates clearly so that they can be distinguished from the verified numbers and (b) make a note in your business case of what is needed to convert the guess into a solid number. This is important as it defines the “to do” list for your team or outsiders who will need to do follow up work to complete the business case at some point. If the project to define the business case is held to strict project plan, then it’s likely that at the end of the effort, some areas of the business case will be incomplete or in the “to be verified” category. It is important to make those clear and assign responsibility for completion, ASAP, after the end of the formal business case project effort.

6. Pull it together
The “package” that comprises the business case should stand alone and be as self-explanatory as possible. This is key, as the package will be distributed throughout various levels of decision-makers and needs to be as unambiguous as possible. There are four primary deliverable components:

ROI Model – a spreadsheet model that provides the guts of the ROI analysis. Four worksheets should be included in the model:

• Assumptions – A detailed worksheet showing all of the constants or assumptions in your model, with brief explanatory notes as necessary.  Examples of data that should be resident on this sheet include constants such as number of sales people or phone reps, and assumptions such as the expected growth rate of revenue, the growth of salaries, etc.
• Cost Analysis – A summary of line item costs by year.
• Benefit Analysis – A summary of line item benefits, by year.
• Summary – This sheet shows the cash flow analysis over a defined time horizon (e.g. a 5-year look at costs and benefits) plus the overriding measure of the project (net ROI, NPV, payback period, etc.).

Explanatory/business case “guide” document
If time allows, we recommend producing a “guide” to the ROI model that explains, in simple terms, the process that was used to build the model, key assumptions that were using in building it, how the model could be used to do scenario-based analysis, etc. This will be extremely useful to two audiences: (1) those less familiar with the financial analysis techniques used, and (2) individuals who are unable to attend the results presentation and may have questions of the “how did you come up with this…” variety.

Overview Presentation
An overview presentation of the business case that covers the following major topics:

• Context / Objective – what is driving this process and why the business case is needed
• Process – how the business case was created – approach, sources, techniques, etc.
• Results – what is the result – go or no-go
• What’s next? – more work to do on the business case or proceed directly to acting on the results (begin technology selection or perhaps move right into implementation)
• Supporting Documents – this could include interview notes, reports or raw data to support the analysis, etc. It is important to include this information, at least in summary form, to provide a bit of support for the simplified picture presented in the other document, as a backup for questions but also as a credibility boost to show the team did the requisite legwork to support its findings.

7. Present it (warts and all)
It is critical to present a business case, not just hand the decision-maker a spreadsheet with lot of numbers and no explanations. The presentation is critical to your audience understanding the business case, the assumptions behind it, why your estimates are conservative and not outrageous, and how you came to your conclusions. Having direct, non-evasive answers to questions about the content and approach of the business case lends it credibility. As mentioned above, you will need to have a separate “guide” document to accompany the spreadsheet, as not everyone will be able to attend the presentation and as documents get passed around the organization, the meaning behind the numbers will get lost.

8. Define a process to finish the job
The most likely scenario at this point is that the business case is substantially complete but, given time and resource constraints, still contains some open items for completion, further detailing or additional research. In many cases this list of open items will need to be completed in order to either get a final decision made for next steps, or perhaps as a precursor to moving forward (basically, clean up). It is therefore critical to ensure that a plan is in place to “finish the job.” Otherwise you risk that any open items either kill momentum or create lingering doubts that can paralyze the organization and prevent any real progress from continuing.

• Create a master open-items or to-do list that are defined during the course of your project or that arise during the presentation of the business case/follow up/feedback you team receives.
• Assign responsibility for individual items on the list and set deadlines for completion/response
• Define a target date for publishing version 1.1 of the business case (which will be considered as close to final as you might ever achieve)
• Define a process for re-presenting the business case and re-addressing open items.  This is critical so that any of the decision-makers who may have had doubts about the business case see that their concerns have been addressed and thus a decision on moving forward is not postponed due to on-going open items

9. Institutionalize the “living” business case
As this process nears completion, it is important to define a process to take the output of the business case team and determine what happens as implementation of CRM proceeds. The business case team will have produced a valuable set of knowledge products/intellectual property. It is important that this is not discarded. A few things your team can do at project’s end include:

• Define an owner for the business case – an individual or area of the business that will maintain ownership for the business case post “go/no-go” decision. If the project moves forward, the owner of the business case should have a clear tie to the executive sponsor of the project; if the project is shelved or postponed, the owner needs to be a likely participant in future customer-focused initiatives which will most surely re-surface
• Define a revision/maintenance/re-issuance process – a process by which changes/updates will be made to the business case (based on changes to assumptions, discovery of actual data that can be substituted for estimates once known, etc.); who will make those changes; who will re-issue the business case when significant changes are made; what the process is for comment/feedback on the re-issued documents
• Determine who is responsible for post-implementation validation (following up to determine if the ROI, as predicted, was achieved, and if not, why?) – this is a critical and, unfortunately, frequently by-passed step.  According to the Hunter Group (2001), as few as 20% of organizations do any post-implementation work to determine if ROI was achieved. 

Revisiting the ROI model, post-implementation, with actual results, can provide a variety of benefits to the organization:

• A definition of areas for improvement/further focus
• A critical look at the work performed by the implementation teams and how it can be improved in the future
• Feedback on the business case definition process that will improve its accuracy in the future (why were we “off” on our estimates, and how can we get closer to predicting real results next time?)
• Create a process to leverage the business case approach used here for other CRM and non-CRM projects, such that the future efforts to justify other business transformation efforts are not only simpler and faster but also consistent in format, content, level of detail, etc.

Roy Schuster is Vice President of CRM Strategy at Akibia Consulting, a provider of CRM services. Roy has over 13 years of experience developing CRM, e-Commerce and IT business strategies for a host of companies including ADP, American Family Insurance, Dell Computer, GE Medical Systems, Lands' End, and Sprint PCS