S1E12: Mind The Gap - Plugging The Most Common Holes In Data & Analytics Strategies
S1E12: Mind The Gap - Plugging The Most Common Holes In Data & Analytics Strategies
This week we are joined by two of Moser's top Data and Analytics experts who are going to talk about the mindset a company should have regarding data and analytics strategy.
Shaun McAdams is Moser's Vice President of Data & Analytics and Warren Sifre is the Director of Strategy within Moser's Data & Analytics group.
Shaun McAdamsVice President of Data & Analytics
Warren SifreDirector of Strategy
Speaker 1: Hello everyone and welcome to another episode of ASCII Anything, presenting by Moser Consulting. I'm your host, Angel Leon, Moser's HR Advisor. Today's episode continues the series of conversations between Shaun McAdams and Warren Sifre. Two of Moser's top data analytics experts. Shaun is Moser's vice president of data analytics and Warren is the director of Strategy with our data analytics group. In this week's episode, they're talking about the mindset company should operate under when implementing a data analytic strategy. They're building off of their previous conversations. So this is a special episode where they continue developing the data analytics world and how you could apply it to your business. Without further ado, here are Shaun McAdams and Warren Sifre.
Shaun McAdams: Thanks Angel. All right Warren, we're on podcast number three talking about data and analytics strategy. For those that just came in, just tuning in on this one. What did we cover in the first podcast?
Warren Sifre: Well, the first podcast, we talked about our definition of data analytics strategy and what it encompasses. What are the different pillars and what organizations usually get right and what are the pieces they just tend to miss or tend to overlook? And we kind of came up with this people process technology and data that ultimately drives your data analytics strategy towards your insights, action, business value, leading from your business strategy. Someone upstairs says, " We're going to do this. And everything we're doing needs to yield some results." And this is how we get there. This is kind of what we covered in the first podcast, is what are these pillars.
Shaun McAdams: Yeah. And then we looked at it and we said, " All right. What should we kind of dive deeper into? Which of the four pillars, people, process, data, and tech? Which one causes most issues or we seeing those gaps with?" And which one was that?
Warren Sifre: The one we picked was process and we didn't necessarily pick it because, hey, it's our favorite, it's because it's the one everyone tends to overlook and it's the biggest gaps. So we thought we'd start there. And that's kind of where we're going.
Shaun McAdams: Yep. So we did the second podcast and we were kind of taking a macro level look at process. And we were specifically talking about the delivery channels. How do we deliver data and analytics products? What were those delivery channels?
Warren Sifre: Well, the delivery channels are your insights, engineering, and platforms. And basically we kind of talked a little bit about what those are. Insights is traditionally your presentation layer development, your report teams, your self- service business units, that kind of piece. Then you've got your engineering, which kind of touches on the data engineering side, data acquisitions, trying to get your data shaped for the insights team to be able to leverage. And then we have the platforms team, which is basically, hey, we need a tool that does this but it doesn't exist. It's their job to kind of figure out which is the best play for the organization and the goals they're trying to achieve to apply it, which then engineering can use to deliver the data for the insights team to do their piece.
Shaun McAdams: All right. And today, we're going to go a little bit deeper and we're going to talk about the mindset that we would like people to operate under, and then we're going to apply it to these delivery channels. And so, we do that obviously through process. So came to Moser in 2015. One of the first things I did was create how we were going to deliver our services. And so this really predated those delivery channels of insights, engineering, and platforms. Being new to consultant life, I just wanted a paradigm under which if I was going to connect with a client and in particular, we were going to work on building data architectures for analytic workloads, how would we go about doing that? What approach are we going to follow with that end result? And now we apply it to a number of things, but the approach is simply uncover, envision, design, build, and manage. Now, before we go into those things, in let's say 2016 to 2020, we followed that explicitly. We're making modifications that to this year and we'll go through some of that. But we also have implemented similar processes based on this foundation for clients. So what I want to do as we go through this is talk about each section, each step, what we want to accomplish in that, the reason for that step. We'll also talk about the new vocabulary, if you will. So that way, if somebody connects with Moser in 2021 or in the future, they may say, " Well, uncover, you don't talk to us about uncover because we have some language differences now." But then also we use at least to one client and their application of this. So regardless of what vocabulary is tied to that particular step, we just want to be explicit about the types of activities we would want to do.
Warren Sifre: We just want to make sure that everything is taken into account. Whether you call it uncover, whether you call it discover, whether you call it whatever terms, synonym you wish to use, or whatever you need to sell internally to your organization to get buy- in to this mindset. We just want to ensure that at a minimum, these things are taken into account and that there's recognition in the value that this brings. And if there's going to be in an omission or any kind of blending of this, it is a conscious decision. It is not something done through ignorance, or I didn't know, or this is the way we've always done it versus, hey, you've been educated. Now you're making the best decision for your organization, which may or may not follow this. There's high recommendations to follow this, but you all make your own call.
Shaun McAdams: And going back to the first podcast, we talked about technical and non- technical influences to all the things that kind of got us to how we help organizations now with defining and delivering the data and analytics strategy. And one of the non- technical influences was starts with why. Companies sometimes they know what they do, the product they produce. They may even know how they produce that, but they don't always understand why they're doing what they're doing. So this is influenced by that. And that's explicitly why we've broken down sort of our discovery services into three steps, uncover, envision, design. We want to answer the why, the how, the what questions. All right. So let's take a look at uncover. So when I originally created uncover, you could even go back and probably pull some old collateral. It talked about uncovering the DNA of an organization. We wanted to know the technical makeup of a organization, but also the business strategy of the organization. And we are being specific to the delivery of data and analytic products. So when I say technical makeup, I'm talking about, where's all the data? Where does it exist? What technologies does it exist in? And then how do they want to use it? We want to know what type of business value they want to get out of their data. We want to know how they look at it. Is it currently viewed as an asset? Is it not? All of those things, we're just trying to learn. So in your experience working with organizations, manufacturing organization on the West Coast. let's talk, obviously we won't talk about them, but let's use them as example because you applied this to them and they used a different term, but they still accomplish the same things.
Warren Sifre: Yeah. So the uncover phase with this organization, that the biggest thing was they needed to mature the data strategy overall. They've got a process, they've been able to accomplish certain goals. They were able to meet business units in the middle with regards to, " Hey, you need this, but we need this. We're trying to get this done." And they realized that over time, it started mounting up and it started becoming this really challenging environment to manage and orchestrate. So their goal was to revamp their data strategy, their data environment, how they serve data to the business, how data was received from the business and collected and ingested. So part of what we needed to understand is, what is your line of business and what is important to each of these business units that are going to be participating in this solution that we're coming up with? We're not just building some, " Hey, someone wants data. Let's build a data warehouse. There you go. You need a data mention? There you go." But why do we need it? What's driving it? The uncover phase, I like to use the analogy. It is our justification as to why we are making the decisions we're making, which means we need to understand as much about what is currently working for these business units. What are things they wish they had today or yesterday? And if they had unlimited budget, what does that three five- year plan look like for that particular business unit? What is the wishlist? Because it's going to be a combination of all those things that's ultimately going to drive what this uncover, this justification piece for everything else we're doing is going to drive.
Shaun McAdams: Yeah. I love the word justification there, because if we were to look at that organization, I think they called this initiate because they had this architectural review board that took place right after that step. So we would have called that uncover. We work with them and say, " Hey, here are the types of questions you want to answer to really understand the why the business value." So that when you go to that architectural review board, which is in place because they just don't want to have people doing things that ultimately aren't going to provide value for the business, that they can make good judgements on that. So we called it uncover, and we'll apply this later to the delivery channels. And we'll do a sample, like an example of how to do it. So I think that's an easy one for people to understand. Because most requirement type of processes try to get to that.
Warren Sifre: Yeah. They have something like this.
Shaun McAdams: So step two, envision, exact opposite. I think it's the one that most organizations don't do because they're not explicit about it. They either think they do it in step one, uncover, or maybe in design, but we've explicitly said, " No, let's stop. Let's call it something. Let's force people to do it." I love it. A lot of technologists hate it. I think this is the biggest one that they struggle with. Not only our clients and getting them to understand it or their resources, but even ourselves, even our own consultants. We're bringing in new people into Moser to deliver data and analytic products. And they don't think in this way, shape, or form. So what is envision? I know we're answering the how question, but in your words, what is it? And what's the importance of it?
Warren Sifre: Envision is what I like to call the brakes. Because to your point, people, once they get the requirements, they just want to start building. I know technology, I got this data, I'm just going to start building and they don't bother to stop and slow down. And this is why I kind of viewed this as something that's almost the brakes. Let's stop and think about everything that we've uncovered. Let's come up with two or three different solutions around the technology that either is currently available, the skillset of the individuals that we have, obviously the uncover requirements that we have. And then what is the potential drive or what is the direction your organization's going in that allows us to take into account future technology or technology that may not be fully embraced by the organization yet? And come up with solutions that give two or three options, that say, " Hey, you know what, here's the fastest, cheapest, not the best." It's a band- aid. And this one's the best, the most expensive, the most this and that. And then something in the middle. And what's going to happen is that with that presentation, organizational will kind of figure out what's the best blend of those two or three options and come up with the best solution based on where that organization is within their data analytic strategy journey, what's their appetite for the cost, the skillset they have. And they're going to make the best decision for them at that moment with a recognition that what we uncovered of where the business unit is or where the organization needs to head three to five years from now, those decisions are taken into... taking that into account as well. So it's not like, " Hey, this is what we need today. We're building it today. There's Excel. Have a good day." No, we're going to use Excel with the expectation that we migrated to something else over time as we acquire. And there's a path to that.
Shaun McAdams: Yeah. I think, and another thing I think that's important is most people that I talk to, I think the objection I usually get with this step of uncover is all we do it in design. We get all of the requirements and that's the first step of design. We're throwing stuff at the wall. We're trying to figure out what it is. And I appreciate that. I get it. But when you deliver data and analytic products, to me, there's also this then separation within design, that once you have all these ideas, you're communicating or should be with the end user to have some acceptance criteria before you then get into what I call the true design. So if I was building a house and I was talking to someone about their lifestyle and how we're going to design something around them, who they are, how many people live there, all these things within uncover. And then I went to envision, I'd be giving them some mock drawings, we'd be talking about, " Hey, how do you like this?" We ultimately get to some version of acceptance criteria. And then I got to make blueprints that's going to tell somebody how to build this thing. And I look at that as design and the importance of is taking how and separating it out is to get to acceptance criteria, to get to a definition of done. And that's going to be important on all of these delivery channels. And when we get to the sample particularly insights, I think then it will register. So for listeners who maybe don't quite appreciate what we're talking about here, I think when we get to the example, maybe it'll hit home then. So we know why with uncover, we have how with envision. Now we get into design, which is what. What do we have to do to implement the thing that everybody just agreed to works for delivering this product?
Warren Sifre: And that's something most organizations are pretty skilled at. They've been building, they've been working projects. They've been doing these things immediately, but like I said, it's putting the brakes on, getting that acceptance by everybody that allows the design to be stable. Because one of the things that tends to happen with the design phase, with organizations that they come up with a design. But because they didn't do a full discovery of the uncover and they didn't have full communication with the business stakeholders or the end users that are going to be consuming this as to how this is going to happen. We get to design and then you start having this iteration of, can we change the color? Can we change the label? Can we rebrand this? Can we add buckets, new bins? Can we calculate this too? Can we change? It started having a lot of iterations because we didn't take that. So by the time we get the design, it should be pretty quick for the most part. It's pretty straight forward. We understand what we're achieving. Now it's just technical challenges that we have to hurdle through in the design phase. And that's where ultimately we end up with our plan that builds says, " Okay, we're going to build this design," simple as that. Builds should be the most straightforward of them all because you should not be playing a lot of audibles there.
Shaun McAdams: I don't believe that design has to be so inflexible that if you go back to the example of building the house, we're not going to allow you to use a different color in the room, or when you get to build, there is this iterative feedback between what you're doing, particularly at the insights level for us and the person consuming it by doing testing and things like that. So I don't think you have to be so rigid within design, but what you do need to be able to do in design is that you have communicated, particularly this is where you see this crossover from business to technology. You have communicated to a technologist that's going to ultimately create this thing, everything that they need in order to do that. So those were the first three. And then you get into build. I think that's fairly self- explanatory. Now we took influence and said, " Hey, let's boil things down to the lowest common denominator." So the reason why here we just had build, it wasn't that we didn't recognize that a lot of activities have to happen within the development. That you would have to do testing, or you may have some system development life cycle, but we wanted to just identify, " Hey, there's a set of activities that have to take place for you to create the thing that you just designed." And then we added on manage, which I don't see in a lot of application development life cycles. I see them do a requirement gathering and design. I see them do development and presenting that. And then I see it going right back in it. And so a lot of times within those iterative processes, they've left out the fact that you've created something that you have to take care of. You also have to let people know about it. So for us, manage is where we're doing the finalization of the documentation, the collateral that has been created through the process for the sake of educating, the people have to take care of it and the people have to use it. So that's why manage exist. If I go back to the manufacturing company that you were working with, they had similar steps. Obviously in build, they call it something else. And they had multiple layers of testing because they are a manufacturing company. And correct me if I'm wrong, I believe that they had made the company's stance that we are going to build products using this paradigm. It didn't matter if it was the physical things that they were manufacturing, or if it was data products, they were going to apply the same process. And I respect that. So within their build, they did development. They did multiple layers of testing.
Warren Sifre: No. Exactly. depending on the line of business you're in, you may have sub tasks or sub activities in each of these. And in manufacturing, you're always dealing with quality control. You're always dealing with a variety of things, specification, making sure you're within those specs and all these different things that go into the construction of something. And in this particular example, this organization chose to employ some of that language into their data development pipelines. So when they actually construct a project and they go through the uncover, envision, design phase, when they start building, they start using these terms because it's very familiar. It is something they can track. They've got systems that can manage it. And they have just reports in the mindset that is already adapted to that. And they understand that. And this goes back to something we mentioned in the beginning, that what we're kind of talking about here is more of a mindset that was once said. How you choose to articulate that mindset, how you choose to label it, and how you choose to evangelize it is up to the organization how it makes sense for them to get the best results from this. But being aware, taking account, not omitting these pieces, or recognizing that you are and understanding the risks and the challenges you're going to introduce and potentially face downstream is going to be there.
Shaun McAdams: Yeah. So a couple, I think, lessons learned from this which caused us to make some adjustments to it for 2020 wasn't that these things don't work. I think the biggest pushback, if I could even say we got any pushback, would have been in step two, because most people were used to paradigms under which they gathered requirements. They figured out what they were going to build. They built it, and then they documented how to take care of it. I think that seems logical. That makes sense. The how part applying that start with why mentality and actually doing how was the one that we had the largest hurdle of getting people to understand. Because, you're right. Most people, when they connect with somebody who has a particular question that they need answers to, we immediately start thinking about all the data we need to satisfy that. We immediately go into that and we don't think about how to communicate that answer to them. So I know we'll go to that in the example, but of the lessons I think we learned from this, and the reason to make changes was, one, to break down build a little bit and recognize that there are influences that are taking place within the industry for development and deployment, or continuous development and continuous improvement.
Warren Sifre: Separation of duties. A lot of those concepts that have been adapted over the last 10 years, and we just want... and that's one of the things that comes up. Okay. Where does deploy happen? Does it happen in manage? Does it happen in build? And what are the steps and how do we account for all of those pieces? So I think that led us to the organic modification of this for our going forward plan of including that as a separate staff.
Shaun McAdams: Yeah. Because it's what's the lowest level of things you need to do and where are those dependencies? So living this out for five years, that was one of the things that we've seen organizations have challenge with. And so recognizing that dependency and then recognizing the dependency between the development of what you are going to do and the people that are actually doing it. So we separate that out, and then we just let marketing do what they do well. Because 2015, Shaun came up with these words, which meant something to Shaun and had no marketing influence in it whatsoever really. And so how can we really communicate this a little bit better? So we'll hit this real quick for 2021 moving forward, we've taken those five steps. We have split apart build. And then we created two phases to now separate these six steps into three and three. So the very first phase is called discovery and we call it discover, dream, and design, same thing. Uncover, envision, design, discover, dream, design. We're using D words. Maybe that's because we're in data. I don't know.
Warren Sifre: Maybe.
Shaun McAdams: But we're doing the exact same thing there. Another way we apply this is in because we're a IT consulting company, this is where also how we deliver our consultancy services. So if we're going to go in and we're going to work with an organization on strategy on creating architectures with the analytic workloads, IT maturity, all of these things, we're answering these why, how, what questions. And so that discovery ties into our consultancy services. Next phase we have is-
Warren Sifre: You guys should develop your deploy and drive, which is ultimately your build and manage, which is your professional service. That's hands on keyboard. That is where we're either building it for you. We're injected with your team to provide guidance, helping hand, increase velocity, or we're in there in the trenches with your team more as a coach to help make sure that the right decisions are being made. And then your team has the ability to bounce ideas off of, especially if the technology, the technique, or the architecture is new, we're able to do that. But having that separation, this is something a lot of firms have had. Their professional services, which is your hands on keyboard, your consultancy services. We're kind of applying that to this delivery method and this ideology that we have and making sure that we have that. And one of the things we strive for is most, if not all engagements that we engage in, we kind of require a little bit of that discovery services to happen. Even if it's just a couple hours of let's confirm what we got, let's make sure we're on the same page. But if not, we're going to spend some time to understand why you were asking us to deliver this.
Shaun McAdams: Well, that goes back to our sort of values as a company and doing the right thing for our customers.
Warren Sifre: Exactly. Exactly.
Shaun McAdams: So if you talk to us post this podcast or something, and you see the language has somewhat changed from uncover, envision, design, we just kind of want to throw that out there and we want to point to, " Hey, what did we learn over the last five years? Why are we making some adjustments?" It's not that those things didn't work. They've worked well for five years. It's that we identify areas of growth and now we sort of attack it this way, which better aligns with how we do all of our services, really within data and analytics. All right. Now, if we have this approach and we have these delivery channels, so we have insights engineering platforms, and we say, " Hey, we got to follow this approach. We're going to go back and just talk uncover, envision, design approach," that has to be applied in all of these delivery channels. So anyone doing work within insights need to follow it. Anyone that's doing work with engineering, anyone doing work in platforms, they all need to follow these things. And there are dependencies that exist at some point in these steps on those delivery channels. So let's walk through an example of what that would look like. And let's just start with, I'm a leader within an organization, I'm coming to you and said, " Warren, I need answers to these questions."
Warren Sifre: So basically you want to report, I want to report. To report them. So this would be the insights delivery channel path. And what would traditionally happen, someone would come and say, " Hey, we need a report. We need a dashboard. We need fill in the blank." But something that is around the idea of converting data to information so they can make decisions. So we go through the uncover phase, why do you need it? What are the answers you're looking for? Why are you requiring it to be a particular way?
Shaun McAdams: What are you going to do with it?
Warren Sifre: Exactly. What decisions you're making out of this. So once we understand that uncover piece, that then gives us the opportunity to go through envision. Basically what we started saying is, " Look, based on what you said, you're going to need these information categories. You're going to need information about a customer, information about a product, information about a process. You're probably going to want to see it this way. So when you start playing with some wire frames, maybe bring out some templates that we have or make some on the fly. Some tools are faster than others of been able to mock things up real quick, to get that idea of how we're going to deliver this information, this data and information to these individuals so they can do it.
Shaun McAdams: And that's the important part. When I said earlier, " Hey, we're going to apply an example," I think that's the one I want to pause on because that's the one that's overlooked and you're talking the very first interaction with the customer. We know we're going to have dependencies on tech and the platform. We know we've got to get data into the firm through engineering. But immediately within these conversations, you understand the business value through uncover that they want. Do not go to think about, well, what data do I need? And I've had situations where I've done this exact same thing. I've asked someone for something. And then when I'm presented back the results of it, I get like a Power BI report with 10 tabs, 10 different ways to look at it. Because there's, " I wasn't sure if you wanted to see it like this, or if you wanted to see it like that, or if you want to interact with like this or you want to ..." They didn't go through the envision stage. They didn't go through how do we need to communicate that answer to this audience?
Warren Sifre: These things work, this iteration that allows us to establish the major aspects of the acceptance criteria so that we can say this is done. Because what will then happen is once we have the wire frames, once we understand the data categories that we're going to need, now we can go in, where exactly am I going to get this customer information is coming from an SAP system or CRM system? Now, we're going to get this, this comes from this system or this data warehouse, or this data mar or this table. Now in the design phase is where we start locating basically where this data lives. Before that in the envision phase, we're not talking about where it lives. We're talking about what you need, because if we determine in the design phase that you need this type of data to do this report, and it's discovered that it doesn't exist yet, that leads us to the branching of our delivery channels. And that kicks in the engineering delivery channel.
Shaun McAdams: Yeah. We've also seen in witness clients who have skipped envision and they've went on year long projects based upon some directive of leadership. There was no communication of how this thing was going to be delivered to them. So they went on year- long projects in order to swing back around to the customer. And the customer then looks at the product that was created for them as is-
Warren Sifre: Not satisfied. They're questioning-
Shaun McAdams: I had some choice of words in my head I was going to say at that point I paused. Because that's a level of frustration that they have. You and I both talk about visualizations and why they exist. Yeah. People consume data. They then take some type of action on those. But there is an emotion you should get out of looking at any type of visualization. You're either going to be super ecstatic because things are going well and you're happy at what you're seeing, or you're going to be pissed off. And if you don't get one of those two emotions-
Warren Sifre: You're looking at the wrong data.
Shaun McAdams: It's not important.
Warren Sifre: It's not the right stuff for you.
Shaun McAdams: That's right.
Warren Sifre: This is the piece. If you can have the same data presented differently to different levels of the organization and all of them have that emotional response, and then you can take the reports that each of them have that makes them move and switch them around amongst business years, not like this doesn't mean anything to me. And it's amazing. It's the same data. But because of that presentation, because of that envision and the design that we have, it allows it to go through.
Shaun McAdams: You want to increase data literacy in your organization. You want to have the ability to be influenced by human centered design, which is a big word in application development. You have to do this envision phase. That's the only place to integrate those things. And the reason why I say you have to do this for data literacy is because that's the place where you can have some templates to the types and ways you're going to communicate similar needs to the organization. Hey, green, yellow, red, they mean something. So having that influence within how you communicate is going to be super important in envision. You said that you go to design, all you're really doing is saying what activities needs to be completed by an engineer in order to produce this design, and at the insights level also, what data do you need to satisfy? Not where it comes from, not what systems it comes from, not how to do your business roles or anything like that. If you, as a BI developer, could just picture in your mind the object that you need. If I was to give it to you and it would satisfy every piece of the report or whatever you're going to design, what does that look like? I referenced that as a data end point, but that needs to be included in design. Now, most likely that doesn't exist for you to do the build. This is that first dependency. First dependency would be between design and build from insights, knowing that you have a dependency for data in order to produce that. So, that would get passed down into this insights delivery channel. Insights or engineering, you're right. Engineering delivery channel. And engineering would say, " Well, why do you need this?" And the example you said, you're creating a report for me. So maybe you're doing that, like through Power BI, it's usually going to get serviced out through some type of SQL mechanism as the interface, the delivery mechanism to Power BI.
Warren Sifre: Could be.
Shaun McAdams: So how do we follow our engineering stages? Which we're going to get to later in a future deep dive with data, particularly. How do I follow those? That's what I would be doing in envision. And then in design, it would be, what do I have to do to create that thing needed for this organization?
Warren Sifre: That object, that view, that table, that whatever it needs to happen to get that data point that the insights channel stated for this particular ask it was missing or is needed, engineering would then look at how and where do I get it? Why do you need it? What is the mechanism that I can use? What exactly do we need to deliver? And then can we do that? And then let's go down the path of, " Oh my gosh, we're now pulling data." Or we need to get something from an environment that we've never connected before or we've never interfaced before. And we don't have the tools available or the frameworks or the mechanism that's been certified by business, by compliance, by InfoSec, by all these different members in the organization that says this is a viable means of getting this information.
Shaun McAdams: Another dependency between design and engineering and their ability to build it, which could also exist at the insights level if the determination on how to communicate something exceeds the functionality crosstalk.
Warren Sifre: Let's say you don't have a dashboard tool. Let's say you're dealing with patching data reports and I want an interactive dashboard, we don't have that. Well, guess what?
Shaun McAdams: Platforms.
Warren Sifre: That would go straight to platforms.
Shaun McAdams: And platforms is going to go through the same thing. Why do you need this functionality? And then how do we introduce that functionality into this environment? Because there's a plethora of tools available.
Warren Sifre: Exactly. How do we envision this working? Are you a Microsoft shop? Are you an open source shop? What are the tools available? What's the appetite? What's the skill set? What's the people that you have that will allow you to make this decision and come up with these options in this envision phase? Which then ultimately leads once that's discussed and determined, you start working on a design that says, " Okay, we're going to use open source. How are you going to do this? We're going to do that." All right. Let's do a design of how we envision this is going to be, and then they can start building it doing the acquisitions, doing any ADA integrations, and any of the security stuff. And then eventually that bubbles back up to engineering. That says, " Hey guys, your tool's ready for you to work with. Here's how you interact with it. Here's everything else, which is the manage phase. Here's the education, here's the keys to be able to drive this yourself. Do your thing." And then they can start building and continue that to get it to continues to bubble up.
Shaun McAdams: Yeah. And here's the power all of this is that this could be one person who's multi- discipline and can do all this work. This could be Warren. Warren can do work in platforms, engineering, insights. But if Warren's mindset still follows this, then I think there's a higher level of maturity, high level of quality that you're ultimately going to produce in that final product. But there's also flexibility within this approach and these delivery channels. To scale to really any organization at any size, it doesn't matter how big the platform team has to be, or how many engineering teams that you have to have, or how many insights teams. We talked about that in the last podcast. So that's the power in this approach, is it tells you here's how to deliver these products, take this foundation, build upon it.
Warren Sifre: And what this also introduces is a level of transparency. If you have a means, a system to track these different phases of work in the different channels, you can very quickly look, okay, they're in envision on this, they're in design on this, they're waiting for engineering to do something with this. There isn't this thing where everyone has to come up with a status email, here's where everything's at. If you've got an electronic system to track the stages and you mimic some of these delivery channel and some of these mindset paradigms in those delivery channel workload environment, you can very quickly see where things are at. So it just does lend itself to agile and all these different scrum and lean and safe and how to track things, because at the end of the day, this is agnostic.
Shaun McAdams: Yeah. It doesn't matter the type of methodology you use for delivering, we're starting, here's the foundation of how you deliver products. Here's the mindset you need to follow. And then let's apply one of those that work right for this organization. That's a good segue into the next area. And so if you're watching on the video, you're going to see a very messy slide behind us. If you're listening in, we have a management service called Honeycomb. This is really where we do end to end analytics for organizations. Organizations that maybe aren't ready today to get value out of their data, or they don't have the ability or want or desire to invest in the tech, the people, all of these things that you need to do. So we've mapped uncover, envision, design, build, manage to platforms, to engineering, to insights. We use Atlassian tools. If you go into our tool and you look at our workflows, they literally are called those things. It's not like things to do, things I'm doing and done. We're explicit. And the states of ours, our uncover, envisions, design, building, management. And the dependencies that we just talked about really from design and to build are on this low diagram. We're not going to go through this on this podcast. They may fall asleep. If they haven't been excited about the delivery of data and analytics products to this point, they would definitely fall asleep if we start going through every bullet within this. But I put it out there so that people can look at it. And if you're listening and you want to see it, just reach out because more than anything, we want to see maturity within the delivery of data and analytics products. That's why we're doing this. That's why we're talking about these things. And we respect that if that's not what you do every day, that the things that we're talking about may make sense, may not make sense. There may be some clarity that's still needed that we're not going to have or be able to deliver on a podcast because we can't talk directly to the listeners. So again, reach out with those questions to us. Hey, this podcast is called ASCII Anything. Fire those questions in, not that we'll only use a podcast in order to answer them, because we want to be a trusted advisor in this space. So, we're looking for feedback and stuff from organizations.
Warren Sifre: Here, our perspective is this, if we can help all organizations increase their data maturity, their data analytics strategy, the more sophisticated data problems, data solutions are now possible. You can't get there without having a good baseline. And we're trying to get as many organizations on this baseline as possible so that you can clean up shop, you can improve your data maturity posture so that you can move on to these more advanced techniques, advanced analytics, AI, ML, deep learning. We all have aspirations of using them and trust me, we all have aspirations of wanting to build them, but we need to make sure everyone's at a point where you can do that and you can do it in a responsible way, in a way that's scalable. And these techniques, these things believe do that.
Shaun McAdams: Yeah. So if there's any organization that is listening to this, and I go back to how we do our consultancy services, by following that process of why, of how, of what, we can help implement these types of things for your organizations, we've done it dozens of times. And we're not explicit to, you've got to call it uncover, or you have to call it the dream, or you have to... We're just explicit to, let's do it in this order because you're going to get the best product at the end. All right. So setting up for podcast number four. Would it be podcast number four the next time? crosstalk.
Warren Sifre: We're tossing out around the different topics. Whether we stay on this or do we move on something else just to throw a little curve ball to our audience. So we're probably not going to announce what that's going to be immediately in this podcast until we decide. Shaun and I are kind of flipping coins here and I just refuse to lose. So we're still flipping.
Shaun McAdams: You got a two headed coin. Is that what you need?
Warren Sifre: Well, you keep winning so I keep trying.
Shaun McAdams: You got a two headed coin. That's what you do. And then you win every time. When we do swing back though to data and analytics strategy, we talked about process. We're going to talk about people. We're going to talk about people operated in those, and there's many ways and many goals to view that particular subject. So when you tune back in the next time, maybe we're talking about people, maybe we're talking about something else. But I appreciate you guys listening in, again, reach out if you need anything. Hey Warren, thanks for hanging out.
Warren Sifre: It's been fun.
Speaker 1: Thank you for listening into this week's edition of ASCII Anything, presented by Moser Consulting. We hope you enjoy Shaun and Warren's conversation on data analytics. We'd love if you would join us next week when we continue to dive deeper with our resident experts in what they're currently working on. In the meantime, please remember to give us a rating and subscribe to our feed wherever you get your podcasts. Until then, so long, everybody.