Leading for Success with your Business Intelligence Initiative: Part 7

In my previous post Leading for Success with your Business Intelligence Initiative: Part 6, I discussed the keys to success. Today, I will conclude the series.

The S's in Success

The Meaning of Success and Failure

Many people assume that success and failure are mirror images of each other; to succeed is simply not to fail; to fail is simply not to succeed. But if the goals, the hoped for results, of a project are less than fully realized the mere absence of obvious failure need not be the same thing as success. Nowhere is this phenomenon more common than in implementing major business application software (e.g., SIS, ERP, BI, CRM).

Failure seems like a simple idea, but when we try to examine it in detail it turns out to be more complex than one might expect. As I have discussed throughout the series, the potential for failure includes quite a few entirely different things. In fact it's hard to imagine anything worth doing at all that couldn't fail in more ways than it could succeed.

Typical Success Rates:

Reported rates on BI project success vary from survey to survey, but tend to be consistent. The 2009 BI Scorecard survey [1] of 324 BI professionals found that 29% of BI deployments were slightly successful; 47% were moderately successful and only 21% of the respondents rated their deployments very successful. The rates were largely unchanged from the last survey in 2007.

In short, the majority of BI implementations fall short of being very successful and usage continues to be hindered by a number of factors.

So what do we mean when we describe a BI project as a success or failure? What are the symptoms of dissatisfaction with BI initiatives? Let's look at the evidence. This is my own list of common symptoms of failure, but it is consistent with my meta-analysis of BI case studies and other published lists.

First, it is apparent that users and builders view both the symptoms and the causes of BI failure somewhat differently.

Symptoms of Failure:

  • Users still have poor access to data and information.
  • Solution outputs don't match decision-makers needs.
  • Missing reports, queries analytics.
  • Business decision-making has not improved.
  • It doesn't do it my way.
  • Too complex or hard to use.
  • There are data integrity and/or data accuracy problems.
  • There were/are data conversion problems.
  • ROI remains a challenge.
  • It just doesn't work! or similar statements of abject despair.

One striking thing about all these symptoms is that they all appear after the fact. That is, there are no early warnings on this list, nothing that suggests were going to have a problem if we don't do something now.

When asked for the causes of these symptoms, users and builders typically list the following (the wording varies from survey to survey).

Causes of Failure

Users:

  • The wrong platform was selected.
  • The BI solution was designed or configured incorrectly.
  • Inexperienced/inept builders.
  • Builders didn't take the time to understand my needs.
  • BI solution was underestimated or oversold.

Builders:

  • Users kept adding and changing requirements. This is the universal first response
  • Lack of user skill. Many flavors (some unprintable), among them:
    • They have nobody who understands anything in that department
    • They refuse to change how they work.
    • We showed them over and over again and they just didn't get it.
  • Both:

    • They lied.
    • Lack of management commitment/support. This is the single most commonly cited general cause of failure, but often it is offered without an explanation of exactly what management should have done differently.

Some rather surprising things emerge when we compare the list of commonly reported symptoms of failure to the list of commonly reported causes of failure. First, almost any commonly reported symptom could be the effect of almost any commonly reported cause. Actually, the relationship between reported symptom and reported cause is even more nebulous than that (if possible). Second, there is nothing in either list that suggests how to avoid these results. The closest we usually come to are statements like:

  • Management should have been more involved (without explaining what management should have done that they didn't; or
  • Requirements should have been better expressed (without explaining which particular requirements were misstated or omitted).

Of the causes of failure (risk factors), the last one "Lack of management commitment/support – is the most critical. To be successful, any institution must decide why a BI solution should be implemented and what critical business goals the solution will address. Hence, identifying business goals, determining the strategic business issues, ROI and strategic requirement identification are essential elements of the BI planning process for success. Alignment of the BI strategy with the institution's business strategy must be enabled by senior executive support. If an institution tries to install a BI solution without establishing a clear vision, every effort can turn into a disaster .Remember that failing to address it can lead to every one of the effects (symptoms) of failure.

As I discussed in part 2 of this series, it is one thing for senior executives to establish a clear vision; it is quite another thing to ensure that everyone else shares and buys into it. Senior executives' do not implement BI systems, but strategic business issues and a strategic vision need to be spelled out in unambiguous terms that everyone on the BI project team shares long before the first requirements are defined and any technical implementation decision is made. These are the keys to success.

Planning for Success

We are only planning for success when the vision and requirements we are working to are the same as those by which our efforts will be judged.

A relatively small number of symptoms or effects of failure, around ten of them, are responsible for all BI implementation failures. Each of these can follow from a somewhat longer but still quite short list of risks (or potential causes of failure).

Managing each of these risks must be a plainly visible requirement, because systems are not turned on until the perceived requirements have been met and they are invariably turned on as soon as the perceived requirements appear to have been satisfied.

Among the requirements that must be visible to everyone involved in the new BI initiative, is the obligation to conform to the institution's strategic goals and objectives. The translation of these goals and objectives into concrete business processes and tactics is critical if project success is to mean the same thing as day to day operational success after the solution is implemented.

With BI projects, many of the biggest failures have resulted from attempts to utilize a traditional application or software development plan (methodology) that produces the wrong work products, and as a result, the wrong solution.

[1] BI Scorecard, Survey Information Week, December 21, 2009.

For some additional insights on BI success, I refer the reader to the following Campus Technology article. BI Project Success.