Here is my #TFFEMEA session today – turned into a blog for you to catch up / take from / read.
Topic – Data Discovery
(Be the change that you want to see).
So you are heading to a new client, or a new sector who wish to use Tableau. Or not even that, you have been assigned a new project at work and they want existing reports built in Tableau and you have no idea where to begin…
I’ve thought about this a lot, and it is one of my favorite parts about the Tableau journey. I feel as if it’s not widely spoken about because you don’t end up showing pretty graphs at the end, but the journey of how that pretty graph got there is actually quite important.
In a business situation you might be limited of what you can and can’t do with the chain above you but i’ve listed out some key questions that inevitably might help your decisions and the process a lot soother from the off set.
I have 5 main questions, a freebie
Here are my top questions I ask to help on the data discovery
- What do you want and why?
- Where does the data come from?
- Who will be viewing the data / report?
- Where do you want this stored?
- Who looks after it for maintenance and upgrades?
For free) Documentation
What do you want?
Firstly – what is it you or they want? They as in those requesting reports. You can look at the requests and ask what is the value of this report?
Am I making it because you are used to having this report every Friday, what does it actually tell you?
If I don’t do it what will happen?
I mean, try to use your time to see what benefits this report has and are different people requesting the same numbers? Could you maybe collaborate a bunch of reports in to one mass report that everyone can use applying different filters to slice the data in multiple ways?
The reports you are producing are there other ways to do it to cut down manual intervention or stop human error?
It’s kind of getting out of being a reporting factory and doing some discovery of your own.
Where does the data come from?
Exactly what it says, where does the data come from?
So normally when I have been on client sites and asked to produce a report I always come back with a list of questions that the client isn’t ready to answer. It might be best to save some of these during a checkpoint of your work perhaps? These answers will help sooner rather than later as it will determine the development of your report.
Is it huge Excel manipulation?
A number of different databases connected in to one to pull data from?
How often does this data refresh?
Do you want a historic record from the previous refresh?
What exclusions are in this data, do we exclude cancelled jobs or exclude NULL values?
Data manipulation is quite a big strain when you don’t have tools like Alteryx to use, i find many a times going to client sites and having a number of Excel spreadsheets and them wanting it turned in to one Tableau report – and your mind explodes.
Recently i unioned 18 sheets of an Excel report in to one Tableau Dashboard and the client had a hallelujah moment. They didn’t know that could be done, and its saved a number of manual hours of cutting and pasting from one place to another. I was able to solve this issue or help by using the questions above.
Who will be viewing the data?
Who is it? Is it the team you are working with, another team or is it high level exec reports?
Exec reports would they mostly be full of BANs (Big Ass Numbers) – the exec level doesn’t need the details, they are mostly interested in just the figures.
Therefore is it sensible to have a more detailed version for the team so if any questions come back, they can easily be explored.
You could have an overview page for your desired audience, finding out who will view this report from the start will help you plan your design.
If showcasing in meetings, do you live bits out on purpose so you can cater for questions to be asked and then show the attendees on the fly and problem solve there and then. This situations are great for winning over a culture change.
So you have your report requirements, you know the build up of it and who will be viewing the reports. You can happily go away and start plugging data, revising data, and building dashboards. Although as you progress and start to save data sources you realise they are either all stored in your Tableau Repository or desktop (mostly for me working on client sites) So i like to have a few checkpoints along the way of my build before getting to far ahead. During this check point I would find out
Where do you want everything to be stored?
Is it going to be a shared folder / drive? Are these data sources going straight to your Tableau Server?
I mean it all depends what kind of data sources you are using, I mostly have to work with Excel on client sites and i save these down to a shared drive or move them once the report is built during the hand over.
Who will look after this report?
During the handover if there is one, i try to find out who will be looking after this report gong forward?
Is it me (if in a permanent role)?
Or is it Billy sat next to me?
Does he know what he needs to do?
So here I would sit with Billy and go through the report to make sure he understands, take notes, drive it yourself and let me watch. Make sure the handover is as detailed as possible. Also – get Billy to send you an email to confirm he has sat with you and gone through it. It might stop that discussion if Billy tends to slip and says ‘I’ve never been shown how to use it’
Often people are asked to produce reports in Tableau and then told to move on to the next one – however, it is always good to get a clear idea who will be looking after the maintenance and updating of the previous reports.
Hopefully you have a whole heap of questions from this that you can utilize in your next build. I wanted to add a freebie tip in that I use in absolutely everything.
I document everything, from the absolute word go and to the minor details. I think this is a hugely important step for any report building process when it comes to business related cases.
It is an endless exercise and very mundane but, I cannot stress enough how important this is.
At a recent client site I was working on, they had nothing documented. Didn’t know where data sources were coming from, the wrong extracts were connected to the wrong dashboards, no one knew how figures got anywhere. It was a mess – you can ask the three different people the same question and get 3 figures in return. By documenting this will stop any confusion, and hopefully arguments of whos number is right / wrong.
We all want one single version of the truth when it comes to numbers. It is always the case Finance has a different number to what you’re workin with in sales.
If it is documented, and calculations are laid out at the start, then when you have that number discrepancy conversation based on a calculation of how you got that % that was signed off two months ago – you know who will win that convo? You will. I always like it when people ask me how I obtained that figure and i can go straight back to them with x plus y.
Sometimes in my work as a consultant, i have to over document because i am leaving the site so I wont be around to ask questions later. I document things such as filters, why have I excluded this, or why have we alias this? Why I connected this data source instead of that data source etc….Always leave a paper trail…..
You might be opening the door for a bigger workload, but if you are anything like my brain and like investigating or problem solving then this work could benefit you more. You’ll learn along the way and could make a difference. Don’t just be a reporting factory or number monkey – be that change.
What is my message for the end?
Go away from the norm a little bit, experiment, don’t be afraid.
P.S. Billy is a made up person where no Billy’s have relation to this post.