Data Thinking (for business users)

Over the past decade, all enterprises have been focusing on being data-driven. Data and data platforms have evolved over time and organisations have geared up to use data as a differentiator. So, what do these data & insights requirements within an organisation look like:

• Visibility into what a specific business (or a business unit) is doing and how they are performing – KPIs based. We all know this as descriptive
• How is the past performance and data going to influence the future? This is the predictive part
• I have some hypotheses; I have some ideas, but what is the data telling me? How else and what else should I be doing? This is more interrogative style
• What should I be doing to ensure that there are minimum interruptions in my factory line - what temperature, torque and pressure should each machine operate at? This is the typical prescriptive style.

From a technology landscape, each of them need to be dealt with differently. For some of these questions, there could be other possibilities like aggregation of these insights at an overall organisational level and their alignment with the business goals. Many enterprises delegate data and insights requirements to IT departments, i.e., the technology teams. That's where the disconnect starts and the data projects drag on for years....and also doesn't meet all business requirements. Hence the need to focus on how and who should initiate the value chain for creating data requirements and how to prioritise those requirements.

It is fairly evident that one of the most important aspects of leveraging the power of data is crafting clear requirements or use cases. While different methodologies already exist like the standard business requirements document (BRD), CRISP-DM, Team Data Science Process, they focus either on the overall framework of execution of the data mining process (like CRISP-DM) or are very traditional and lengthy in nature (like the BRD) which makes it counter-intuitive for business users to start this process.  In 2019, Zhamak Dehghani from Thoughtworks made a case for an architecture pattern called Data Mesh which again emphasizes the need for data product thinking and is more of an architecture rather than a business tool.

So, is there a way to simplify the process and start at the beginning / the origin - the core aspect of the data journey i.e.; defining the requirements for data & insights by business users. Let us consider a 2 step approach for this and for the sake of articulating the process, let us consider a group of clinics that has patients foot-fall for PHC (Primary Healthcare Conditions)

1.Create the “data idea”

A high level representation of what the business user intends to do with the data, expressed as a requirement. Let us do that as a question

-      How many patients are coming into the clinic on an average in a day?

-      What are the top 3 PHC “conditions” that patients are suffering from?

-      How is clinic A faring when compared to clinic B in terms patient foot-fall?

2. Build the "data story"

At this stage, the idea can be expanded a bit more and take the shape of a user story. The intention here is to add a bit more meat on the bones and explain the intention in a much more clear manner. Taking a cue from the previous examples, this is how they would get transformed:

-      As an operations manager, I would like to understand average number of patients at the clinic in a given {day}/{week}/{time of the day} so that <I can plan for staff availability in the clinic>

-      As an executive administrator, I would like to understand average number of patients across all clinics in a given {day}/{week}/{time of the day} so that <I can optimize staff across clinics>

-      As an executive administrator, I would like to understand how {Clinic A} compares to {Clinic B} or {overall clinics} in terms of average footfall of patients in day so that <I can create a score card across clinics to review performance>

As you can see, at this stage, there are more details. But more importantly, all the good features of user stories can be leveraged - group requirements, define success criteria, identify the persona, map it to a business need. Another important characteristic at this stage is to create multiple user stories for each user persona. That way testing the user story as well as the need for building such a metric is evident to the technology team

 Post this, it would make sense for the business team to evaluate the priority of each of these ideas and user stories. Customised versions of Gartner’s ROAR framework can be used for this. This helps business funnel their data thinking across different grroups better. This prioritised list is what the technology team can start working with, maybe create data model canvas (as a initial design guideline) and build the pipelines, reports, ML models etc to meet the requirement.

This is an initial attempt to understand and synthesise the idea around how to get business users start thinking and talking data. The intention is to borrow from the existing practices like design thinking, user stories, decision making to initiate conversation in this aspect. More than happy to hear your feedback!