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
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
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
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.
Recent articles by Claudia Imhoff