Causes of Unsuccessful BI Implementations – Part 1

The success of a program of BI implementation within an organizations depends on how well coordinated the entire effort is with regard to how people react to and interact with all the technology, processes and data that comprise the core of any BI system installation. The concept of Business Intelligence is so poorly defined that a Manager’s expectations of the implementation of a sound BI program is limited to what the last BI software vendor had advised him. With the increasing demand for information at all levels, BI applications and implementations in real-time are understandably becoming increasingly complex. In this context it is not surprising that some implementations poorly coordinated never get off the ground. Some are abandoned at various stages of implementation while yet some others are never carried to their originally intended level of full completion.  Some of these incomplete installations nevertheless continue to carry on sluggishly failing to impress or deliver the results to anywhere near the level expected of them.

The detailed reasons for such implementation failures are many and varied; but broadly, common pitfalls could be easily identified as to why BI project implementations fail so often for many organizations. It is our intention to look into some of the most common core factors that account for such failures and pitfalls. It is hoped that an understanding of the key factors and an awareness of the potential pitfalls would help you to avoid them or at least mitigate their adverse effects if you happen to be confronted with any of these issues in real-time.

  • Lacking in Upfront Planning:

The beginning and end of the success of any business intelligence implementation program lies with the end user. Before you commit on a program, carefully assess why you need one and if the needs of the organization justify having one, align BI strategically with your business requirements and problem areas. Don’t make the mistake of designing a program for a handful of power users. Make it available and appealing to the average and below average users that form the vast majority of those needed to make the program a success. The requirements for power users can follow once the majority is happy with what has been prepared for them. Other probable areas of inadequate upfront planning can be cited as (a) Insufficient recognition by IT management that BI needs to be managed differently than transactional systems, (b) Insufficient leadership to drive changes to how the company uses information and analytical tools to drive results, (c) Weak business sponsorship and lack of accountability for the BI program or initiative, (d)  Lack of clarity on how BI will be used by the business to improve profits.

  • Customization Overkill:

Contrary to popular expectations, too much customization of vendor applications to accommodate needs of too many individuals only tend to increase costs rather than usability. The increased consultations necessitated add to costs and make the project take a longer time to build. Later, more people will be needed to support and maintain the application.

  • Incorrect Choice of Technology:

The chosen technology may not be supporting the requirements: specifically information access, presentation, automation and analysis. A classic case I have seen is the use of adhoc reporting tools for drill down financial reporting instead of OLAP. Some adhoc reporting tools cannot embed intelligence (for instance assets are shown as positive and liabilities as negative in the reports).  They miserably fail in “drill down” and “signage”.

  • RAC Test:

This is a very useful and revealing fundamental Self Test. Take it and pass it before you get concerned with more advanced aspects.

R  =  Relevance

A  =  Accuracy

C  =  Consistency

T  =  Timely

Unless you pass well in all of the above tests, you might as well forget about the project. All the indications are that it will be a failure!

  • Inadequate Training for whom it is needed:

Many organizations make the mistake of throwing their weight on an ambitious BI implementation program without giving adequate training for the essential users. When things start going wrong as a result of the untrained personnel using the tools incorrectly in a haphazard fashion, the company has to incur high costs on undoing the procedures made by the untrained users for using the tools. Before deploying the technology, the organization should ensure that the absolutely essential users are adequately trained instead of training all inadequately. Insufficient technical training prevents developers from getting software products to do what the vendors guarantee them to do.

  • Non-involvement of Executive Leaders:

Implementation of a BI program means you are introducing a change to the organization. You should choose some executives with known leadership qualities to collaborate with different cultural and organizational groups and smoothen the changeover. Many employees resist change, refuse to cooperate or even turn hostile. The BI implementation should be preceded with a plausible explanation of the need for it, together with a list of benefits to be derived by the organization as well as the employees with clearly defined metrics for their measurement and preferably with an attractive but workable incentive scheme for those who will play ball. BI is an iterative process. It has no place for cubes that can only interlock into a predetermined dimension, and a defined set of measures and aggregations. It should be appreciated that within 12 months of a pilot BI project implementation, the very requirements and needs that led to its inauguration would have vastly changed beyond recognition. As past information and procedures become commonplace with the advent of new users with their new requirements, inevitably it gives way to new challenges and new horizons. That’s why they say, “We are never done with a BI system!”

  • Poor Communications with Consultants:

Ensure that you and your BI consultants have a perfect understanding and agreement on all key issues such as each other’s roles, responsibilities, time frames and costs. Potential problems that could arise as a result later on and trying to find solutions after the damage has been already done could be prevented with a little foresight in having a project scope document incorporating all the aforesaid issues prepared and agreed on by the parties concerned in advance.

  • When Perceived Needs differ:

It would be practically impossible to cater to a request like “we all need a single version” since it presumes agreement among all with regard to even matters like turnover, sales andd revenue. This is a typical situation where the cost and time involvement could be very high and would need very careful assessment. Even different social / cultural needs within an organization could be significant enough to spell disaster to the implementation of an ambitious BI program.

Translate this post