For the data teams, knowing the hearts and minds of end users is a vital ingredient to success…
When business people are asked ‘what reporting do you need’, there are typically one of two instinctive responses: ‘You tell me’, or ‘Give me everything’. Neither one is any good if you are to create and deliver solutions which are valuable to users.
If that sounds like the wrong foot on which to get off on what are typically complex, demanding and high-value projects, you’d be right. Data analysis projects more than most require extremely good communication between business and IT teams, primarily owing to a problem which best characterised as ‘you don’t know what you don’t know’.
This problem routinely crops up in data analytics, as, while business users might have an idea of how analytics can be used within the organisation, making it a reality depends on their ability to explain that to other people – and it can be very difficult to visualise. Once you have your business team on side, getting quality analytics delivery in place depends on a close interaction between those who know how to make it happen from a technical standpoint, and those who need to specify what it is that they want.
Further complications arise because the way data is captured isn’t necessarily the best way to analyse it. This means technical skills are necessary to get the right data into the right format. This is a crucial step – but getting this in place isn’t the end goal of analytics at all, though it tends to become the focus.
That’s because a fixation sets in with getting the data sorted out. Specifying and analysing the data for accuracy and suitability becomes the entirety of the exercise, rather than delivering insights from the data.
It might sound crazy, but there is an abundance of projects which get bogged down in this situation. Years go by, with no useable output but an absolute heap of time wasted on specifying requirements. Projects like these are in effect mired in the technical phase, with little or no focus on business outcomes and generally, it becomes apparent that the technical experts aren’t talking to the business side of the house.
And yet, from a technical standpoint, ‘progress’ is being made. The data is clean. The data warehouse is populated. By now though, the business has moved on, with needs that have changed, often dramatically, since the data warehouse was planned and the project signed off.
What happens in such scenarios is that shadow IT initiatives spring up as pockets of frustrated executives bypass the stalled data warehouse and create their own data sources. That raises the spectre of incorrect data driving poor decisions, failed governance and an IT department which has lost control of its most important asset.
This leaves many organisations in a position where they have one of two problems. On the one hand, the data teams are unlikely to get it right the first time, as the business users don’t know what they want until they see it.
On the other, even if the data team did get it right, it doesn’t look like it. That’s because so much time went into building the data warehouse that on completion, the business has moved on and it’s no longer relevant.
Solving the apparent conundrum depends on an agile approach to working with the business (learn-show-learn-show). You need to speed up the technical delivery – and that’s where the right software makes all the difference, automating the rote stuff and keeping the focus on the end goal of creating business value.