How to achieve value quickly with your Business Intelligence implementation

How to achieve value quickly with your Business Intelligence implementation

Tekengebied-5-1024x683-1

In this article, I aim to share some insights into how I tackle a frequently asked question during consultancy projects:

“How can we, as management, quickly find out what value we are going to achieve with our Business Intelligence (BI) solution before making major investments?”

Most (Power) BI projects fail because the organisation is experiencing insufficient value. Expectations before the start of the project are often sky-high and there is a great need for certainty about the end result from the outset.

So how to avoid this pitfall?

Small scoping is the key

I regularly see organisations fall victim to the pitfall of starting out too big with a vague goal. It takes too long before the first results are delivered, sometimes it takes six months or longer. And when it is finally delivered, it is below expectations or the benefits do not outweigh the costs.

I believe it is important to deliver a first dashboard very soon after the start of the project. Preferably a deliverable that immediately removes a pain point, such as a cumbersome reporting process. After all, the organisation needs to know whether the project will generate sufficient value. This applies both to the first BI implementation and to the expansion of an existing implementation.

Every single project starts with the same questions:

  • What is our vision on BI?
  • How can Data become an asset for our company?
  • What exactly do we want to achieve in the long and short term?
  • What insight would be most valuable?
  • Which goals are easy to achieve with what we already have?

Based on these questions, you build a first dashboard: a proof of concept*. The PoC enables the organisation to see (within a few days / weeks) what the added value of BI can be and what to expect. After the PoC you decide whether to continue the project or not.

These first steps should be small investments which deliver great value. This way of working often creates support for the project within the organisation.

The next phase may be bigger and take longer, but even then, we keep the scope as small as possible. We do not start by implementing 10 data sources at once. Start with the first one, build on that and validate with the business as soon as possible!

The following customer case is an example of a PoC, build on Excel exports and delivered within two weeks: Insight into the availability of 1,100 bridges

* For our internal dashboards, we sometimes create a picture of the first version in Power Point. We first validate whether the “dashboard” shown, answers the team’s questions. Is it correct? Then we start building. This ensures speed and minimal risk.

Three biggest pitfalls for a BI project

If we see Business Intelligence projects fail, it is almost always due to the following three pitfalls. I will explain them briefly.

1)    The scope is too big (as mentioned before). In a BI project, you almost always run into issues, just like when developing software. You never know in advance what you are going to encounter. If the scope is too big, you may encounter too many issues at the same time during development. You then get bogged down in complexity and endless discussions, which is why the project fails.

2)    The developers do not work according to the Agile philosophy. Often leading to the following scenario. First, the entire technical solution is built, modelled, and outlined without validating it in iterations with the business. After delivery both the development team and the business team discover that the proposed solution was not exactly what they needed. This often means a part of the work needs to be re-done. This generates a lot of work without added value and increases the costs unnecessarily.

3)    The developers have insufficient experience with the customer’s business model. As a result, they are unable to discuss the end result or match the data model to the business model. The customer has insufficient experience with the technology and is therefore unable to manage the project. More time is spent on meetings about why things are not working and what needs to be done than on actual building.

The product owner is the success factor of every BI implementation

A competent BI product owner knows their customer’s business. They understand both the business and the technology, and they know how to get to the desired end result within acceptable timelines.

By scoping small and continuously focusing on the most added business value. Development teams can make a new delivery every 2 – 3 week sprint (scrum). This means that value is delivered every 2-3 weeks with a very short feedback loop.

Along the way, you will always encounter issues you could not have foreseen. By working in small sprints, you can quickly make choices. This allows you to take the path of least resistance towards the best possible result with the resources available.

An experienced product owner guides this process in the right direction while also monitoring the timeline. The customer is continuously involved in the process, is always informed and understands what is happening.

The end result is that a solution is devised in short cycles that delivers great value to the organisation. Bonus: because the business is involved in the process, they experience ownership of the delivery, which ensures a high adoption rate.