Let’s see if you recognise this one.
You’ve spent weeks deep in the bowels of a BI request.
You’ve chased down the data sources, you’ve wrangled those mothers and made sure the ETL pipeline is flowing freely.
The midnight oil has been burned.
You've made sure everything is where it’s supposed to be and looking just like you wanted it to.
You’ve been:
- dashboard building
- perfecting the visualisations
- and making sure the reports don't just display some numbers – they sing them loud and proud for all to hear.
The magic day of delivery arrives and, although you’re scared of letting your baby out into the big bad world, you know it’s time.
You want to see it soar like the proud eagle you know it is.
So you send it live and…
Crickets. Tumbleweed.
Not so much as a whimper.
Certainly not a thank you.
Hell, after a few days you’d take a stakeholder walking up to you and slapping you in the face. Even if it's for handing them such a steaming pile of dog poo, you'd take it.
But you don’t even get that.
No news is good news, isn’t it?
Well no, not in this case but (not so) deep down you already know that.
Time to check the usage stats to see what exactly has been going on. That's when the big fat zero in the active and lifetime users columns hits you like a hammer.
Right in the fleshy sore parts.
They haven’t even looked at it.
The animals. The scoundrels. The useless dirty %!!%!@ers!
All of that time wasted and it’s not like you just magically decided to spend weeks building something they might want:
THEY ASKED FOR IT IN THE FIRST PLACE!!
You have two choices at this point:
1) break down in floods of salty, bitter tears, rage quit your job and go off to tend a garden in a monastery somewhere in Nepal
or
2) learn one of the most important lessons of a BI analyst’s career – how to make sure what you build is what the business really needs.
As I’m not writing this using my own blood for ink on papyrus scrolls in the Himalayas you can assume I prefer option #2.
Let’s dig deeper.
Why did this happen to you?
Let’s consider why your dashboard might have been ignored in the first place.
1) Timeliness
We all know that BI reports are only as important as the amount of time left until they are due to be used in an executive pack or a regulatory return. If said time period is less than a day then the importance factor reaches maximum levels.
Did you take the original request away and spend four weeks building a full end-to-end BI solution to cover all eventualities?
It might just be that you took too long over it.
It happens.
Agree drop dead deadlines upfront and get some actual confirmation that the deadline being claimed is actually a proper deadline.
If you sit on for weeks after it should have been in then you’ve missed the boat. It doesn’t matter how good your actual dashboard delivery is.
This ship has sailed without you, my friend.
2) Complexity
It’s a well-known fact that as you keep adding more bells and whistles, the likelihood of anyone ever using it starts to fall rapidly to zero.
Stakeholders will always keep adding on more elements as you go through requirements gathering with them. But you know they'll give no thought to whether they will actually be able to decipher what the final report is telling them.
That's where you need to make your expertise felt.
I am all about the simplicity. (My website isn’t called SIMPLE Analytical for nothing.)
Take a long look at the dashboard you’ve produced and put aside your parental feelings of love for it. From a cold analytical viewpoint, have you went overboard and made it too complicated for the average user to understand?
Not the average BI analyst. The average BUSINESS user.
Remember who you are doing this for.
Just because it makes perfect sense to you doesn’t mean it won’t look like the control panel on the Space Shuttle to them.
Better still, ask your users when you deliver it for some specific feedback. Sit with them for half an hour and talk it through. Make sure they feel comfortable asking questions if they don’t understand something.
When the choice between simple and complex arises again in future, think simple. Every time.
Your users will thank you (maybe quietly and internally but they will appreciate it).
3) You didn’t ask the customer what they REALLY wanted
Yes, you may have scanned their job request form and gleaned the bare minimum of what they seemed to be asking for.
What you then went and did was take it upon yourself to decide what they really wanted. Even better, what they really should have wanted to make their working life that extra bit more special than it already is.
Problem there being that you aren’t a mind reader.
There is no substitute for actually sitting down (or getting a phone call) to go through the requirements with the customer.
I repeat: NO SUBSTITUTE.
But this is how we've always done it.
There is no excuse for locking yourself away in a tower and blindly driving on with a long development process on your own.
The general gist of proper Agile project management seems sound to me. Short development sprints, work on well defined chunks of requirements and regular show-and-tell sessions should be no-brainers in most situations.
When it comes to re-doing a badly specced job - Avoidance is always better than cure.
4) No champion
Do you remember back at the start when we looked at the problem that got us into this mess? Back about the time you hit Submit and just sent the dashboard live into production?
Did you notice how there was no mention of sending any comms out to stakeholders who might be interested in what you’ve built?
Did you not think that was strange? Of course it was. But, be honest, how often have you done it?
I know I have.
Sometimes you get so sick of a job that you just want it cleared off your plate. But if you feel like that about it, why should the customer feel any differently?
Let's say you have:
- completed your requirements gathering phase correctly
- set a realistic and desirable timeline for the job
- AND kept the complexity to a bare minimum
Shouldn’t you already have your stakeholder pre-sold on the dashboard being a major success?
They should be shouting from the rooftops about what they are going to get their hands on.
They should be out evangelising you and your dashboard long before it hits their screen.
What if they aren't?
If you don’t have at least one champion on the business side of your request before it lands then you better double down on your post-delivery meet and greet plans.
Set up at least one feedback session about a week after you have handed over the keys to the new reports. Invite the main stakeholders to attend and encourage them to give proper feedback. Don’t let them off the hook easily if they haven’t even looked at it.
Sometimes you have to be your own champion to ensure take-up actually happens.
Better to carve out the time to do that than sit weeping because you delivered your best work and no-one cared enough to appreciate it.
How should this all work in the real world?
So how far do you have to take it in terms of:
- getting the reports out quickly enough
- talking to the stakeholders before you build anything
- talking to the stakeholders after you build something
- then making sure all the way through that it’s simple and easy enough for them to understand and use?
Each job will be different and it’s experience in the role (and your own company) that will dictate the amount of hand holding that will be required.
I understand it’s usually the coding and development phase that gets analysts interested in a project. The last thing you want to do though is ruin all of the great work you put in by telling yourself it’s the customer’s problem if they don’t wind up using what you built for them.
It’s not, it’s your problem too.
Maybe not just today when the feelings of frustration are overwhelming you either.
It might be further down the road when, despite the great work you’ve produced, some pen-pusher comes along when job cuts are being made. If they can’t find anyone at a senior enough level to vouch for the value you’ve produced over the years, what do you think the result will be?
Visibility is key.
If you're locked away tinkering in your ivory tower all the time, to the untrained corporate eye, you might as well not be there at all.
You have been warned.
Take ownership of your project and your end result.
If you don’t, who will?
If you enjoyed this article, come over to SimpleAnalytical.com for more stories, hints, tips and strategies on building your analytical skills and career.
Top comments (2)
I recognise this one ... as with all your posts :)
The more I work with software devs the more I see the value in creating an MVP quickly and working from there. The more I do this, the more I find that the requester really just wanted a quick and dirty answer to their question. Slaving away over ETL, beautiful dashboards and the maintenance that comes with all that is sometimes unnecesary.
There isn't a lot of job satisfaction in pulling together something on the fly when it could be so much better and stop them coming back in three weeks for the same thing. But at the same time it requires them to use self-service, maintenance of the dataset underneath it and in reality, I've saved the code so I can just rerun it if it's not too involved.
The long-term BI projects I've been involved with require a Stakeholder and signed off Requirements doc from the get-go. No doc, no work. Going back to the Stakeholder every milestone or a couple of weeks is crucial in keeping them interested and scope creep to a minimum.
Data is easy to wrangle, people aren't :)
"Data is easy to wrangle, people aren't :)"
Never a truer word spoken!