Five most common mistakes in a Business Intelligence project

[eduardorodrigue]

How many of us have already seen or even experienced ourselves a Business Intelligence (BI) project failing? But then, some would argue how many of us have seen or even experienced any sort of project failing?

Although I believe that is a valid (and complex) discussion, I have no intentions to elaborate on the project management side of it in this article. Since I believe that would be better addressed in a Project Management Institute (PMI) article rather than here. 

What I do want to explore is the five most common Business Intelligence mistakes in projects, based on my experience and also on the experience of my colleagues. And you can be sure, however, that those five common mistakes are definitely to be blamed for several of those failure BI projects we all know.

Mistake #1 – Not getting business stakeholders involved

I know sometimes is hard. “Those IT guys are always asking to get us involved on their tech stuff” some will say. But when you are dealing with Business Intelligence projects, there is no way to get the “Intelligence” part working if you don´t start with the “Business” part of it. The customer (and the boss of the customer) has to express their requirements clearly. Knowing their current challenges, pains and opportunities is a must in order to build something that meet their expectations today and is sustainable on the long run.

But getting the stakeholders to define the initial requirements is just the beginning. They have a key role in all ASAP (Accelerated SAP) project phases besides Business Blue Print (BBP): business stakeholders need to be available to clarify questions, discuss possibilities and test the outcome during execution; they need to actively promote and support change management activities and training during final preparation phase and they need to be open minded, supportive and proactive during the go live & support phase.

If you got all the above done, there is still a second part of it, much harder to get done. In case you are in a true Business Intelligence project chances are that you are implementing an indicator (or even a KPI – key performance indicator) or at least, making it visible and accessible. That is the most difficult part, an indicator will make visible all sorts of problems: from master data inconsistency to process issues and solve those issues is definitely to some of yours business stakeholders.

Mistake #2 – Not having a clear goal

That is a very common one. “Could you, please, help me out to start my Business Intelligence project?” and then “What is it for?” one could ask. The answer: “The usual BI stuff, you know”. NO, I DO NOT.

Although it is about the same in every project, not having a clear goal in a Business Intelligence project can be a real killer. There are so many options and differences that not having that clear goal will most certainly lead you to deliver the wrong thing.

A CIO, from a big retail customer, asked me to access its current Business Intelligence scenario do help him understand why he was not getting the KPIs and Dashboards he was hopping for when he started the project. After a short assessment the reason was clear: the BI specialists did a great job translating operational reports and operational analysis into the BI system but no effort was focused on deliver a Dashboard and even less effort was put into defining what KPIs could possibly make part of that to be Dashboard.

Mistake #3 – The tool to answer all requests

If you ask a man who only knows how to use a hammer how to chop wood, he will tell you it is possible to chop it by hammering it. Although that could eventually suffice, it is far from been the right answer. That is no different when it comes to BI projects.

SAP has in its SAP BusinessObjects portfolio a wide range of tools, each meant to answer a specific request. More details on those tools can be found in specific materials, but here it goes a short description:

Tool	Simplified use case
SAP BusinessObjects Analysis	Used for data analysis in a pivot table like user interface, drill down, drill throw with no or minimum training
SAP BusinessObjects Crystal Reports	Used for pixel formatting reports, highly formatted reports or printable (list) reports
SAP BusinessObjects Dashboards	Used for Dashboard build, KPIs display, high end presentation and simple simulations
SAP BusinessObjects Explorer	Used for data discovery and exploration with minimum or no training
SAP BusinessObjects Predictive Analysis	Used for data mining, trend analysis and complex scenarios
SAP BusinessObjects Web Intelligence	Used for data analysis, drill down, drill throw and charts analysis

Yes, it looks obvious. However, I have seen in several projects and customers the attempt to create detailed reports using SAP BusinessObjects Dashboard or nice printable lists using SAP BusinessObjects Web Intelligence. It is very important to understand the initial requirement and goal, in order to choose the better tool.

Mistake #4 – Understand BI is not about reporting

I know it sounds obvious, but it is not. I have seen it in many projects and heard it from many managers, users, customers and even from some people in the C level that they needed their “reporting system” to work properly.

The problem here is somehow connected to the previous topic about finding the right tool for the job. Some original BusinessObjects customers are simply accustomed to make extensive use of SAP BusinessObjects Web Intelligence and SAP BusinessObjects Dashboards and for been satisfied with the results never actually pay any mind to the whole portfolio.

In Brazil we have a saying that goes somewhat like this “in winning teams, no change is required” however, in order to deliver bigger value to the customers we need to do more than simply reporting and listing.

One of the big service companies I have visit have tried to use SAP BusinessObjects Web Intelligence to create a printable, twenty plus pages, preparation book for their monthly board meeting, containing all their KPIs and important reports. Needless to say they got very disappointing results from both performance and meeting productivity alike.

In that case, as I have recommended then, the best solution would be to use SAP BusinessObjects Dashboard as an entry point for exception base analysis and link specialized SAP BusinessObjects Web Intelligence and SAP BusinessObjects Analysis for deep dive on more detailed data.

Mistake #5 – A project team with missing skills

That is the fifth on my list but only because it relates with some topics above which I wanted to clarify before coming to this point. So once more, last but not least.

I understand and agree that the right skills set to build up a complex Dashboard, with SAP BusinessObjects Dashboards, using several sources, complex calculations and even some simulations is usually a technical consultant. However, every and each BI project is about measuring business processes, about finding the best indicator or KPI to measure or track something.

If we all agree on the above statement, we must agree on the next: each and every BI consultant must also understand the business general rules and needs at least in high level view.

It is only possible to ask for business stakeholder to come along if you can tell what you need from then; it is only possible to challenge for a concrete and achievable goal if you can imagine how that goal should look like; it is only possible to point out the advantages of using one tool over another if you understand how it would be used in the daily routine and more over it is only possible to shake the status quo and propose and exception based analysis (for example) instead of a list if you know how business dynamics looks like.

Conclusion

You are probably wondering now about ten other common mistakes in Business Intelligence projects, you may even disagree with my top five, which is fair enough.

Reality is way too complex to be capture in few pages or five topics; however I strongly believe that avoiding at least the five mistakes above by:

1. Getting business stakeholders involved
2. Setting a clear and achievable goal
3. Defining the right tool to be used in a specific case
4. Supporting the customers to use the complete spectrum of Business Intelligence tools and concepts
5. Putting together the right mix of business and technical skill sets

Chances are substantially increased for you and your customer to have a successful Business Intelligence implementation.