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.
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.
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. This site 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 permalink
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.
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? permalink
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.
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.