What is a BI Project?

A business intelligence (BI) project is the planning, assessment, development, and implementation of BI. These projects require balanced cooperation between a company’s various processes, technology objectives, and data to ultimately empower better business decisions that drive companies to increase revenue, improve operational efficiencies, and gain a competitive advantage.

But often, though these goals are exciting and achievable, business intelligence projects fail. In this article, I’ll cover the 5 most common mistakes organizations make when pursuing BI projects.

Moving Goalposts

We frequently witness that the user requirements for BI projects keep changing throughout the development and testing phases and the goals of a BI/Data project are not clearly defined at the beginning of the project.

Often, critical questions pertaining to reports/dashboards, usage, and ownership are left to be considered later. Some of these questions may be:

• What exactly are the key metrics and KPIs the users are after?
• Who owns the different data pieces required for the report model?
• What are the slicers/dicers, and dimensions needed for key reports?
• What is the latency required for each report? 

The result here is that the project keeps getting delayed because of continuous changes, rework, and eventually exceeds its timeline and budget. 

The solution is to have a rigorous requirement gathering process that formalizes each and every aspect of the users’ requirements, along with a general agreement with data owner(s) about what will be required in terms of data.

Big Bang Approach

Another reason the BI ship, so to speak, often becomes a Titanic is that it is just too big to float. A Data warehouse/Data Lake/Data Mesh that takes care of all the corporate analytics needs at once sounds like a fantastic idea but is inherently filled with risks.

For example:

• The data ownership is spread across the organization and getting everyone to agree and share their data within the stipulated time can be very challenging.
• The Development/UAT/Pre-prod environment is shared between different teams. Carrying out a massive project means needing all those teams to force-cooperate with the BI team on a more frequent basis in terms of data refresh, UAT testing, etc.
• Having a project that aims to tame all the areas (Sales, Purchase, HR, Marketing) of analytics may require massive efforts in terms of resourcing, budget, and user engagement. It also exposes the project to multiple points of failure.

The solution is to follow a simple, agile approach. We suggest a 3-week timeline for every deliverable. Build fast, fail fast, learn fast, and fix fast. Overall, deliver incremental value on a regular, consistent basis.

A solution for its own sake

It might be the case that a BI system is in place but no one is actually utilizing the reports or dashboard. So, a project may be executed and delivered, with all the money, time, and effort spent on it but in the end, it sits there for its own sake without anyone leveraging its value and potential.  

The reasons can be different, but examples include:

• There was no user buy-in in the first place. Someone had the idea (and budget) that they should have a BI system and the project was kicked off without any user involvement about what they really wanted or needed.
• Users just don’t like the BI tool. Unless they are properly trained, users may find the BI tools a bit cumbersome to use and if they don’t like it enough, they would rather go back to their old, Excel ways.
• The reports/dashboards are too complex. The underlying data model may be very rigid which means there is no possibility of having a self-service visualization. The users often want to use the reports in their own way, with specific filters, slicers and dicers, and visualization. They’d hate to go back to IT for every little change and would rather stick to, again, Excel.

The solution to this is to have thorough user engagement throughout the project. Especially the requirement phase, as it must be clearly driven by the user, and the requirement doc must be formally signed off by them. They should also be brought on board when choosing BI tool(s). Last but not least, user training must be high on the agenda of delivery.

Getting off on the wrong foot

A BI/Data Analytics project often involves overlapping data areas and departments –

some of these departments typically have their own reporting systems which can vary drastically in terms of tech stack and sophistication. Not taking into account the existing systems while architecting a new solution can actually be enough to make your new solution a waste of effort. So, a project may actually be doomed for failure for reasons like:

• The new design is incompatible with the other larger parts of the data ecosystem, which can result in rather clunky architecture.

• The new architecture fails to take into account the future direction data platform.

For example, if the organization is planning to migrate from Snowflake to Azure, then proposing a Looker-based system would not make as much sense as proposing a Power BI system.

Before finalizing the high-level architecture of the solution, it is imperative to enquire about the surrounding data ecosystem in terms of different platforms, vendors, compliance, and licenses.  Only after these factors are weighed in properly can the BI architectural components and high-level design be finalized.

Putting the cart before the horse

If a new business application is under development and could make good use of BI analytics by feeding data to it, should you start developing a BI system in parallel to the application? Not always.

In fact, it is actually more prudent to wait for a new application to stabilize in terms of its component and data structure before you start utilizing its data for BI analysis. It may seem odd, but overenthusiastic managers have tried to build BI systems in parallel to an application by using sample and test data.

In one case, we saw the BI system was ready even before the main application went live. What an achievement! … or is it? Certainly not after you consider massive efforts in rework every time the source application underwent change during the UAT phase. If they’d only waited for a little for the source system to be UAT signed off, they could have saved half the money and time delivering the same project. First things first, as they say.

We could go on and about the ways to build and navigate your BI strategy, but your success comes down to one crucial step – which is finding the right global BI consultant.