In this little series, you'll learn about 10 BIG mistakes that companies regularly do, when they run data or analytics projects. I've been doing data consulting for quite a while now, and over time, some clear patterns popped up.
In other words: typical problems that burn your money, staff and time. The good side about it: all of them can be avoided.
This is part 1 of 2 of the series, with mistakes 1-5. Find the second part containing mistakes 6-10 here on this blog.
You are a video person?
You can also WATCH this article as YouTube video. If you like it, please give it a like, subscribe to my YouTube channel and feel free to comment below the video (you will need to click the YouTube logo).
Why does it matter?
Now, before we jump into the actual mistakes, let us quickly talk about the context here. Like for many things in life, there is no clear right or wrong.
Some organisations or teams succeed in a way, that doesn't work for others. Some do succeed with their projects, and reach their goals, but it's very painful, costly and when they look back, they could scream!
However, although there is no black or white solution here, there are clear patterns which make some companies much more successful than others. And at the same time, lots of these best practices can be adapted.
Why only lots of and not everything you may wonder? Well, because every company is different. Haha, the classic stupid sentence of any consultant - but it's kinda true.
For instance, if you're a startup company with lots of digital natives in your team, you'll have a totally different starting point than many enterprises. This includes your company culture, they way you work, historic circumstances, technical solutions, and yes, even politics.
On the other hand, large companies can afford lots of external help, the best solutions money can buy and often have a known brand that people already follow. As you see, in my simplified scenario, the best solution (whatever the best solution or advice actually is), is probably very different.
Besides: you should always look out to do what fits your maturity level. If you're just starting to become data-driven, you'll want to do totally different things than if you're already several steps ahead on the ladder.
Imagine it like this: a great photographer can shoot amazing pictures and tell great stories with any camera, while a beginner cannot take any advantage of a 60,000 EUR cinema camera. You need to take your circumstances and maturity into consideration when doing your next data project.
10 BIG mistakes in data projects
Let's take a look at 10 BIG mistakes that I have seen companies doing over and over again throughout the years, wasting a lot of money.
For the list itself, it doesn't really matter about what kind of data project or program we're talking about - but obviously, the larger the more difficult.
Whether you're into business intelligence, AI, data science or whatever, you can learn from and avoid these mistakes.
Take them as guidance and advice, rather than strict rules.
[#1] Focus on technology only
Unsurprisingly, many data projects include some sort of technology. This might be a data warehouse, some digital tracking solution, scripts for data analysis or something else.
Look, the issue is that a company is a place that - still as of 2021 - consists of human beings doing most of the work. The bigger the step forward with your technology, the harder it might be for the people to catch up.
What you want to do, is focus on technology and enablement and culture. Especially from the data analytics perspective, technology is useless if you don't have people using it PROPERLY. This can have many different reasons:
- it's too complex and not simple enough to use,
- or people don't see the value or benefit of spending their precious time with your solution,
- or they are simply not used to work in a certain way (sticking to what they are used to),
- or people are afraid using it - they don't want to break something
- or their processes are incompatible with the way your solutions works
- or many others
And let's be honest: transparency isn't always desired in companies, in particular when systems can lead to a direct or indirect ranking of the work quality or outcome of employees.
When you are responsible for any kind of data project, make sure you don't forget about the people. If you don't use it, it will not have any impact. Think of an enablement program, to turn sceptics into your biggest fans!
And no, a training or workshop of how to use it is not enough. Ideally, you already incorporated your stakeholders deeply into the creation of the solution, but that's another story.
[#2] No attention to data quality
Watch out - this one might be familiar to you: You have spend some considerable amount of time on a new solution - or say a new report. You figured out all the nitty gritty details, and went at least one extra mile to make it even look pretty. Of course, you're very happy when you finally present it to your colleagues.
First impression is great, but just after 1-2 minutes, someone says "there must be an issue in your report - this data for sure isn't correct". Others jump in: "hm ya, looks a bit weird". You do your best to steer the conversation, but you already know, that was not the impression you wanted to create.
Look, this probably happened to everybody dealing with data already. In smaller setups this might not be an issue, but in larger projects or organizations, it's doing no good to you or your project.
Actually, it's even more severe: have such a situation few times in a row, and nobody will use your report in the future. The whole success of your project could be at danger when people don't TRUST YOUR DATA.
I call it the data vicious circle: the less time you spend on high quality, accurate data, the less people will trust your data; this usually means, they'll use it less and less; with a lower audience consumption, you may take even less care in the future and I'm sure you'll see where this will end up: in a failed project.
[#3] No self-service / data democratization
Data is great for better decision-making, but also for activation, that is making use of data in any kind of operational system you're using, like your Sales CRM, your marketing solutions or your finance tools.
In today's world, and in particular in digital business, data is a huge boost to growth, can save you considerable amounts of money and accelerate your business or progress. It helps you to know your customers better than ever before. And the list goes on and on and on.
In short: better access, insights and usage of data it can be a game-changer almost everywhere inside the organization.
Now look, if this holds true, wouldn't it make a lot of sense to give EVERYBODY access to such data, not just a few? In a way, that other teams can work with data & analytics in a way that suits them best? Without coming to you for everything they want?
Hell yeah, this makes a lot of sense and is called self-service analytics or data democratization. I've seen countless examples on this firing up the afterburner for companies.
But beware: just technically giving others access will not change much, if anything. It's a cultural topic as we've seen, and therefore, you want to have a better game-plan behind.
[#4] Not giving departments what they need
This one is super simple to understand, but a huge issue. We shouldn't work on data & analytics JUST because it's cool - which IT IS!
We should work on data & analytics to have impact on our business and goals. When you ask upfront, everybody tends to agree that you should only spend time on something that helps you and others to do a better job.
However in reality, we see this becoming an issue more often than not: teams work on data projects and functionality that do not have a clear scope, use case or impact in mind ("it's probably going to be useful!").
And at the SAME TIME, the real business requirements from other teams are not fully covered. So you have something that does solve issues that don't exist - AND fail to have solved the real pain.
If this sounds familiar, do a full stop and go some steps back, doing a proper discovery of the project scope. Especially if you're waterfall-planning your projects, with long requirement lists upfront (opposed to doing it more agile), this will almost 100% become an issue.
[#5] Starting too late
This one largely depends on the circumstances you're in, but after all i'd say: you can and should always start with data projects, no matter where you stand. The real key is, to do what fits your own maturity level.
In other words: don't over- or underfit your solution to your maturity, but make sure you do create the possibility to benefit from data.
Let's look at one example: if you want to go grocery shopping at home, you won't take a huge truck. Instead, you may take a normal car, your bike, or just walk. You'll probably not take a Ferrari sports car either, because cargo space is super limited. What you do, needs to fit the purpose and the circumstances.
The same situation holds true for companies: while it's not always straightforward to choose what's the best approach or solution, there's always something. The days are gone, when every data project turned into a monster project by design. Even within your own department or team, there are so many possibilities to just go ahead and start doing it.
In an early maturity, this can be simple dashboarding software (like Google Data Studio) combined with a tool to automate data integration (e.g. Supermetrics) so you don't have to manually copy data around. In more progressed maturity scenarios, this can mean investing into full business intelligence setups and beyond.
The later you start, the more potential benefits of data you'll miss, the more decisions you'll have to do without appropriate analytics. Compared to some years ago, you don't even have to spend any considerable amounts of money. It's cheaper, faster and easier than ever.
Recap of learnings
- Do not focus on technology only - see the big picture of how data is used within the organisation
- Pay attention to data quality (e.g. not showing inaccurate data), because otherwise people will lose trust in you and your solution
- Ultimately, you should approach a self-service analytics culture, in which teams are trained and incentivised to work with data on their own - without coming to you all the time
- Make sure you know what the real requirements of the stakeholders are - challenge requirements if necessary by their business impact and help them to help themselves
- Start early with your data journey, but make sure you find a solution and approach that fits your organisational data maturity
See you next time and make sure to check out part 2 of this series here in the blog once release. Subscribe to my newsletter to get notified once part 2 is released!
