As business owners or process managers, you are likely to be interviewed by somebody that’s building your solution so they can collect requirements. These people want to understand what’s needed in order to capture that value that you’ve identified. The way that’s going to be done is through some type of an interview process. It may be formal, it may be informal, but in some way or another information needs to be collected from you so that we understand what needs to be built, how it needs to be built, and who it’s going to be delivered to.
I want to start off by just saying, there are no guarantees on the first-time approach. You, as the person providing the answers to these questions, are going to provide the best answers you possibly can today. A lot of the time you’re not going to be 100% correct, because you don’t have all the information you need to answer these questions. But you’re going to do the best you possibly can so the people building the solution can get as accurate as they can on the first iteration. Then it will be just that, an iterative approach. After the first set of reporting solutions are delivered, you’ll then have more information. You will have learned more about the overall solution and its effectiveness, and you’ll be able to adjust.
This gets into another concept of being able to be agile in a reporting solution or a data warehousing and business intelligence solution. Which is a different topic, but it’s extremely important. The idea here is we want to be able to go to these people we’re interviewing and say, “Give me the best information you have today. I know it’s not going to be perfect but give me the best you have today.” I’ll take that and I’ll go build something that’s going to meet those needs. Then once the requirements change, we learn more information, we’ll adjust to those changing requirements. Hopefully, if done well, we’ll be able to adjust without a lot of rework.
Back on topic, which is requirements. I’m going to go through some of the questions that we ask in order to collect or cultivate this information from whoever we’re interviewing. The person we’re interviewing is going to typically be the person that’s requesting this report to be created. It could be an individual contributor, it might be a manager, director, or a business owner. It could be really anyone that has come up with the idea of creating this report. One of the first questions I like to ask is, “Describe the business process that we’re trying to impact. What is the process we’re trying to interact with?” This could be anything. If we’re talking to someone in finance, it might be a process to manage accounts receivable, for example. If we’re talking to someone in operations for healthcare, it might be managing resource schedules. It’s something about a business that is ongoing that we want to try to improve.
It may not be a process in the traditional sense. It could be the executives just simply wanting to get insight into the operation. I call this the ‘meat and potatoes’ type of reporting that every company should have. At a minimum, you need to know what’s going on. That as well could be the response. This is not necessarily a business process, it’s more of us understanding what’s happening in business as a whole. That’s a perfectly fine answer as well.
Once we understand what the business process is that we’re trying to impact, we want to try to quantify that business process in some way. This is going to vary quite a bit. What we want to do is get down to the time and the money that’s being invested in that process. It doesn’t have to be down to the dollars and cents, of course. We just want to quantify this in some way. If we’re talking about the finance scenario, we might want to say, “Look, right now we’ve got two full-time resources working just on this all year long.” That’s the amount of expenses that we have invested in this process.
We also might want to quantify why that process is important. What is the value of that process? If we’re talking about A/R, the value of it is that we’ve got to be able to collect on all this A/R. We might focus that a little bit and say, “Without doing these things that we’re talking about in this business process, we wouldn’t be able to collect our aged A/R. Maybe anything over 90 would just go stale forever.” I don’t know how it would be quantified, but we would try to quantify in some way the value of the business process. We know the cost and we know the value of the process, that really gets our mindset around how important this solution is going to be.
The next couple of questions are pretty simple. Who manages the business process? I’ll stick with the finance system. It might be the CFO, it could be an A/R manager in our example. But who exactly is managing that process, meaning who is responsible for seeing that process be successful? Then who interacts with the business process? This could be anyone from individual contributors, it could be third parties, a whole list of the people that are interacting with that process.
If we go back to the question number one, which is to describe the business process, if we’re talking about a complicated business process, we’ll typically use a a flow chart. We will identify at each point in the process who is interacting with that part of the process. This varies quite widely of course. We want to understand the people that we’re going to be working with and try to aid in doing their job better, make them more successful in what they’re doing. Who are those people interacting with the business process is what we want to know.
The next question gets down to the pain point. Which part of the process are we trying to improve? That’s it. We’re talking about A/R, that’s a pretty easy one to understand if you’re talking about accounts receivables, you want to collect as quickly as possible. Maybe the answer is we really want to be able to collect on our 90 day plus aged A/R buckets faster. That’s what we’re trying to accomplish. You notice that I’m talking about the business requirements. I’m not talking about anything else, like the method used to do such a thing. It’s “what does success mean to the business?” In this case, we’re saying if we can collect on A/R a little bit faster, that’s how we’re going to try to improve this process, an increased collection speed.
Then on top of that, we ask if we’re successful, what value will we add? This probably doesn’t come as news to any of you that have been listening to this podcast. I really believe that it’s extremely important that we identify the value that we’re going after. We’ve got to understand what that value is. Again, if we’re talking about accounts receivable and we’re saying that we can increase the collection speed, if we can do that, it’s basically a one-time increase. If we can sustain it, maybe the value is we’ll just say $500,000. Whatever that is, it’s important to understand it.
It’s important for many reasons to understand the value of what we’re doing. If it’s only $5 we’re going after, we could stop the interview right there and say this is not going to be something that makes sense. We’re going to spend more than $5 building this solution. On the other side of things, if we say it’s a $500,000 opportunity and time is money, which we’ll get to in a little bit here, that might change how quickly we try to attack this problem. It’s very important that we identify what success looks like and what value we’re trying to actually capture.
The next part of the interview process goes into what we need to do to be successful. We ask what information is needed to improve the process and we break this down. That’s a wide-open question. We try to break that down into, first, what measurements are needed to make this process improvement happen. It could be that we need just more refined data sets, for example, in order to know exactly where that aged A/R lives, who’s the responsible party. What is the actual age, what type of service is the aged receivable associated with? What’s the likelihood of collecting that type of responsible party? The person that is coming up with the idea of building this report likely already has a lot of that insight. Collecting that is critical.
We’re basically asking, “Great, now we know we’ve got an opportunity. What do you think we need to do in order to capture that opportunity?” We try to break that down into measures and dimensions. Now this is not necessarily something that a business owner or a person being interviewed needs to be concerned. The person that’s asking the questions is likely thinking about things in those measures and dimensions terms. We want to know which measurements do we need to capture and what dimensionality? In other words, if we’re saying again, A/R, if we’re talking about the outstanding balance as our measurement. The dimensionality would become by responsible party, by the service associated with the A/R, by time, by age, all the things that start with “by”. That’s our dimensionality. That’s how the interviewer is likely thinking. From the standpoint of the person being interviewed, though, you should just be able to provide a brain dump of what you think is needed to improve that business process.
We know a little about the business process, we know the value of improving it, and we know what we need to do in order to improve it. At least we have a good theory at this point of what we think we can do to improve that process. The next thing we’re going to talk about is where is this information that we need in order to create a report to deliver on this value. Typically, this is going to be in a business application. I guess I’m stuck on the finance example here. If it’s a business application, it could be an ERP system, could be a finance system. It doesn’t really matter if it’s in a business application on the technical side of things. We have to go into that database and pull the information out that we need. It may be spreadsheets that can become your data source. It could be a combination of data sources.
Where is the information stored? We need to find where the information is stored and how are we going to access the raw information that’s needed in order to build this report. Often the businessperson that’s being interviewed will not know a lot about the actual data store. They might know the application where the raw information is entered. They might not know where the data is stored, but that’s fine. We just want to begin, get some clue about where the information is coming from. Of course, as you work with your team, they are going to already have a pretty good understanding of where these different data repositories live. It’s not very difficult to find the data stores.
Now the next question is how is the raw data collected? This is sometimes really, really important. What happens is, you’re entering raw data. Either a person is entering information into a system, or some automated process is generating these records that are stored in these systems. The way that data entry is done is going to impact what information is stored.
Sometimes there’s special cases. For example, if you’re working with a business system that doesn’t exactly support what you’re trying to do, people get inventive about how they’re going to get the job done. They might take fields that are in the business system and use them for something other than what they were designed to be used for. They might even take comment fields that are designed to be free form comments and start putting standard information in there. There are all sorts of things that happen and it’s important that we understand if any of those things are happening, at least to the extent that the ones that are relevant for what we’re trying to improve with this business process. How is the raw data collected, is the question.
We’re going to move a little bit into delivery. The question here is what is the ideal delivery method? The answers might be anything from: I want this report to be delivered to me in an attachment in an email every day. Or we’re going to use Power BI and self-serve the report. Maybe they’re going to self-serve and they’re going to use the data model directly and do ad hoc analytics. Maybe they’re 100% going to use this on a mobile device, because this is a remote process. Maybe it’s a type of programmatic delivery. We need to generate flat files and FTP them somewhere. There are a lot of options, but it’s very important of course, that we don’t just assume that we know the answer to that question. We need to ask. What is the ideal delivery method?
Then the next question is, “What’s being done today, or what is in use today to solve this problem?” The answer might simply be nothing. They might say they are doing nothing and that’s why they are coming to us. Sometimes that’s not the answer. Sometimes there’s some type of manual process in place to fill this gap. That goes down the avenue of, “Well, what’s that manual process costing us today? There’s another value proposition. We can possibly eliminate the need for that manual process and free up those resources to do things that are more valuable.” A manual process is a possible answer to this question.
If there are existing solutions in place, then what is deficient about those current solutions? If we’re talking about a manual process, is it slow, or error-prone, costly, etc. If there is something else, then what’s deficient about it? We don’t want to go off and build a solution and end up with the same thing we have today with the same deficiencies. We want to understand what those deficiencies are and address them with the new solution.
There might be something in place today, like a sample report. It’s even possible that there’s a report that’s being created manually that is perfect. It serves the need; it gets the job done. It’s as simple as it possibly can be. We look at that sample report because now we’ve got a very clear direction. We know exactly what we want to build and maybe we can make minor improvements on it, but we know what we want to build. We know what data elements are in it. We know that this report is already delivering on the need. That’s perfect if there’s a sample available.
The next question is, describe the ideal report layout. This is assuming there’s not a manual report being created. Let’s say that there’s not, which is most often the case. What is the ideal report layout? Now this is going to depend on first, whether it’s a programmatically consumed report, or if it’s something that humans are interacting with. If we’re talking about a programmatically consumed report, that usually means we have some type of data feed going on from point A to point B and the destination is going to have to consume that report. It may be a flat file, like a CSV, a TXT, or a pipe-delimited file. It could be a fixed-width file. There are all sorts of ways. You could do XML or JSON, but some type of programmatic consumption of this file would define the layout of the file itself.
Now, most often we’re talking about humans that are consuming these reports and when a human is consuming the report, we have a different set of challenges. This can be an area that’s difficult for people to envision. Sometimes and other times it’s very easy. Often, we’ll ask the client to sketch something that describes the type of visuals they’re looking for. Sometimes they’ll draw a chart with X axis being whatever, X axis has time. Y axis has a measure on it and they’re drawing a stack column chart or something like that. Some people already have that in their mind, a vision of what is needed. That’s great, because that gives the development team something to go after. It’s not like it’s one visual most often. Usually, we’re looking at different views of this information to understand something about it. Not always, but most of the time it’s a combination of visuals that are needed. At the end of the day, we want to understand the report layout.
Now, in addition to report layout from a static standpoint, you also have interactivity. We most commonly work in Power BI. If you’re working in tools like that, you’ve got a lot of options. Each data visual can interact with one another. This can be a little bit overwhelming for someone to try to describe the ideal layout when you’re doing this requirement gathering process, but you can simplify it. If the client as an ideal layout that you’re looking for, but you’ve got five business units. We would ask them if they would like to be able to see that same information for each business unit individually and as a whole. That’s a simple question to answer and the person developing the layout or doing the report authoring would be able to use that information to try to come up with some initial layout that might fill the need.
It really sparks a lot of thought and discussion when you get to the actual report layout. When someone sees it, they either love it or they don’t. It’s usually not perfect on the first try, especially if we’re starting from scratch. It’s really an interesting process. When you have a business owner or manager of some kind looking at this report and they’re saying, “Yep, I like this, but no, this is useless, and it would be really cool if we could do this,” that’s when you know you’ve got the process going the way you want it going. Because people are thinking about things that are going to be useful to this business process improvement that we’re trying to undertake.
The next question is once this report’s created, who is going to be able to help validate it? How are we going to validate this report? You don’t want to have reports that people cannot trust. We’ve talked about this in the past. It’s important that you build trust, so having validated reports is critical. Right at the interview process, we need to ask, “What do you consider to be successful? What is valid in your mind?” The answer to this might be something like, “Look, if I can go into my business application and I can pull these five data elements and it matches what the report has on it, I consider that to be correct.” Or it might be, “I can go into my business system, and I can export a data dump here and show you what it looks like today and if that matches up to what’s in your report, well, that’s valid.” Defining what is valid and how we’re going to validate is important.
Data validation goes into a whole additional subject area. I’m not going to dive into this deeply here, but I want to reiterate that it’s important for several reasons. First, we define what is valid. We don’t want to develop this report, build all the things that need to happen to get this report in front of the right people, and then find out this doesn’t line up with the expectations. If we ask this question, then the development team can be validating as they go. They know what they’re trying to match. If they’re able to match to this known, good, valid source, they know they’re correct. If they don’t know this information, then we’re developing in a vacuum. We’re building something, but we have no real way of knowing if this is accurate or not. We can come up with our own ways of knowing if it’s accurate or not, but from the business user standpoint is the perspective that matters. Not us, the development team, it’s the business user’s perspective that matters. It’s important that we ask the business user, “What do you think is valid?”
The business user is not always right. Sometimes the development team will find things that can challenge that business perspective and that’s fine. We’ll bring those things to the business users. We may find that they should consider something else, because that information they are looking at is not matching up to what they described as needed. That back and forth can happen. At the end of the day, we want to know what we consider to be valid because that’s going to drive the development process. It’s going to make us much more successful in the long run.
Next question is, how often should the report be refreshed? When someone comes in, in the day and they’re beginning their workday, they want to have a report that reflects all data through the prior business day. That’s the most common answer to that question. In other words, we want daily refreshes for this report to be effective. That’s not the only answer, but it’s important we know the answer to this question. If the business user has no insight into how these backend processes work. The business user might assume it’s always going to be refreshed every time they open the report. Which that often happens. People just jump to that conclusion that when they’re looking at a report, they may assume that it’s tied directly to the same business system that they’re using to enter their raw data into and think that the report is always refreshed. Meaning it’s a real time report. Which it can be, but it’s not necessarily going to be the case. It’s important that we know how often the report should be refreshed.
Now this is something that goes toward cost. A report that’s refreshed more often or in real time, is going to be more expensive to produce than one that is batch refreshed once a day. You don’t want to refresh all the time, just because. You need to think about what is valuable? Is it valuable to refresh this report every time you run it? If you’re talking about age A/R, probably not so much because usually aging is done daily. Why would you want to know today again, that same data? It’s still going to be the same age. It’s important that you select an interval that’s appropriate, and you don’t want to ask for something that’s not necessary.
Next question is who should have access to the reports? This goes to two areas of answers. First, the actual question is who? Who should have access? There are particular people. It could be answered with everybody in the finance team should have access to this report. One answer could be anybody can have access to this report in my organization. Sometimes only one person should have access to this report. There are all kinds of answers to that. But that’s an easy question to answer. When you get into security, which is what we’re talking about here with who should have access, there’s also nuances. If you want various people to be able to access the same report, but when they access that report, they should only see subsets of the overall data that drives that report.
An example of this would be where you have a manager that’s managing one region, let’s call it the north region, and you have another manager in the south region. You want them both to have the same report, but you want the north region manager to only see the north region data and you want the south region manager to have the south region data. These security decisions are important to discover as well. Now the security decisions are important, not only because we want to make sure that people get the right information in front of them and the information that they’re entitled to, but also for things like performance. We must try to make these reports perform well. Understanding the security requirements that we have in delivering this report, which can impact performance, it’s important to know that upfront.
The last set of questions is about when is the report needed? When do we need this report? Most often the answer is pretty cut and dry and it’s yesterday. We need this report yesterday. We already know we have the need. If we can have the report yesterday, we’d already be capturing some of this value that we discovered earlier in our interview process. We need it as soon as possible. If that’s the answer then great, but we need to understand what it means to delay delivery of this report. In other words, how much missed opportunity do we have each day, each week, each month, each quarter, if you don’t have this report in your hands? That’s important because that’s going to derive how many resources are placed on the development of this report.
If we know we got this report and it is trying to capture $50,000 a month in opportunity, where we have another requirement that’s trying to capture $5,000 a month in opportunity, well, we should probably consider that when we’re prioritizing these efforts. It’s critical that we know what the expectation is for when the report needs to be delivered. Now, it doesn’t happen that often, but sometimes people will start a new process and that process is not going to be up and running until next quarter. They need to have these reports at the time that new process comes online. This is often the case when you’re setting new business applications up. That will help in the prioritization process developing multiple reports.
That’s the set of questions that I will typically ask when we’re interviewing someone for a new report to be developed. There are others. Oftentimes these individual questions will lead us down little tangents that are important to understand. So, this is not a comprehensive list by any means. You could probably just go search online for business intelligence requirements gathering and you’ll find all sorts of answers to this need of collecting information from the business users. This is a solid list, maybe not comprehensive, but it’s a solid list of questions that you will be asked whenever you’re beginning this journey of building your Reportopia.
We build this journey one step at a time. We’re talking about one business process that we’re trying to improve through reporting. We get that one done, great. We’re capturing that value. Let’s keep that process running as smooth as we possibly can. As we learn more about the process, we might find ways to improve even on that. We’re also working on any number of other business processes in parallel.
Okay, I’m going to leave it there this week. I hope you found this useful. Requirements gathering is an art in a way. It’s very important that we go through each of these questions each time we’re collecting requirements from a business user so we can try to hit the target as quickly and accurately as possible the first time.
