We are going to pick up from where we left off on the last couple of episodes, where we’ve been talking about defining value and figuring out how we can actually uncover value opportunities. You remember, we broke this down into expense reduction, revenue increase and risk reduction as being the most common types of value. In this episode, we’re assuming that we found some opportunities to capture value. We’re going to talk about what we’re going to do next. What now? What do we do now that we know there’s opportunity out there and we’ve done some due diligence to figure out if our data sources can support the process or the information that’s needed to improve a process? There’re really four steps here that we’re going to go through.
First, we’re going to go through the requirements collection process. Then we’re going to move into a dev cycle, we’re going to go into delivery. And then finally, we’re going to do some monitoring and collect feedback on the implementation. Let’s start out by talking about the requirements’ collection process. This can be a very complicated or a very simple step. Frankly, if you have a very simple opportunity, that’s very easy to define. Maybe it’s a very simple business process you’re trying to implement or impact, or maybe it’s not even a business process. Maybe this is just a monitoring report that you’re trying to pull together. Those types of scenarios, not that all monitoring reports are simple, but the simple types of scenarios can also have a correlated simple requirements’ collection process. And of course, on the other side of the coin, if it’s a very complicated process, well, there’s a pretty good chance that we’re going to need to spend a little more time defining the requirement.
It’s not as if you need to do all these things that I’m going to mention, but you need to consider these things. The more complicated the requirements are, the more requirements collection you’re going to need to do. The first thing I’d say that is important is to understand what it is we’re trying to achieve. What I like to do here is just have a short paragraph describing our goal, just in text form. If we’re talking about again, a monitoring report, it might simply say that we want to enable the X person, say the CEO to have insight on a fairly regular basis into some business function. It could be that simple. We might identify the measurements that we want to take at a high level at this point. But the idea here is that we need to have some summary level information that tells us, what are we trying to achieve? This is important because when you get into the weeds of the next steps of developing and delivering the solution, it’s easy to lose sight of what you’re trying to achieve. It’s kind of the… “You can’t see the forest through the trees” type of scenario. So having this little basic description of the goal can be very helpful.
The next thing that I would recommend doing is having a flow chart. Today I was working with a client, one I’ve worked with for years. We’re talking about just one particular measure and how we want to define that measure. It’s a critical measure that the business needs to really gauge how well they’re performing or how well their resources are performing. While the flow chart that I created is not extremely complex, no more than a dozen nodes with maybe three or four decision points. But they’re so important that it’s just critical that you’re able to communicate the rules in a black and white manner. A flow chart really does a good job of that. It’s one thing to talk to a business, a subject matter expert or a process owner about what they want to have done. But when you go and you ask a developer to build something, the developer has no leeway. Everything is black or white. You’re either doing A, or you’re doing B. So having a flow chart really forces you to identify the different pieces of logic that need to go into this solution. Now, I usually just use draw.io. I used to use Visio for this. You can use Excel, or you can just use an iPad and just sketch out a flow chart. This doesn’t have to be some highly sophisticated thing, but it does need to capture all of the business logic.
The next thing that I would do is get some type of a definition in place for the critical measurements that we’re going to be taking. If we’re talking about a close rate, or talking about a conversion rate, or if we’re just getting an aggregate sum of some unit, it’s important that we define these measurements in terms of the business perspective at this point. How does the business define this measure? Is what what we want to know. The flow chart and the measurement definition kind of go hand in hand. You can think of the flowchart as a developer’s guide to how this measurement is going to be created. And then the measurement definition is the business’ perspective on the actual measure definition in English terms. For example, I was working on a close rate today, the close rate for this particular healthcare client is defined for those that are new patients. For a new patient, how successful are they at closing them? Whatever the procedure or the transaction is. How successful are they at closing this new patient? The same thing applies to eCommerce and all sorts of industries. But the measurement definition is really important. It’s different from conversion rate, it’s different from all other sorts of measurements so having a text definition is important as well.
Some of the other things are logistical, but they’re also important such as, what’s the delivery method? Are we going to try to send this report out in email form as an attachment? Are we expecting the business to self-serve? And are we going to publish a data set and allow them to use that data set, to do some type of discovery on their own? If so, is this going to be done in a business intelligence tool of some kind? Are we trying to allow them to connect Excel to a data source? Is this going to be an automated data feed or a data exchange? There are all sorts of ways of delivering this solution or delivering the report. And it’s important that we have an idea of what the delivery method is going to be upfront, because that can really impact what happens in the next step, the development phase. And then finally, we need to mock something up. Not all scenarios require all of these steps. But especially in cases where there’s complexity or you feel like there’s any type of ambiguity here, it’s important to mock up what the end-user is trying to achieve.
If you think about a typical report with data visuals on it, there’s so many different ways to build that report. Having a simple mockup, even if it’s just a doughnut chart and a clustered column chart and a table, having something on a piece of paper or a sketch of some kind that the process owner can actually give you or the business user (that’s actually going to utilize this report) the ability to relay that information to you. It can really uncover all kinds of things that are going to prevent a lot of re-work down the road. That mockup can be considered a spec. Now, when we talk about a spec, often they’re much more detailed than just a mockup, and you may need to have a spec in some scenarios. When you get to larger organizations where there is a more rigid process in place, you have got a lot more people involved. Sometimes the spec is really needed.
You have to get these processes in place to very clearly define these specifications. You reduce the amount of rework that will be needed down the road. That’s really what I would consider a complete requirements collection process.
To recap here: We are going to flow chart the business process. We might even flow chart the actual measurement definition so we can identify the decision points that are going to be critical when we move into a development cycle. We are going to define the measures in English terms. We are going to have some type of summary to begin with, with what we are trying to achieve. We are going to have some type of delivery method defined. It may not be just one delivery method. It could be multiple. You might even have a mock up of the end result that we are trying to create. All of these things together create a pretty good picture for a developer or a development team to go out and build this report in the next phase, the development phase.
The first thing I would say about the development phase is we want to break this down into very small deliverables. It’s hard to take a large project and push that whole thing through a development cycle and expect that the end result to be right on target. It typically isn’t. Things change because large development cycles take large amounts of time. It’s just always better to try to take small pieces of that deliverable and break them down into things you can develop in isolation.
While still considering the prioritization, there are all sorts of things to consider here when we are talking about development and we’re not going to get into the details of how the development process works. But there are some things that are important to understand from a developer’s perspective. The first person that should get these requirements would be someone that is going to actually understand the entire architecture and this person is likely to be the data modeler. This person understands what type of data model is needed to fulfill the requirements.
This person is thinking, “I’ve already got some of these things in the model, they are already supported, but there are these other things that we don’t currently support or maybe there’s some that we actually kind of support, but they’re not exactly right yet. So, I need to make some adjustments.” At the same time, that person needs to think about keeping a solid foundation in place. They don’t want to have a fragmented model where you have point solutions to deal with for just this one requirement. Instead, we want a cohesive model that will support this requirement. Hopefully, the next requirement is going to be easier and faster and cheaper to deliver, because we’ve got this foundation that is very integrated in place. It is going to be important that that development team understands the priorities. The priorities relate to this requirement, and that can take different directions with the priorities. You can say, “Look, the highest value piece of this opportunity is this one thing. So, let’s go after that first.” Or you might consider what is the easiest and the quickest. Or maybe it’s some combination of those things, but you really don’t want to just leave it up to the developer that’s writing the code to figure out what those priorities are. The developer can provide some very valuable input for the business owners who should be making that decision. But you need to define those priorities so that the development process actually goes along the expected path.
Now, the development cycle is really going to have a couple of different phases in it, depending on what type of solution you have in place. If you have a data warehouse in place and then you will almost always start with the system of record research. Someone is going to go out and do a little deeper dive into the system of record, where is the data coming from and make sure the exact data elements that are needed have been identified.
Then they are going to move that information into the data warehouse. That’s an ETL process sometimes called an ELT, which stands for extract load and transform. Once the data is into the data warehouse, they are going to need to go through one or two more layers. These are the semantic layers and the cube layers before you get into your reporting layer. There are a lot of steps in there, for sure. We’ll talk about some of those in future episodes, but the point is that it is important for the development team to really understand what they are trying to achieve. Not only from a technical perspective, because even as good as we were at defining those requirements in the last step, there will always be things that come up that are going to be up to the developer to decide. You just can’t stop at every question that you have and set up another meeting to make sure everybody understands the details of the particular complexity that we need to figure out and then move on. It’s just too slow of a process. So, the developer must have some amount of leeway, but you also don’t want them just cowboy coding and figuring out everything as they go. Then pretty much inevitably at the end of that type of a process, you have something that you didn’t expect.
Giving the development team as much information they can, or as you can upfront is going to help the process move along as smoothly as possible. Now, we’re trying to break these deliverables up into small pieces so that the development team can actually deliver things continuously. We’re talking right now about one particular value opportunity, but if whenever you’re working in these reporting solutions or business intelligence solutions, you’ve often got two, three or a dozen different value opportunities that you’ve identified. Really what’s going to happen is, it’s not just the one value opportunity that you’re working on at one time. We are often working on several value opportunities. Even further, I guess it emphasizes the importance of looking for efficiencies in your development process because several of those opportunities might have requirements that overlap. So again, trying to get the biggest bang for your buck, you want to try to find those things that are going to deliver the most value the quickest. So, let’s just say that’s the development process, I know that’s very abbreviated, but we’ll dive into the details of the development process more in future episodes.
Now let’s talk about delivery. If we are developing this thing in an agile manner where we are continuously delivering things into production, that often is going to mean that you don’t have everything ready to go at the same time.
If our delivery method is a report within a business intelligence tool, then when we create the first feature in development, that might just support one axis of one visual, and then the next piece will be the next axis of a visual. And then maybe we’ll go ahead and build a couple of measures. Now we have maybe a couple of the visuals and maybe we already had some of this information ready to go in the data model. So, we can set up a couple of filters as well. Just like the development cycle is delivering things in small pieces, we will have a delivery method that is going to be delivered in small pieces. Obviously because the development cycle is only delivering small pieces at a time, you have to be careful here because you need to set expectations. You don’t want to take a subject matter expert or a business process owner, that isn’t going to be intimately involved with this process, and put in front of that person something that they will think is incomplete. “Why are you showing me this thing?” is often what they might be thinking if it is not what we talked about building. So, it’s really important that you set those expectations and tell them that we are going to build this thing one piece at a time and we’re going to deliver those things all the way to the report end. You’ll be in production, and you’ll be able to look at this report. We can put together reports as we have these different development cycles complete. They should have the correct frame of mind and understand why you’re doing it that way. One of the main reasons is so that they can actually see what you are building as you are building it. If they see you’re going in the wrong direction, well, they can get you in the right direction before you do these other 10 steps that are ultimately going to be the wrong direction. It’s important that you have those people involved in this process, but that person doesn’t have to be the end user. If we’re talking about the CEO here, maybe the CEO doesn’t want to be involved on an every couple of day basis to look at what’s actually going on in this report development. Maybe he just wants to see the final report. Well, that’s fine, but someone needs to be involved. Somebody needs to have their eyes on what’s going on. So, we can adjust course as needed as quickly as possible when we find we’re not on target.
So when you do deliver this report or whatever it might be, it could be a data model that someone’s using in a BI tool, or even a data model they’re accessing in Excel. You need to actually formally deliver it. And this is the piece where we’re saying, “Okay, this thing is ready to go.” You might have been working with one person as the development cycle is progressing, but now it’s ready to be put into use. At that point, you need to sit down again, probably with the same group of people that you sat down with whenever you first collected the requirements, and you need to deliver it officially. You need to show them, “Okay, look, here’s what we said we were going to build. Here’s the amount of time it took us to build it. Here’s the individual pieces that we broke it down into. And here is the end result. Here is the report that we believe will to help you capture this value.”
And again, this depends on your audience, but it really is important that you do this because sometimes you’ll uncover that you have the wrong assumptions about people’s capabilities. If you’re delivering something in a BI tool and you think that they’re going to be able to use that tool just by kind of clicking around and figuring out as they go, they may or may not be able to do it. They may or may not have experience in that tool. So, you can capture those types of very easily solved problems with just a couple of hours of training or even less, showing people, how you actually access this information.
When is this data going to be refreshed? How do you share this with others? These are some very basic questions that will help the users of this report get a lot more out of it. And of course, you need to go over the meaning, even though we have the requirements that we’re using to build this report, we need to go over again, exactly what was built. Because sometimes there are minor differences and those minor differences can make a big difference in the ability of this report to actually do what it was supposed to do, impact the business process, capture value, etc. So go over the meaning of the report, take a little bit of time, look at each page of the report. Look at each visual on the report, talk about which axis you’re dealing with. For example, one thing easy to overlook is time. Often we are looking at a time series, but there’s different ways of looking at time. If we’re talking about accounting, for example, you can have time on accounting process date, meaning when a transaction was processed or you can look at time based on when a service was rendered, a service date. If you have a time axis on a visualization and one person’s assuming it’s date of service and the other one thinks it’s the process date, well, you’ve got a major misunderstanding. The developer might think it is just common sense, or they might think it’s intuitive, but it is not. So, it’s important to talk about the meaning of each of these reports. The other thing I want to say about this is that I’ve recently been putting a glossary right in the report.
There are all kinds of ways to do documentation. You can buy expensive tools to do documentation. You can hire teams to do documentation and maintain it. But what I think is the most effective way to document something is, if you have the definitions of things right next to the report that you’re delivering. We use Power BI a lot here, pro BI. And I’ll just simply take a page, the final page in a report and I’ll write down in that page, at least a basic understanding of the measures. And I’ll write down, if there are any exceptions that are in place, maybe we’re filtering things out, whatever it might be, just some basic information.
This not only helps the business understand the report, it helps me understand the report in six months. That’s the reality. In a few months, we are all going to forget the details that we’ve been talking about and having that glossary will prevent you from having to go back to the development team and reverse engineer what was done to try to figure out what the rules are that are actually built into this report. That’s something I’ve found really helpful.
The last phase of this process is what I call the monitoring and feedback phase. And this is where you’re… Well, you’re going to monitor and collect feedback. You’re going to let the process begin. Right? Remember, we’re delivering a report. In our example, here, we’ve identified some type of value opportunity. Early on we talked about what we thought it would cost us to do this thing. We did some initial research to figure out if it was possible. Well, now let’s just see if our assumptions and our kind of rough estimates were accurate. After let’s say a month goes by, let’s sit down again and say, “Okay, how is this working?”
We know what it costs to get us to this point, because we developed this thing now. How much of the opportunity have we been able to capture? It’s really, really important. This is what sets apart, the Reportopias that are built as a cost center perspective, from those that are considered to be a business function. You’ve really got to go out and you’ve got to take a little bit of time and you’ve got to say, “Look, here’s what we built. Here’s the opportunity we’re trying to capture. Here’s what it cost us. And here’s some basic ROI that we think we got from this one effort.” And then you can advocate. You can share this result, and when you do that, it just becomes contagious. One business unit after another will look for these opportunities even harder. And it really just kind of feeds on itself and rightfully so, right? Because that’s what we’re trying to do.
We’re trying to be successful, whatever that might mean in your organization, we’re trying to be successful. And when you find a way to be successful, you’re going to leverage that and you want to share that information.
The other piece of it, is how long did it take? That’s another part of the equation. If we thought it would take us six months to build this thing and it took us two weeks, well, great. If it’s the opposite, well not great. We need to figure those things out, identify the bad assumptions and try to make better assumptions on the next round.
The other thing about monitoring is sometimes the end users of these solutions will find other opportunities as they’re capturing an opportunity. It’s like whenever you have a solution like this, a business intelligence solution, whenever you ask a question of your data and you get that answer, it’s going to often mean you have more questions as a result of that. For example, if the CEO is trying to understand what’s going on in a business function and the CEO begins to receive some daily measurements and trends. As soon as the CEO sees that that trend is taking a turn either for the better or worse, I can guarantee you that this person is going to want to know why. Why are we seeing an improvement? Why are we seeing this? This thing costs more, whatever it might be. And when you have that, now you’ve got a whole other thing that you can kind of dive into. What’s driving that particular measurement? How can we break that down? Who owns those different pieces that we’re breaking down? That is really how this process comes live whenever you get something that works and someone starts using it. They really start understanding what’s going on in a business process or a business as a whole, from a data perspective, it just feeds this whole new way of thinking about things.
It takes you away from the… guessing game. We’re making informed decisions in our cases, but it takes you away from a lot more of the ambiguity or the guesswork if you want to put it that way. Then it would be, if you’re using a data driven approach, like we’re talking about here in building a rewarding solution. The feedback piece of this is also really important. Whenever you get those final numbers and you’re ultimately asking someone to decide and to take action. They’re getting these insights and they need to then take this information, take this insight, use it to make some type of decision. Well, the decision itself is not going to make any difference until an action is taken.
It’s the action that becomes part of the feedback. Whatever that action is. Now we know we’re taking this action. Now, what are the results? What’s the outcome of that action? It’s several steps away from the actual report. You’ve got raw data, which is just information. We’re going to turn that into knowledge. That knowledge is consumed by some individual to turn it into some type of information. And then they’re going to use that information to gain insight about some type of process. That information will then be used to decide and that decision will lead to some action. Then that action and the outcome of that action need to be measured to create new information. Now we’ve got an entire decision-making cycle.
So that’s basically all there is to it. In the end, we’re saying, great, we have this value opportunity. We think it has a positive ROI on it. Let’s get really clear about what we’re trying to achieve. Let’s get that into a development cycle, get it developed in a well-organized, prioritized manner. And then let’s continually deliver piece by piece of this product until we have a whole result ready to go and put it into action. Let’s monitor what is going on. Are we being successful? Are we not being successful? Are we capturing the opportunity we hoped to capture? And use that feedback, use that information to improve this whole cycle. If you do all these things, you will be on the road to Reportopia. No doubt about that.
You’ll find that you’re going to create some objectivity. You’re going to remove a lot of the subjectivity for your business processes. You’re going to transform into very objective processes that you can measure. You can incentivize and just overall you can make things run very efficiently with this sort of approach. Well, it is the holiday season here, so I’m going to keep it kind of short this week. I do wish you all the happiest of holidays. Thank you so much for tuning in and we’ll talk to you again. Next Tuesday.
