Business Intelligence Project Pitfalls

Originally published September 13, 2005

Most of us have heard stories of business intelligence failures. I assure you that it is rare for technology to cause the failure. Unfortunately, it is usually the “softer” issues that bring down the project. Here is a list of definite project pitfalls. By understanding these pitfalls, hopefully you will avoid them altogether or at least decrease their effects when confronted with them.

A recent Nucleus Research report lists their top five IT mistakes in generic IT projects. I have added my own comments about these in terms of specific business intelligence projects, in addition to adding a few of my own. These reasons include:

  • Customization Overkill — Every business intelligence project is subjected to constantly changing requirements. This can be managed by using a scope document to hold peoples’ feet to the fire. Trouble arises when we begin customizing vendor applications or those standard reporting applications that we created to better match individual needs. According to the report, too much customization rarely increases usability, but it surely will increase initial and ongoing costs. You get the one-two punch with overly customized applications. Initially, you will spend more on consulting and projects will take longer to build. Secondly, the applications will require more consulting and personnel to support and maintain. The business must have a good justification for customizing a vendor’s application or your in-house analytical capability.

  • Lack of Training — We would all like to think that our business intelligence applications are so intuitive and easy to use that no training is needed. If that is the case, then why hasn’t everyone in your organization embraced your business intelligence environment? There are many other related processes or cultural changes that are needed for full utilization and adoption of your business intelligence applications. The report relates Salesforce.com stories in which the technology was deployed with no user training. The companies ended up either abandoning the tool (which was unfair to the vendor) or worse, investing significantly in changing bad behavior later because the users made up their own procedures for using the tool. Please listen to your vendor when they offer estimates for the type and length of training needed to use their tool. Then make sure you only train those employees with a “need to know,” rather than making the entire company go through the training.

  • No Executive Involvement — I wish I had a nickel for every time I have said this to an audience. This form of support is especially critical for business intelligence projects that require collaboration between different organizational groups. This is because you are changing the way the business users do their work. The business users become hesitant, maybe even hostile toward the new technology and application. You must have a C-level executive who is willing to be the first guinea pig, to be the first person to adopt the new environment. This executive will make your application the only way they receive such information; which will create incentives for others to adopt the new system and replace workers who flatly refuse to play. A clear list of benefits, along with the metrics that will be used to measure the benefits, will go a long way. Thus, the executive will become comfortable and want to get on board with the project.

  • Lack of Communication to Consultants — Make sure that you and your consultants understand who is doing what. Agree on specific roles, responsibilities, costs and estimated time frames before you initiate the project. If things get off track, do not wait to call a meeting to determine the problems and potential solutions. A scope document for the project and another for the consultants’ roles and responsibilities will eliminate a large heartache later. Specific deliverables assigned to each person on the project, as well as their time frames, will benefit you greatly.

  • Assuming the Project is Finished — The report successfully points out that a project is not over simply because the application has been deployed. It should end when it is being effectively used by the business. This is especially true of business intelligence applications. It may take awhile before the business community actually uses the new application. It may be because other processes must be implemented before the analytics can be fully utilized. It is important to understand how the application fits into the business user’s workflow before declaring that the project is completed. Your project may not truly end for several months, perhaps even years, after it has been organized.

Here are my own top five business intelligence project pitfalls.

  • No Business Involvement — This is lower than the executive level and occurs throughout the life of the project. If you cannot get access to the actual users of your application, you are headed for failure. These are the people that will be using your application daily. They are the business analysts in your company. They must also believe in the project by contributing to its requirements. Otherwise, they will not accept it. No amount of training will overcome this obstacle.

  • No Audit Controls — If you cannot guarantee that your numbers match those in the original sources, you will find that your audience has disappeared. Many business intelligence project leader’s think that because their projects are not “operational” in nature, they need not bother with audits and controls. Not only is that idea naïve, it is downright silly. Of course, you must demonstrate that your environment is as sound as the operational one. If the numbers do not match (and they most likely will not), then you must produce the audit trails and statistics to explain why they do not.

  • No Data Quality Processes — Much like the previous pitfall, the business community must be assured that their decision making data is of the highest quality possible. In fact, it should be even better than the data in the operational environment. To give your users confidence, you must have metrics to measure the quality of the data going into your data warehouse and marts.

  • No Program Mentality — Obviously, anyone in this business understands that you never build just one business intelligence application. You are building an environment which business users can utilize to make appropriate business decisions. This means that you build the first application, then the second, third, fourth, etc. Each project should build upon the value created by the previous projects. This means that these projects must be coordinated and have a reuse mentality. Hence, you must have some form of program management function that prioritizes and funds these projects. They must also create reusable templates like project plans and data models, while ensuring compliance with program standards and procedures.

  • No Technological Road Map — Since you will be creating an environment from multiple projects, you must have an architecture that acts as your roadmap determining how each project will contribute and fit into your overall business intelligence strategy. Without such an architecture, you are likely to build just another set of chaotic reporting databases. The Corporate Information Factory is the best known of these architectures. It can be very helpful to study and even create your own version for your organizational needs.

Hopefully, these 10 pitfalls can forewarn you of potential problems within your own project. If you see that you are falling into one of these, stop what you are doing, reassess where you are and determine the best path to stop failing. This will at least lessen the effects of the pitfalls and guarantee a successful project outcome.

  • Claudia ImhoffClaudia Imhoff
    A thought leader, visionary, and practitioner, Claudia Imhoff, Ph.D., is an internationally recognized expert on analytics, business intelligence, and the architectures to support these initiatives. Dr. Imhoff has co-authored five books on these subjects and writes articles (totaling more than 150) for technical and business magazines.

    She is also the Founder of the Boulder BI Brain Trust, a consortium of independent analysts and consultants (www.BBBT.us). You can follow them on Twitter at #BBBT

    Editor's Note:
    More articles and resources are available in Claudia's BeyeNETWORK Expert Channel. Be sure to visit today!

Recent articles by Claudia Imhoff

 

Comments

Want to post a comment? Login or become a member today!

Posted February 4, 2011 by Bozidar Kralj bozidar.kralj2@gmail.com

Beside it is posted a long ago, every reason you've mentioned is still very actual. I've made my own list of top business intelligence failures and it is complement to yours.

Is this comment inappropriate? Click here to flag this comment.