Why Analytics Projects are a Mistake
Before you go and start a new analytics project, consider these sobering statistics.
As far back as 2005 Gartner began ringing the warning bells. ”More than 50 percent of data warehouse projects will have limited acceptance, or will be outright failures, as a result of a lack of attention to data quality issues” they reported.
In 2012, Howard Dresner’s Wisdom of Crowds Business Intelligence Market Study reported that only 41% of users considered their business intelligence projects to be a true success.
In 2015 Forrester reported that 64% of analytics users struggled to relate available data to the business questions they were trying to answer.
And if you think that’s bad, I believe things are even worse than they appear. I’d go so far as to say that the entire approach taken nearly 100% of the time is plain wrong.
For the majority of companies running them, analytics projects are a huge mistake.
You may think that’s a cavalier assertion, but hear me out on this one. Do a quick Google search on ”why BI projects fail.” What you’ll see are pages and pages of expert analysis and guidance. Article after article explaining how to avoid well-understood pitfalls and lead your analytics project to success. Unless these experts are all frauds, it stands to reason that by following this advice you can have a successful outcome. Yet, while everyone endeavors to follow this advice, the majority of users are still unsatisfied with the final results.
Why is this?
Well, the reasons we hear again and again have to do with complexity and communication. Yes, business intelligence projects are complex and it is easy to underestimate this complexity. And yes, business users will always find it challenging to define their specific needs, and nearly impossible to do it in terms that the technical team can understand and relate to the available data. But these ”causes” are a given, not something we can fix. Blaming them for our failures is like blaming obesity on hunger.
No, the real problem is something else entirely. Something that we’ve been overlooking for far too long because it is much less obvious, and not something easily dealt with. A few practitioners have touched on it before, but usually in a discussion about “agile BI” or some other equally hard-to-understand jargon. So let me put this in the simplest terms possible: the real problem with business intelligence projects is that they are projects in the first place.
There is a fundamental conflict between the requirements for successful business intelligence and the idea that it can be accomplished with a project.
The most successful analytics professionals I know all agree on one thing: business intelligence must be an ongoing, iterative process. And for good reason. At the outset, business users don’t know what they don’t know – it takes exposure to the data to identify the gaps in one’s knowledge. Technologists don’t know what can and can’t be delivered ”” they must first understand the requirements and thoroughly understand the underlying source data. It’s a chicken and egg problem, and the result is that it takes a significant amount of back-and-forth to arrive at an optimal solution architecture. Even then, data and reporting initially thought to be out of scope suddenly looks like a priority. Quickly new data becomes available, source systems are upgraded or migrated, and the whole process starts all over again.
Yet for two decades the vast majority of companies have thought of business intelligence as an IT project, something to be completed and checked off the list. For all the reasons listed, this is exactly the wrong approach.
We have to stop thinking about analytics as a project, or even as a system, and start thinking about it as a core function of the business, like we do marketing, sales and operations. We don’t speak of conducting a sales project with the expectation that at the project’s conclusion we’ll have all of our sales needs met. And this approach is no more appropriate for reporting and analytics.
We also need to stop thinking of analytics as a function of IT. While reporting and analytics may rely on technology to a greater extent than other business functions do, this is not its defining characteristic.
Like all business functions, analytics requires constant attention and the development of resources and expertise over the long term in order to succeed. It also requires a company-wide focus on collecting, governing and utilizing data to make well-informed decisions rather than relying on gut instinct, and this will never happen if it’s a “project”. When we overlook these facts and treat analytics like an IT project rather than a core business function we are fooling ourselves about its true nature, and setting ourselves up for failure.