So, this seems to happen all the time.
A new software system is set-up which involves many months of planning. Consultants come in and talk to the various interested parties. The users of the system say what they want the interface to look like and what data they want to record. You might even get them to make a process map showing how everything fits together. This gets passed over to the software team who spend time turning it into a project plan and number of bits of code. It probably needs a database or two to hold all these records and user interactions. A round of endless meetings refines this over and over until a good idea of the final project is put in place. Timelines and resources get allocated and everyone starts working on the code.
And then, either just before the deadline, or more usually just after, the email, phone call, support ticket arrives.
“We need some reports for this new system, and we need them by the end of the month”
So you ask for details on what they want reporting and why. You might ask them what information they are after, then again what information they really need (A subject for another blog). You probably sit with them while they go through the interface showing you how they use their shiny new application.
You then go to the software team, ask for a login to the database so you can get hold of the data, and then your heart sinks.
It either turns out that the data the users want reporting either isn’t available in a useful format or worse still missing. If you are lucky there might be some kind of data warehouse, but that only holds a subset of the recorded data. You then have to write your own code to get the data you need into a usable state and then you finally fire up Tableau.
So why does it get like this?
Reports are always seen as an after thought, something optional, something we can worry about later. Well thats just wrong. Reports don’t write themselves, there isn’t a Report Fairy that waves a wand and they magically appear. Tableau might be awesome for displaying information to people in a visual way but if you havent got the information then it’s just not going to happen. The mindset needs to change. If people are recording information into a database then they are going to want to recall it in a report, otherwise why bother storing it? You then have to explain to them that you haven’t got the data and see the shine come off your new system.
The answer to this isn’t difficult at all. The report writers must be involved as early as possible. They must be involved in all the team meetings, they must dictate how the data is to be stored. You know how to create great visualisations, you know the data format that you need to do that. If you need it structures a certain way, make sure its stored like that. And while it’s not much more work, the impact of how it’s designed/stored, can be significant (is it usable when it comes time the grab the data for reporting).
It’s a team effort this software business, but all too often a critical member of the team doesn’t get involved until they cannot influence the way the game as gone so far. Leaving it until extra time to bring on your 11th player is rarely going to turn the course of the game
After all you could have the greatest bit of software that asks the right questions, tracks the users data perfectly, but if you cannot report on it, then you’ve all wasted your time.
It would be like going on stage to put on a rockin’ concert without a lead singer. Concert-goers start trashin’ your band and you end up in a Where Are They Now tv special. Not cool. Definitely not a data rockstar move. Bottom line, wanna be a data rockstar? Get the reporting folks in the conversation, early and often.
