In the previous article, Please, no ad hoc data requests any more, we witnessed two conversations between Eva from marketing and Tom from the data team. What happened in the second conversation to make it much more pleasant for both Eva and Tom, and much more positive for their organization?
First, Eva suggests co-building the analysis with Tom!
Then, two positive factors come from the willingness of our two interlocutors:
-
Tom, having already been involved in monitoring previous collections, demonstrates business literacy, helps Eva specify her needs, and proposes ideas. Eva feels more comfortable involving Tom in her issue and can clarify her business questions, knowing that she is understood.
-
Tom feels better because he sees that Eva has, or has developed, analytical reflexes and possesses a form of data literacy. This doesn’t necessarily mean she has learned to write SQL queries! But she knows that for data to be archived, maintained, and leveraged on a large scale, it must first be modeled in a standardized manner and then subjected to aggregations that vary depending on the context. So, she knows enough to put herself in Tom’s shoes and understand the complexity of what she’s asking.
But Eva and Tom are also lucky to be supported by foundations which are the result of collaboration between business and technical teams:
-
Shared documentation where processes and metrics are detailed.
-
Master data, which includes everything related to collections, is available and explorable by everyone in a single source of truth. This means they avoid having to rely on manually edited and exchanged files, which, as the subjects multiply, add a significant cognitive burden.
Following this exchange, Eva and Tom understood each other, and it’s easy for Tom to provide a quick response. Moreover, the work Tom is going to do will be used in a recurring report, providing important information to the business… and it won’t be an ad hoc request anymore!
Ad Hoc Requests Fail at the Translation of Business Needs
In fact, the heart of the problem lies in the second step, where the initial question is translated.
Neither of them truly takes the time to put themselves in the other’s shoes, and their exchanges gradually become transactional. Instead of sharing the business problem, they have to specify a specification document, which is written in a language that is difficult for the business to grasp. If the result doesn’t meet expectations, the specification document will be used to argue that the request was poorly specified. In the best case, the cycle repeats until the right solution is found, costing everyone a lot of time.
I will share the different negative outcomes I have observed in environments where the business-technical relationship has become at best transactional and sometimes outright difficult:
-
The business operates without data, disconnecting itself from data-driven decisions or a more comprehensive view.
-
The business makes far fewer requests, consolidating all their needs into a mega-request for a massive data extraction, which they will then struggle to manage in Excel.
-
The business routes all data to a third-party solution or provider that offers to leverage their data and sell it back to them in the form of dashboards and studies.
Moving Away from Ticketing
The key to getting out of this situation is to view the qualification of needs as an opportunity to transmit data literacy to the business and business literacy to the technical team.
Ticketing is tempting for technical teams. Centralizing, streamlining requests, trying to assess and quantify effort, assigning tasks… But let’s remember that ticketing was primarily invented for outsourcing requests, level 1 support, requests that are generally similar or at least within an “expected” realm: a specific product, a particular piece of equipment…
While ticketing is indeed well-suited for support requests, it is not at all suitable for action-oriented requests, not just creation but creative ones. By adopting a more open approach to collecting requests, many questions will be asked initially, but as requests repeat, everyone will become more knowledgeable about each other’s domains, and it’s not hard to bet that many difficulties will naturally be resolved.
However, this doesn’t exclude the implementation of internal tracking of requests by the data team to measure the burden of ad hoc requests and its evolution, distribution by requesting team and theme, request typologies… On the contrary, it will be a valuable tool for Turning Ad Hoc Requests into Opportunities, the subject of the next article!
What about self-service? Wouldn’t it be simpler to let users access data themselves?
Tough question. Self service does not fit everyone’s needs and is not something you just enable by opening access rights.
In my opinion, in short, the two are not mutually exclusive but complement each other. I will delve into this in more detail in upcoming articles.
Thank you, but how to handle all these requests?
A data team should always be seen as available to handle ad hoc queries… while ensuring they don’t get overwhelmed!
As mentioned earlier, in the next article, Turning Ad Hoc Requests into Opportunities, I will propose a way to distinguish requests to better prioritize them and incorporate the corresponding effort into more easily plannable projects.