Analytics: Best Practices for asking Information

We as business areas are regularly in charge of producing reports for our teams and even different areas of the organization.?And one of the tasks we have to deal with almost every day is to ask for information to our Data or Technology teams. Some of these teams have a very manual process (email), while some of them might have a ticketing system with a very nice UX.

Normally, we see this (asking for information), as a trivial step: “send me sales for each region in the last 3 quarters”, “I want to know the inventory levels of the Top 10 products of 2022”, and the so.?This 1-liners usually have much more information related to them and it is our responsibility as information owners to know how to ask for it in a complete manner so we are efficient with everbody's time.?This post is a first approach to deal with this situation.

Phases of a Request

To start with, I believe there are three (3) phases during any information request process: 1) before we actually ask for the information, 2) while the data analyst is producing the information, and 3) after we receive the information.?I will detail below some best practices for each one of them.

Before we ask for information

This is the key phase and the one we should really care about.?Here we think, analyze and re-think about the information we are asking and we define it with as much detail as possible.?? Some best practices recommended:

• Answer a Question.?Do we have an actual question to answer? or are we just exploring data to find patterns? They both can be important and necessary, but they need a totally different dataset.?The first one would require a well-defined dataset while the second one might require additional information to help us understand and play with the data, additional columns we might need, and the so.
• Use Complete Requests.?Ask for a well-delimited set of fields, and define them a priori.?This will let the people in charge understand the granularity of the petition (do I need to send the total of each invoice or the total at the item-level?), also it will permit the responsible team to properly estimate how long would it take to obtain the information.?Be as precise as possible.
• And we should always remember: If we think something is too obvious to be added, we should add it. We have our view of the business, while the team producing the data will most likely have a rather different view of the same business area.
• Rehearse (like we already have the data). ?This is often something only a few people do, which is to rehearse, and simulate how the data requested might come and how to embed it into the analysis we want to finish. Remember we can always generate a fictitious dataset using Mockaroo or GenerateData , which are quick and simple, so we have our analysis (graphics, tables, stats) already built when we receive the data.? Productivity tip!
• Assess Importance and Urgency.?We should ask for the data with the proper importance and urgency. Normally, each company has its own framework to prioritize tasks, and we should make good use of it. If we are not sure, we should tell the Data Analyst we need it with the lowest priority, e.g. two weeks from now. ?Remembering there are more people being served is always useful.
• Define a Deadline.?We can always share our reference deadline and business rationale with the analyst in charge of the petition, so they understand why are we asking for it and also they can relate with other similar requests.
• Think Security.?Most importantly, we should not ask for information that might be considered personal (PII) such as email, telephone numbers, names, government IDs, etc.?Ask Data to anonymize it in case we need it.?We can always go to public anonymous datasets that we can plug into our data analysis.

While we wait for Information

• Communicate, communicate, communicate.? We should talk to the person who is obtaining the information for us and ask about the progress, being respectful of the estimated time of completion of the task. But at the same time, we should always be present.
• If the analyst has an issue fetching with one or more fields, this is the time for us to prioritize and perhaps receive the information in one or more requests.?Also, if we found out the information is not as urgent as it was before, we should update the analyst so they can shuffle our request and work on a more urgent one.
• We should not expect the analyst to be a magician and send us the right information the first time we ask for it, without further context. More than often, a quick call will reduce the processing time from days to a hours.

After we receive the information

• Don’t scope creep! This goes inline with the complete request requirement explained before.?Once we receive the information, we should use it, test it and squeeze it if necessary. If we realize we forgot one or more fields, we should ask for them using a different request, unless the analyst has nothing else to do or if the marginal cost of obtaining them is close to zero, which is pretty unusual.?We should think about the analyst as a person who is serving a line of customers, and we should be respectful of all the people we have behind us.
• ?Give Feedback.?We need to tell the analyst if the information was what we needed or not.?Also, we should let the analyst know if there is something that could improve the process to send the information properly.?
• Ask for Insights. Data analysts are often people with a very different view of the business, and knowledgeable in different portions of the business we might not be that familiar. We should think of them as consultants and ask for insights once we have the data. We could always ask for insights before we ask for it, too.

---

I am sure there are things we as users can do to improve the way we ask for information, but I considered this initial points as a common-sense start. Comments more than welcome.

See you in a few weeks,

G-

--

Opinions are 100% personal. Contact me in LinkedIn.