In the movie, "The Patriot," the lead character, played by Mel Gibson, instructs his sons to "aim small, miss small" as they are about to take on the British army for the first time. What Mr. Gibson's character didn't instruct his sons in is who to aim at. Given that the British soldiers were wearing their stereotypical red coats, it was intuitively obvious who their target was. However, in the business intelligence world, one often finds organizations aiming at the wrong targets. In last month's BI for the Masses column, I made a rather bold statement that warrants further exploration.

The statement: A data warehouse offers no tangible return on investment to an organization. The value lies in the processes that the data warehouse enables.

Think about it. Even the most thorough report or insightful analysis adds no value to an organization unless someone acts on the information that is now available to them. The value only exists when the marketing department leverages the data warehouse to initiate a successful cross-sell campaign or sales people follow up on their newly identified prospect list.

The Wrong Target

While many would agree that this is true, this belief seemingly is not universally held. Unfortunately too many data warehousing projects are justified with the belief that the data warehouse is an end to the means not a means to the end. There are far too many stories of data warehouses languishing from lack of use, non-acceptance and unmet expectations. If you look closely at these failures, the majority stem not from implementing the wrong OLAP tool or any other technical decision, but from a failure to provide demonstrable business value.

The business value of any initiative is typically expressed in its return on investment (ROI); however, this is a subject that far too many BI projects have shied away from. Yes, calculating the ROI on a BI project is hard. Yes, it is a risky and a somewhat subjective endeavor. But it is also the key for aiming your BI project at the right target.

If an organization looks at building a data warehouse as an end to the means it is clear why they will struggle with calculating the ROI for the data warehouse. It just isn't there. Now, if the processes that the data warehouse enables are indeed the target, then the ROI will start to show through. A data warehouse merely acts as an enabler of your organization's collective business intelligence.

Many IT practitioners may be surprised to learn that there are actual generally accepted accounting formulas for calculating ROI and making capital budgeting decisions. The three different methods for expressing ROI are:

Net Present Value: Net present value is the present value of the benefits minus the present value of the costs.

Internal Rate of Returns: The method equates the rate of return, or interest, derived on the initial investment (cost of the project) with the subsequent cash inflows. It can be useful in comparing one project's relative value to another's.

Payback Period: The payback period is the time required to recoup the initial investment. It is the simplest method for calculating ROI but really only identifies the breakeven point not the ultimate return on the investment.

The Right Target

While these approaches are all different, they ultimately should lead to the same accept/reject decision of a project's value. Therefore, it does not matter that much which method you pick as long as you pick one and go through its calculation.

The greatest value in attempting to calculate the ROI on a BI project is that it ensures that a clear link to the project's potential business value is established and an understanding of the processes and steps necessary to achieve that value are gained. A BI project that has its objectives at the level of promising to turn mountains of data into information or to create a deeper understanding of customer relationships is not going to have any demonstrable ROI. The prime reason for this is not that the objectives are necessarily at too high a level, it's that the project most likely does not provide the complete map to get there.

How does one begin to calculate the ROI on a BI project? Calculating the cost of a BI project is easy, it is the benefit calculations that are hard. Costs are merely the implementation components (hardware, software, consulting services and internal staff time) plus the ongoing support costs. Most organizations focus too much on the implementation costs instead of the ongoing support costs. A database server with the necessary software may seem expensive but isn't nearly as expensive as a dedicated FTE over the long haul.

On the benefit side, cost reductions due to consolidated reporting or the automating of manual processes are relatively simple to calculate. However, it is only the large organizations that have such economies of scale where operational improvement activities can alone justify the cost of a BI project. Even if your organization has these economies of scale, it is the strategic BI initiatives that contain the real value.

For more strategic BI initiatives, the answer to how to calculate the potential benefits is to let the project sponsor or the user community do it. If we stick with the sales example and say your organization wants to increase its top-line revenue, there are only really only three fundamental ways to do so:

  • Increase the number of customers you have.
  • Increase the average size of each purchasing transaction per customer.
  • Increase the frequency of purchases by your customers.

Now if your organization could implement a BI solution that would

  • Accurately identify prospective customers similar to your top 10 percent most profitable customers.
  • Identify those customers who have not had a repeat purchase in a given time period.

What would the percent increase in number of customers or purchases be? As someone championing a BI project in your organization, you may need to work with the users to define these drivers, but ultimately it is the user community that must provide the quantitative measures. Putting these factors in a simple revenue calculation spreadsheet with the appropriate assumptions will allow the users to perform their own what-if calculations that begin to develop the ROI for the project.
If the users begin to see the potential for the BI project, they will also begin to buy into the project and more readily support the project along the way. This buy-in will eventually translate into ownership as the BI application is deployed and the focus shifts to the processes that will leverage it.

Ultimately, it is these same users who will need to determine the realized ROI after the BI application is up and running. This can be difficult because the benefits can be claimed by multiple areas within the whole process stream. While it was the BI application that identified those prospects that turned into new customers, does the BI application deserve credit or the marketing campaign that went along with it or the sales director that motivated his staff to follow up on the prospects? Where the credit ultimately lies is, of course, subjective. However, by having the entire process chain involved in the BI initiative, a more realistic and supported benefit will be assigned.

Having the users think in terms of bottom-line results also begins the process discussion. If the BI system has now identified customers whose repeat purchases are trailing off, what will the organization do with that information? Is the solution a targeted marketing campaign or an increase in sales calls to those customers? Regardless of the approach, the processes need to be integrated into the overall project.

Aim Small, Miss Small

Now that we've found the right target, we need a slow and steady approach in tackling it. When engaging in your first BI project, pick a single or core set of business drivers that provide the requisite value for your organization to justify the project. Hoping to hit the bull's-eye the first time for your entire organization is a sure way to deliver disappointing results. An incremental approach that tackles the low-hanging fruit first and then builds off of its success is best way to manage a BI initiative.

An alternative approach is to look for the economies of scale of an enterprise BI initiative. While they may be there, the increase in risk potential frequently outweighs any potential scale economics. In fact, if your organization is new to BI, the only time you should look to implement an enterprise data warehouse or enterprise anything would be if the ROI calculation for a specific more focused project comes out negative. There are times when the barriers to entry in BI can prevent a single department from going it alone. In this case, the associated risks may be worth tackling.

The interesting thing about an organization that says they can't quantify the ROI on a BI project is that they are frequently able to quantify in great detail the cost savings of upgrading their RDBMS, implementing a new BI reporting tool or consolidating BI technical resources across multiple projects. The real issue seems to be not that the ROI of a BI project is difficult to calculate, it's that they are aiming at the wrong target.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access