During the last 5 years, I have taken part in more than 80 Business intelligence projects together with flex.bi business intelligence team. I would like to share my conclusions on this topic because it is very sad to see that obvious things are overlooked before thousands of euros are spent. In my experience, the project has failed, if a BI system (Power BI, Qlick Sense, flex.bi, Tableau or any other) is not used after 2 years – it means that this tool hasn’t found its place in the everyday life of the company. Can we predict this outcome before starting a project? Actually, we can! While analyzing our failures, I have found that these 4 reasons are the most common. If they sound familiar, maybe it is not a good idea, a good time, a good team or a good software setup to start implementing Business intelligence. The process is hard enough and requires a lot of effort from the business, so try not to make it even more complicated. So, here comes the list..
1. Keeping double standards = Not enough of the company’s employees are using reports in “the same language”
This is a typical mistake that leads to failure in the first or the second year after the BI project implementation. The thing is that often BI tools are considered to be management playground, and they are not offered to the ordinary people on every level of the organization. This leads to employees on the operations level still using the old reporting standards and tools. As a result, at some point, management fails to communicate with them in the “new BI language” and returns to the old system, because the employees on the operations level are dictating the manner of reporting – as they are the ones bringing the money in. Also, it will be hard for them to complete goals that they do not understand. Don’t get me wrong – for the most part, BI dashboards will be used by business/department managers, but you should try to make it even more casual. I think, that the future slogan should be “BI for everyone please”.
Solution: So, how much is “enough”? Make your BI tool a mandatory system and not just a “nice to have” extra. This is a KPI based on a gut feeling. You can’t really measure it, but basically – if your BI system is down and people are asking for it the next day, then it is enough. Try to find ways for interacting with all of the team members, using the same KPIs, so that they see their contribution in achieving the company’s common goal. Give everyone a sense of the main common goal and you will see a lot of positive change.
Methods for achieving the above: personal result KPI panels for salespeople or middle management, online TV screens with company progress for non-technical people, quarterly strategic dashboards for middle management, references to those dashboards in the weekly meetings, dashboard email subscriptions for those who are not “active” BI users.
Think about your BI platform’s capabilities to communicate your goals to everyone in your organization and youse those tools.
2. BI Project Leader is too technical (Data analyst, CFO, Data manager, etc) = The long term business needs will not be satisfied
Please, please, please, don’t allow highly technical people to lead business analytics projects! “Project leader is a professional who leads people and makes sure a project is carried through. The project leader engages the team, motivating them, taking care of their needs, and maintaining a friendly and productive work environment. Some of their primary responsibilities include: attending meetings with other leaders, developing progress reports regarding projects they’re working on, keeping the team focused on the project and moving toward to reach its goal, testing product prototypes.”
To understand the consequences of assigning this role to a technical person, we need to have a closer look into the personality of a “technical person”.
- Usually, these people are the ones who like doing and not thinking about doing. That might sound perfect when you have clear tasks, but the drawback is that they focus only on the short term needs. They want to get things done and move to the next task. This can lead to a lot of technically complex reports lacking the answer to one of the main questions – why do we need that? This is caused by the vertical thinking of technical people – they are perfect for diving into one specific topic, but that is not what you need when planning the most important dashboards of your business.
- Another aspect of a technical person – they are not very talkative. They will not enjoy collecting information about the needs of every department and aspect of the business. The resulting dashboards will contain plain layouts (usually tables or simple charts) and no KPIs related to business strategy. There will be no added value for the management. It takes someone who knows the business, to analyze business, and they don’t. That’s why it is so hard for them. They will try hard, but the result will make no sense.
- They will not be able to plan the project and deliver business critical values first, because they don’t know what is critical for the business. As simple as that. As a result, you will get unimportant KPIs. Most of them will be “lagging”, not “leading” – with focus on today or yesterday instead of the future – not the KPIs that could take your business to the place you want to be.
- The result will be quite “gray”. You will get long tables instead of nicely structured dashboards because technical people just want to see numbers. They like and understand numbers and don’t take into account the experience of other users and the fact that the owner of the company probably prefers more visual presentation of data.
Solution: In a perfect scenario, you should hire a business analyst who can also be a project leader. If that is not possible, you should choose someone from your own company, who understands your business processes, is a good project manager, and knows how to satisfy the needs of different groups of people. That doesn’t have to be a technical person. It is even better if he/she isn’t one. Knowledge of the business and project management skills are critical requirements. Don’t get me wrong again – data analysts and IT specialists are perfect for the actual implementation process, but they are not suited for leading the project.
Methods for achieving the above: hire a business analyst for the length of the project implementation 🙂 If you are a business owner, free some time to take part in the BI implementation process and make sure that technical people know exactly what has to be built.
- Make a list of 5 most important topics that you want to focus on in your dashboards and give this list to the project leader (or a technical person).
- Provide some examples of dashboards that you are expecting to get as a result (just Google them.. or look in our Template library).
- Together with other business owners, one or several (max 3) KPIs that you want to focus on. KPIs must match your strategy. My favorite method for KPI selection is the Hedgehog principle.
- Set priorities – clearly state what is and what is not important, and check if those priorities are followed during the project. Request dashboard delivery in priority order, if it is technically possible. This method is called Incremental project management approach and it is my favorite for BI implementations.
- Plan weekly/monthly meetings with the project team – always on the same time and the same day. Request presentation of unfinished and “proof of concept” versions of the result. This will ensure that the team is staying on track and not going too deep into unnecessary details (which is typical for technical people, if you do not control them). This will save you human resources and money and also allow you to adjust and your initial ideas on the go.
3. The business is not mature enough for BI or is undergoing a big change = The project will just fail and go to the trash. Several times. Maybe even won’t go live.
This is the most ineffective way of burning your money, but if you are ready to fall, stand up and do it all again – you are welcome to do it. There are some organizations that need this to foster the change. If we look from company’s lifecycle perspective (I will use Adizes methodology for this), there are some periods that are more suited for a BI project implementation and some, that are not. I would like to emphasize Courtship – Infancy, Go-go – Adolescence, Recrimination – Bureaucracy periods as especially risky. BI tools are often considered as “non-critical” part of organization’s IT setup, so a new BI tool will be the first sacrifice during hard times for the company. During the last 2 years spent under the influence of Covid, we have received a couple of emails saying something along these lines: “We have to cancel our subscription because we have to focus on survival.” Unfortunately, BI is not considered a part of the survival package. This is a typical example of a situation where critical changes can push a BI project to the side. Again I have to say – please, don’t get me wrong!
How you can tell that you are in the middle of a big change:
- The company’s management team is changing. Your team members change often. Usually, it shows that organization is trying to define new standards and scope but is not there yet. Wait while the team becomes more stable. BI project has to be delivered by one team, because introducing a new team to the BI project specifics during the implementation process costs a lot of money, time, and effort.
- The company has fallen into “Founders trap” – for a fast growing business it is typical that the Owner is still a part of the operations team and is doing everything himself. He is working days and nights and also doing all of the reporting. This indicates issues with trust and delegating responsibility to someone or “something” else, including a BI system. In this case, even if the project goes live, it will fail fast, because it is “not the same as before, so not trustworthy”. Successful implementation of a BI project will take time, maybe even multiple times. We have some customers who have canceled flex.bi subscription and then activated it again 3 times, just to start everything all over again, because it takes time for a founder to understand that he has to move on and become a manager or leave.
- You are changing some of the business-critical Systems – like ERP, Financial Systems, CRM etc. to fit the new scope.
- You are defining or re-defining your business process that you would like to analyze or are in the middle of negotiating business process changes (Recrimination- Bureaucracy).
Suggestion: Implement a BI tool before or after those tricky moments. Changes are good and well suited for exploring the market, checking out the options out there. But “winds of change” can be too strong for a data and process based project to survive. During these times, use a business analyst to assist you with change management, plan your future IT infrastructure, but delay the implementation or implement it step by step, starting from basics. Wait a bit for the winds to calm down, re-define your strategy and think about new KPIs.
4. Too many too old systems that do not talk to each other = The cost of the project will be too high and solution will be hard to maintain. It will stagnate for some time and then will be forgotten and replaced.
There is a common misconception that a BI tool is some kind of a magic wand that can be used to fix everything – but in reality, it’s only a way of seeing the existing process, data and other problems within the company. Which is a good thing, if you are ready to face the problems and adjust. But it is not so good, if you just want things to be the same. The situation described above is typical for a mature business that is at the top or downhill of Adizes lifecycle (often those are government institutions and high profit organizations who haven’t focused on IT infrastructure) or for very young companies who have chosen their systems based on short-term requirements. In the context of BI, having too many too old systems just means that you will soon find yourself in the situation described above in the 3rd paragraph The business is not mature enough for BI or is undergoing a big change. In case of a mature business, the BI project could even go live and be used for a while, but for small businesses, there’s no chance of success, because they just can’t afford it.
Suggestion: Involve a business system analyst to replace/update the old or randomly selected systems. Exercise: draw a model of your IT infrastructure on a white-board or using this Free Online Diagram tool. If you have one system for each department, it is too much. The less systems you have, the more “integrated” and effective you are. Think about ways how you could become more effective and which system is “pulling you back”.
- Mark (with red) systems that do not talk to each other or do not have connection possibilities (REST API, SQL, or other)
- Mark (with red) systems that are older than 5 years and haven’t been updated since then, do not grow, do not have fresh updates.
- Mark (with red) any manual data transfers between systems.
Make a simple table of all Business processes and look for possible improvements. Are there tools in the market that cover more functionality and could make your business processes more effective? This table shows our software structure. This is our perfect bundle deal that also provides data analytics possibilities. All systems are interconnected providing the smoothest possible business processes. What about yours?
I truly believe that project success can be changed at any point during the implementation, so make sure your that project falls into the pile of successful ones. Please think about those 4 points, if you are on your way to or in the middle of your BI implementation, and hopefully, it will save you some time and money. Share your thoughts with me, because I would like to know what are your struggles with BI projects.