We’ve spent the last 20 years implementing Business Intelligence and other data related projects. It is very rewarding to help companies become more effective with little effort.
However we’ve frequently had to rescue failed projects and over time we identified a pattern. We found four major reasons why many BI Projects get derailed.
Reason 1: The Requirements are Not Clear
In other words, the customer often does not know what is needed when a project starts. This is not about better specifications. This is about genuinely trying to achieve the wrong thing. We found that more than 60% of the initial specifications form of any customer were completely unrealistic. Sounds horrible – but is absolutely normal.
Imagining how data can be transformed and assessing the business impact is often very abstract, too abstract for most people who don’t do this professionally. And for us, professionals, the complexity of the data is not a problem, but understanding the client’s business well enough to see the problems the client could not see themselves is just impossible at this stage.
We found that the first version of a BI Project is often not the solution required by the customer. It is more the foundation need to talk about the requirements in a specific (non abstract) way on order to see the data empowers the Business to ask better questions. Analyzing the data enables the Data Scientist to point out possible solutions.
With traditional BI it takes too long to build the initial project and the outcome is too inflexible to be adjusted to the real requirements. Modern in memory and self service tools usually hold up better in this stage.
We are simplifying the issue in the description. In reality customers request a certain solution that basically makes sense but after a while (2 week – 2 years) changes are requested, that requires a complete redesign of the system. We found many companies are experts in triggering this cycle before a project is even fished.
Reason 2: Systems Grow into Unmanageable Complexities
There are many methods, best practices and tool sets that are supposed to give you better BI. No matter if you follow the Microsoft BI Best Practice or implement all recommendations from the Kimball Group – your system tends to become very complex.
If you don’t follow industry standard methods, changing your requirements often enough will result in your BI System becoming a chaotic mess.
Complexity, as such, is not an issue if the used tools make it easy to handle complex systems all is well. Unfortunately most complex systems are really hard to maintain. Often only the people who built the system really understand how to maintain it.
With a highly complex system, each change request takes the project one step further to its failure.
Reason 3: The Original Developer Leaves the Project
As managing a complex system gets more difficult, people leave the team. Eventually the people who built the system are gone. Now the quality of the system becomes visible. Well designed systems often work for years without needing any maintenance. We are often surprised how long unmaintained systems actually remain in production. Badly designed systems often fail within days or weeks after the original developer left.
However what (almost) ALL complex systems have in common is that the documentation is not sufficient to make changes. Or the documentation is so epic that it is still impossible to make a change without breaking anything.
In the last 20 years we’ve seen systems where adding a single attribute to a dimension caused several weeks of work to make sure everything works again. In many cases the new team actually recreates the whole system to be sure nothing unexpected happens and the complexity starts to grow, again…
Reason 4: Self Service
Particularly in recent years we’ve noticed a new trend. To avoid complexities, a big project is replaced by Self Service BI.
Empowering users to enrich data by themselves can give many advantages. However, just replacing an integrated BI Project with self service tools creates new issues. Getting correct data from several source systems is a complex task. But to get a correct Sales Report from iE Oracle EBS you may have to join 30-50 tables properly. Real world quickly becomes too complex for end users.
Another issue is that inexperienced users easily create wrong data without noticing it. A common example is when a table with Sales Data is enriched with a Sales Reason. It’s trivial to join both tables but no end user would realize there may be more than one sales reason for some deals and that joining them just creates duplicates in the table. Because often only a few rows are affected it can take a while until the error is discovered.
Another issue in the Self Service world is the consistency of formulas. Its easy to make up your own definition of revenue that makes you or your team look good. Self Service can be a road back to ‘Excel Hell’ where everyone makes up their own numbers.
How to solve these Issues?
Have you ever experience any of these Issues? How did you solve them?
We’ve developed our way to make BI agile and efficient. See our Post “Why Agile BI?” for more info on how we do it.
We also offer a Free Consultation to point out ways you can rescue your BI Projects.
You are also welcome to just leave a comment or sign up for our newsletter.