Top 10 Costly Mistakes for Business Intelligence / OBIEE Implementation Projects

Top 10 Costly Mistakes for Business Intelligence / OBIEE Implementation Projects

Okay, you have done your research, you have meticulously compared market offerings, and lined up a team of resources for implementation for Oracle BI 11g product. Senior management is supporting you, and they are expecting a great implementation of the product from your team. With a company new to the tool, how to make sure of a successful BI implementation? Having over a decade of experience in the industry, I assure you, success doesn't come easy. Selecting a technology stack is less that 10% of the battle fought to achieve your overall BI goals and expectations. Below are listed some of the most common and highly avoidable mistakes by various organizations from tiny to gigantic in sizes:

1. Not setting the expectations right with users and senior management - Having millions of dollars of funding approved from management does not mean that ton of reports will be available for analysis. It is best to release small batch of reports first, and then build upon it based on the users feedback. IT department is often under pressure to arrive being a hero group, unfortunately, there is no easy button in BI.

2. Going for BI Apps and assuming all out of the box reports will be ready and used by business - The Out-of-The box BI apps are extensive, and look good. But I am yet to find a company, that has used them without major customizations. Most Out of the box report will require some level of customization in order to be able to be used. BI apps make sense to purchase to get ETL code, which will help in building warehouse tables and having a baseline repository to begin with. Even that would require some customizations, matching the same done to source systems. Verdict - consider BI Apps to get ETL code and a baseline warehouse built. But plan to perform customizations.

3. Not spending enough time on designing repository to enable intuitive ad-hoc reporting - One of the key selling features of product like OBIEE 11g is the ad-hoc reporting capability, which allows end users to make simple changes to reports themselves, thus reducing their dependence on IT, and cutting down development cycle. For this to happen, the data model should support it and repository should be in line with ad-hoc reporting. Without proper foresight, this may not happen, and is a costly mistake to be avoided from the beginning. Some companies plan for this, however during the development, with several changes coming back and forth, and multiple fix and break cycles, its easy to loose track. Change in BI projects will be there, it cannot be eliminated, it has to be managed keeping ad-hoc in mind. One way to reduce change cycles is to involve users from beginning, and this brings us to our next costly mistake as below.

4. Lack of user involvement during development project - User know what they want, in their heads, unfortunately, they cant communicate in BI language. They will communicate in the language of MS Excel or whatever current reporting tool they have. Waiting for six months or closed to delivery date, to show first cut to the business would be a big mistake, as they are new to BI. Their light bulbs will go on only after looking at the reports and dashboard. Best would be to do a proof of concept (POC), or to involve them from the beginning, by having working sessions, or letting them see work in progress in development. I kid you not, this a common mistake.

5. Not testing subject areas for Ad-hoc reporting - Developers and rest of the team are under pressure often to deliver the laid out requirements, which usually is a list of reports. Seldom, the subject area itself is part of that list. This is a big mistake, and letting SA go to prod without testing will add to user frustration during ad-hoc reporting (this is supposed to be a key value offering of BI tool set).

6. Not having BI standards for requirement gathering, development, testing and migrations - Including inconsistent naming conventions across subject areas. Too much focus is instead spent on technology stack setup, users requirement at hand, and deliverable on which success will be evaluated. Although standards evolve over time, its best to set a baseline from the beginning. Your users will be happier and less frustrated 5 years down the road. It is a good idea to have a resource who is knowledgeable and has access to BI best practices for development and implementation.

7. Hiring a great data modeller experienced with relational source systems, and letting him lead dimensional model design - will you visit a brain surgeon for a root canal treatment? No I suppose, then why would you go to a relational data modeler for dimensional modeling project? Yet, it is a common mistake made. It can lead to wrong designs, which brings to our next mistake.

8. Using relational models instead of dimensional model - Technically - possible, practically - useless. Warehouse models should be dimensional - star and snowflake - period. Reasons? Relational models are good with write and read systems, while dimensional models are best for read performance. Relational models offer poor performance, are difficult to maintain, complex to troubleshoot in case of issue, very hard to enhance per customer request, and most of all, it does not support ad-hoc reporting.
9. Not having application level backups or other faster ways for disaster recovery. Most companies have teams that will backup all servers and have a plan for disaster recovery. However, you would be surprised, how much time a read disaster will take for recovery. If you loose one file to a bad sector in hard disk, will business accept waiting 48 hours (or more), before server is back up? Application level back ups would be a minimum, if fail over servers or high availability environment is not setup. It will allow at least the application admins to do basic restore of services in event of a disaster.

10. Having developers or power users write access to non ad-hoc reports in Test, or Production environment -
This is a trap, to make changes in any environment other than Dev (ad-hoc reporting is a valid exception although, where reports are built directly in production by end users). Unless you want to be wondering down the road about which environment has the latest working code, no one should be making changes to test or prod servers. Not even administrators, leave alone power users. I'm not kidding, it is a common mistake. Delivery deadline, and customer push, makes toughest of the security policemen bend over to this rule. Set the expectations right, with proper reasoning, and avoid future headache.


I feel compelled to point out one more item, which may or may not be a mistake depending on who you are talking to, so let me continue:

11. Having multiple installations of software withing the same organization - There are some merits of this, like HR in most cases would want a silo installation and have a silo development team due to sensitive nature of data they own. They have a separate hardware and software stack. But finance and sales having silos doesn't make sense. This is particularly true with large shops, who don't care about chump change it takes to build a silo, and fall for flexibility, independence and speed of development with this model. For most of us, it is a mistake to avoid.

Hope you found this article useful.