Digital transformation is one of the most popular topics in the industry right now, but when a company is considering or embarking on their digital transformation journey, where should they start? In this episode, Hexagon’s Xalt Solutions will discuss the most important gathering requirements to ensure a successful digital transformation for your organization.
JC: Hello, and thank you for tuning in to this episode of Solving Problems with Technology on HxGN Radio. I’m your host, Josh Cranfill and today we’re going to talk about one of the most important pieces of a digital transformation, which is ‘gathering requirements’. In this episode, I’m speaking with JD Martin, VP and partner at Corbins Electric, Nate Unruh, who is a business solutions manager at NOX Innovations and Geoff Wakefield, our continuous improvement expert here at Hexagon Xalt Solutions. So, welcome to the show. Thanks for joining us, guys. Looking forward to today’s topics. I think we’re in a very surgical and let’s say useful topic in digital transformation.
And I believe this is something that people do wrong a lot is, okay, we want to deliver a new workflow, a digital, you know, a small, discrete digital transformation, but how do we figure out what to do? How do we figure out? How do we prioritize? How do we gather requirements from the right people? And so forth. Oftentimes, and I’ve been through many, many, many projects where somebody gets an idea. You realize that a business process is broken; you want to go fix it. How do you get there? We at Xalt, we like to do a lot of process mapping and figuring out current state and ideal future states so that we know what problems we’re solving and how to attack those through integrations and automations and notifications and workflow and so forth. But we’ve also seen over the years, certainly customers or rivals or whomever else, skip past this step of gathering requirements and just sort of go for it. Start building the plane on the runway, as it were. We figured out that’s not the way.
So I’d like to kind of just start with you guys, because I think you’re the quintessential example of how to do this well. So just to start it out, the topic is gathering requirements. So what’s your process? Who collects the data? Who’s involved in the step and some pitfalls to avoid? So that’s the basic topic. And so we’ll just start with this piece. How do you identify a process that has waste and could be better? What’s your process there to get people together and so forth?
JDM: Yeah. I want to reinforce what you said, Josh, is that of all the people that we’ve helped, some of our peers in the industry, some people that I’ve met through Xalt, this is the one—knowing that you need to digitalize, building on from our last topic that we did, building on digitalization and/or digital transformation, people realize they’re like, oh, we need to be in the 21st century. We need to have digital workflows. And that’s kind of a no brainer. Regardless of the platform, they’re like, yeah, we need this thing. Where we’ve seen the biggest failure point is in the requirements gathering process.
I’ll give you some anecdotal stuff like, so, some contractors that we know, the one pushing for the digital transformation or a new platform to solve one problem, they might be able to get that one problem a solution through a platform that they’re trying to implement or promote, but then beyond that, the failure point, it goes high because they’re not going through the right steps. And this is a case of like they don’t know what they don’t know, and you kind of have to have gone through an iterative process to refine it; and we’ve done that. So that’s why we want to share it here. We don’t want anybody to have to reinvent the wheel. If they can get success into learning from our failures, that’s great. We just happen to also learn along the way, and we didn’t give up and we got really good at it. But yeah, gathering requirements the right way with the right people and the right stakeholders, prioritizing your projects so that you’re building the things that’re going to have the most impact on your business, those are all things that need to come into consideration.
So basically what we’re going to talk about today is like how do we systematically, how do we break those down? How do we learn from other people, like maybe Corbins Electric on, hey, what did you do that worked well? What did you do that didn’t work well? because we certainly have those. We have both. You know, we’ve been living—you know, this is a spectrum of like, hey, here’s all the stuff that went really well. And here’s the stuff that—we were constantly swinging back and forth trying to find, you know, a good spot in our processes. We think we have one now. So, yeah.
One of the things, to answer your question, Josh—well, we’ll get a conversation going, I guess—is how do we even identify, okay, we’re a company, we realize we have some processes we want to put in place, whether we have a platform or we don’t, we go, okay, now what are we going to go work on first? Usually, and this is what happened to us, the thing we decided to work on first was the thing that was causing us the most pain. Right. And by pain, what I mean is we had processes in an organization that were causing a lot of rework or create a lot of paperwork or consumed a lot of people’s time to do that. Now, we were looking at those things because we were looking at a point where we were about to scale up. Right. We’re about to go from $28 million electrical contractor to 40, maybe 50. And we knew that human beings were going to be a constrained resource for us. So we want to automate some things that a lot of human beings were doing. We want to automate those workflows. We wanted to check for errors, validate data, all of these things, which we’ll get into, like how we gather that stuff. But that’s where we started.
You start with—this really actually goes back even before we found Xalt. We did a group book study on 2 Second Lean by Paul Akers. And for anybody who hasn’t heard that, I mean, if you’re in the construction space or manufacturing space, you’ve probably heard of this sometime in the last 10 years. But it’s a really simple read, it’s like 75 pages with big type and pictures. But anyway, we did this book study 2 Second Lean because it is just about process improvement, continuous improvement. And we took a lot of things out of that. And we said, yeah, this is a good mindset. This is just a good general mindset that we promoted it within our company. Dozens and dozens of people read it and started implementing small, little things that they can control. Maybe not 2 Second lean, like they didn’t necessarily take it literally to try to improve their process by two seconds. It was all about continuous improvement. Hey, is there a better way of doing this thing? Right.
The other thing we took out of that was also knocking down the silos. We had departments working in these silos and they only cared about the work that was right in front of them. And they didn’t really care about where it came from upstream and who needed that information. Once I’m done with it, who needs it downstream? So it got us thinking about a lot of things. And this is just like another iterative process out of that continuous improvement. Okay, now we have a platform. We can do digital workflows. Okay, let’s start. What are we going to work on first?
JC: So even before that, what I’m hearing you say is it was philosophical first. It was sort of a cultural like, okay, we’re here together in the senior leadership team or whomever, and we’ve decided we recognize maybe we can’t put our finger on the most important one first. But we recognize that philosophically we have a problem. There’s rework happening. There’s probably a little bit too much administrative overhead, stuff like that. So it’s philosophical before it’s tactical, right?
JDM: One hundred percent, yeah. It’s a mindset. It’s a philosophy that we have to be bought in for. And to take it one step further, one really important thing about implementing anything new in your company is buy in. Right. Buy in from the right people at the right levels. And, you know, as kind of a top down approach to that. But that can get sideways on you, too, because you could get “permission” from your CEO or CFO to go explore this thing and permission to go do something that’s completely different from having a champion at that level who’s also promoting it, right, and saying, hey, guys, here’s the thing. You know, looking around at all the leaders going, here’s the thing we’re going to do because we think this is going to X, Y, and Z to help our business. And I want you guys bought in and, you know, it could be like, hey, so-and-so is taking point. You know, JD’s taking point, Nate’s taking point, so they’re going to be around and talk to you about the process and how we’re going to do—it may not be the CEO being the tip of the spear, but what they’re doing is laying the groundwork to be able to go get things done. We certainly didn’t, I mean, beyond permission, we certainly had a top down approach of like fully bought in mindset. It wasn’t like a little side project. Hey, you guys, we’re going to go create some workflows around time card collection and material requisitions. And, you know, if it works out, great. You know, we’ll try it and see if it works out. And… No, we had like a really bought in from the top, going, hey, guys, this is something we think is going to change our business, so get on board.
JC: So if I may take a slight rabbit trail, what is the difference between your culture and your decisions and some of these other companies? Because there’s still an addiction in the industry, in construction, I would say especially, where you want to go buy a software that does a certain thing, that says, okay, now I go buy a tool tracker. And the inherent problem with this is you buy a document management system and a tool tracker and a time sheet deal and everything else, so then you’ve got a whole bunch of systems that are difficult to talk to one another, and they kind of require you to conform to them rather than them conforming to you. So it becomes sort of a diminishing returns the more you get. What changes you from that philosophy, which I would say is prevalent today in the industry, to we’re going to take ownership of this and make sure we squeeze this orange for all that we can get out of it?
NU: Yeah, I think honestly, I think the skipping ahead a little bit on kind of past the prioritization point, it comes down to really defining your problem is really what it comes down to. Right. Are you trying to solve a specific like I just need to track my tools, I’m going to get a tool tracker, or am I just trying to solve this, or are you trying to solve interdepartment communication or are you trying to solve that? Right. A lot of that comes down to the decision of are you trying to do a kind of full transformation or are you trying to solve one or two problems with a specific tool? Right. And again, for different companies, that’s going to mean different things. Right. Are you looking at a specific problem and is that solvable with a single solution? But you don’t really know that without really going down and getting to the root cause of the problem. Part of the prioritization of what we want to tackle first comes down to—JD already started a little bit of it—but aligning that with the strategic objectives of the team. It’s making sure they’re bought into the kind of focus of what we’re trying to do and if the purpose is we’re just trying to solve one or two logistic problems, that can be solved by some kind of ad hoc software that solves a specific scenario. But if you’re really trying to optimize every piece of your business, include communication from here on out, continuously improve, that’s when you need to look at a solution that’s a little more advanced in terms of being able to pivot quicker for some of those environments and being able to solve there. And a lot of times it’s a little bit harder to kind of see that future in terms of those needs. But as JD said, it really comes down to what does your culture look like? Is continuous improvement involved in everything? Or is this a project that’s going to come up every one or two years for a big ticket item? That’s really where we’ve seen a lot of the differences in terms of the attitude and the approach towards kind of ad hoc versus process.
JDM: And I think from our perspective, culturally, yeah, there are softwares out there that solve, that may solve a very specific problem that you have, and we did that. We went through, we are actively searching for solutions and for some of our most basic project management needs, time card collection, material requisitions, you know, things like that, just general project management software; there were tools out there that solved those needs. And I’m not opposed to having a single solution if it really does solve your problem. What we realized is that when we are going through all these demos is not all of them solved all of our issues. Not any single one of those solved a comprehensive problem that we had. It may have solved 75 percent of the thing, but what we weren’t willing to do is settle for that canned solution for something that didn’t meet our needs and meet our current needs, and we were looking for scalability. Hey, does this break at scale? because we knew we are in a growth pattern. Does it—? Are we able to be consistent with it? And then beyond that, there is other things that we’re looking at, like do I really want to manage 12 different software solutions? because then there’s a burden on IT for administrating passwords and resets and licenses and, you know, every single one of those different solutions acts differently and has different back end and may produce different data and bringing all of those things together. In fact, there are contractors that we know, our peer group members, who’ve already gone down the road and really dug in on very specific solution needs that solved very specific problems. They could have 10 of them, let’s say. And then what they’re seeing a couple of years down the road, like now, is that they don’t have a way of bringing all of these disparate systems together comprehensively to be able to look at data or manipulate the data. And I still promote because I still think Xalt is the best solution for that, is being able to talk to all their disparate systems that don’t naturally talk to each other. And I know a lot of them are like, yeah, we have APIs, but we all know that that’s—anybody who’s had to deal with APIs for a canned license solution, it could be very, very limiting. It could be really restrictive on what you’re allowed to go get or write to their databases. So anyway, culturally, that’s what we’re looking for, is like, hey, does this solve our problems? It can’t be the only thing you’re looking for. Hey, does this help us scale? What is the user experience going to be? I know we’re going to talk about user adoption and some other topics later on, but like if it’s not a good user experience, then it will fail. Right. If it doesn’t give you all the data that you need, it will fail. Whether you kill it or it dies out on its own or the users refuse to use it. So there’s a lot of things to look at.
JC: Good. All right, moving back to kind of tactical, once you have the philosophy figured out, you have your tool figured out and everything on that top down buy in, how do you identify a process that has waste and how could it be better? And what I mean is very specifically, especially if—and this has actually birthed a few more questions—but if you have many, right, and I’m sure by now you have suggestion boxes and people, once you do a couple of these, people say, oh, I know what I’d like to have in my department. So if you have many, how do you select the right one to work on next? And how, if anything, how do you gather those ideas from the field? Because not all of them are going to come from you, from people installing conduit, right? How does that work?
JDM: I’ll talk about that and I’ll turn my time over to Nate because he can really get into the nitty gritty on this. But like from conception, yeah, at first when we started rolling out a couple of different workflows that were proven to be successful, that were solving problems, that the users liked and it was helping our business, the question turned from like, well, what are we going to build beyond these two problems that we have, and transition to what are we going to build? They’re like, oh, man, if that can solve that problem, what else can it do? And what that did is we had a floodgate of people stopping by my office, going, I have an idea for a thing. Right. And I would hear them out. And that solution may only help that one individual with his one type of customer this one time of year. Right. And you go, okay, well, good idea. You don’t want to discourage them, because they may have other good ideas,. So you don’t want to shut them down, but you also have to let them down gently and go, okay, well, what we’re trying to solve are these bigger issues. And so we actually don’t, Josh, we don’t have a suggestion box per say. What we do is we actually run ideas. If somebody does stop in with an idea or email one or text one, we politely nudge them to their operational leaders of the business because there’s more to the discussion. Right. Because you can’t just go look at a thing that one person has and go, oh, we’re going to solve that one problem. You have to look at what’s upstream, what’s downstream. You know, there’s other discussions happening about maybe similar workflows in our business or other things that might be integrated in that, that that particular requester doesn’t have information on.
But one of the tools that we use in order to kind of vet ideas, we have a requirements gathering like a triage thing, which Nate will talk about. But let’s say we get a bunch of ideas and they’re all good on topic. We go, oh, we need a time card solution. We need a customer relationship manager. We need a shipping calendar. Just think about—we need a T-shirt size collector. Okay, cool. Those are all great ideas and they pitch their reasons why it would help the business. We do a—I kind of talked about this on our last podcast, but like a simple matrix, like an impact versus effort matrix, right. And it is impact. Just to get a little more details from our last topic, impact could be what is the impact on our business? Is it going to help us financially? Is it going to increase speed of a line of service that we do? Is it going to remove the noise or clutter or individuals in our business so they can go focus on other value added services? So that’s what we’re talking about on impact.
Effort. Effort could be, okay, how much is this going to cost? And you could translate almost anything into a dollar, right, when you’re talking about business: time, human capital, third party resources, hardware, software, and the list goes on, but that’s effort. You can look at it lots of different ways. And we start taking these ideas and going, okay, just really rough idea. What is this? What is the material requisition going to do for us? Where would you plot it? right on this impact/effort matrix. And we ended up plotting all the things and then we kind of break it down and go, okay, if it’s high impact, low effort, let’s go work on those things first. That’s quick wins. That’s what we call quick wins. Right. We should see a return on investment. It’ll help a lot of people. It’ll save money, whatever those impacts are. And then we go, okay, let’s look at the low impact, high effort. Those are things we’re going to punt on, okay? We’re going to go, ooh, I’m not sure any of those will. Maybe after we build all the other things, maybe we’ll go look at that list again. Low impact, low effort are things that we’ll use as filler work. You know, we’re constantly juggling multiple projects at a time. We’ll go use those low impact, low effort as like filler kind of projects while we’re in between bigger projects. And then the high impact, high effort are things we’ve got to go re-prioritize again. We’ve got to go look at those and go, ooh, okay, we know it’s going to take a lot of time, money, effort, human capital. Right. But we know it’s going to have a huge impact on our business. So we really have to plan those out. We have to plan the resources. What we don’t want to do is hastily start one of those and realize we’re not going to be able to see it to completion. So those are the things we really look at again.
Nate, what do you want to add to that?
JC: And on demand or is that on a monthly basis? How often do you do that?
JDM: Yeah. So Nate and I constantly, we have an ongoing meeting. At least every month we look at like the prioritization of all of our projects. But it’s on demand. It’s kind of as things pop up. And honestly, sometimes we won’t even entertain new ideas of projects because we have a backlog of really important projects. This is something that is really important I want to drive home too.
Nate is part of our executive leadership team. There’s 19 people on this team in our business, and they represent department leaders or other influential people in our business, decision makers. It was really important that Nate was part of this executive team because he gets context to all of the other things that are happening in our business and he can actually help direct or at minimum ask the right questions to extract the level of priority. And knowing how the rest of the business is going, he can kind of know when to call B.S., you know, on things, or he might know that, absolutely, okay, I can see how this fits into our overarching goals. I’m going to make an executive decision and kind of bump that up the list on prioritization. But Nate, so how does that go for you?
NU: Yeah, and I think you touched on a good part of it. To provide a little more context on the impact and effort, right. A lot of times that could be difficult in dictating the impact. J.D. gave a couple of examples of how we’re able to do that and the more practice you get at it, right, the better you get. But when we first started with identifying the impact on our business, we really started with aligning that with the strategic objectives of what we were trying to go after. So if that was for this quarter, we are really looking at our labor shortage and attracting more talent, well, then any projects that were like focused on the HR talent acquisition side of things, those would all of a sudden get a bump on the impact, right, when we’re looking at a number of people or anything like that. So aligning that with the strategic objectives of your company not only allows you to really make a very quantitative and say, hey, this is really what we need to go work on, it aligns with the other things that we’re doing in our business to go after that. But it also helps align the people that you need to get involved with it. When we’re talking about buy in, we’ll talk about other things like that. But if everyone’s working towards the same objective and your workflow that you’re developing is also pointed towards that, it makes it a lot easier for other people to work with you on getting that information and pushing that across the finish line. So that’s what we’ve really found in terms of the impact. And the effort you’ll learn depending on whatever software solution you’re using or whatever, how you’re designing what that looks like, that’s really going to kind of ebb and flow as you learn, hey, how can we optimize our efforts on that and other things as it’s built out?
The last thing that I would say for the effort piece is how big and cross departmental it is. That’s a really big point for us. If you see in a process that covers five or six different departments, every time you add that second piece of, you know, hey, this is HR, accounting, field, right, whatever that looks like, every time you add another piece of departments or whatever that looks like in your business, it increases that complexity so much more and that effort ends up skyrocketing not because the solution itself might be more difficult to, but it’s really getting down to those requirements of, hey, what are the pain points for each sector and making sure we’re aligning those and getting that all into one solution. That’s really where that effort starts to creep up and really get to a point where it’s, you know, if it’s still important, we’re still going to do it. But just be aware it’s going to be a larger effort than, you know, a couple of meetings here and there and get going on something. So in prioritization, I think aligning that with the objectives is really the key there.
JC: Was there ever a time that you didn’t get it right in terms of aligning the impact with the strategic objectives? And what did you learn if you weren’t doing it that way?
JDM: Yeah. Nate, talk about the CRM. That was a recent one. We created our own customer relationship manager, guys, going back to our previous topic that Josh just asked a little bit ago was like we couldn’t find a solution that met all of our needs for a CRM from an out of the box or even another platform. So we decided to spend the time, money, and effort to develop our own. And we recently launched at the beginning of this year. But that was a long and arduous process. Nate, you want to dig into that and how that—we had some false starts on that?
NU: Yeah, and I think it’s a good kind of segue into, like, gathering requirements in the first place. Right. So real quick, going back, and the first thing that we do when we get a kind of big idea. Right. So somebody says the, you know, buzzwords CRM or anything else like that. First thing we do is we run them through and we have them fill out our triage sheet. This will look different for whatever business you’re in, whatever that looks like. But what that implies is it’s just a couple of questions that we ensure the individual or the group of individuals that is coming up with this idea has really thought through what this looks like. It’s not just an idea in their head of what that is. And sometimes if it comes back and there’s not a lot, but we still deem it a good idea, we can still work with them on fleshing that out, but a lot of times we’ll have individuals in our business say, hey, I’ve got this great idea, and that’s all it is. It’s an idea we don’t have, hey, what departments are involved and what’s the impact on the business and how much, you know, what is this, how is this going to move the needle on these objectives? And so that’s really how we align it with those objectives, making sure that we have that, because a lot of times when you see those false starts, like we’re talking about with the CRM, we are trying to solve a problem before we define what the problem was. Right. And that’s the number one point that you get to in requirements gathering where you realize, hey, we’re not actually solving a customer relation management. Right. We’re solving an estimating bid process, or we’re solving, you know, tracking our communication with our customers. There’s a lot of different, I guess, ideas when you get this cool, high level idea of—it could be something super simple, like tool tracking. Well, what are we actually trying to track in some of those software? So, again, really starting with that initial questions of making sure that they’re grounded in the business impact and kind of going back to some of those deciding factors really helps us align it and avoid some of those pitfalls that we’ve seen. Like JD mentioned, you know, we had a couple of false starts there on what we wanted to do with the CRM and what that was supposed to be but before continuing on.
JDM: And one of the reasons, because it fell on the impact/effort matrix, it fell way up high impact, high effort for us. Right. And why was that high effort, Nate? Why did we rate that high effort?
NU: Because it was going to touch every sector of our business. It was one of the things I talked about in terms of really pushing that effort off the graph there a little bit is it wasn’t just our operations team that would be using it. It was our operations team, our estimating team, our vendor and our material groups were going to use it. Our safety group was going to use it. Everybody was going to be involved in this and everyone had different needs that came out of it. And so when you’re talking about, you know, requirements gathering, those are always going to be the hardest just because, one, you have a lot of different opinions in the room. Right. But identifying what we’re actually trying to solve, everyone’s got a different opinion on it and getting down to what’s really going to move it forward for the business and what’s even you know, if you try to tackle ten different problems at once, you’re never going to solve anything. So really narrowing it down and saying, hey, even if we just solve this one problem that’s top of our list, let’s start there and then continue forward. We almost always never, we almost always release kind of what we call kind of a phase one, phase two, and we group the features into those phase one, phase two, because the second you try to solve this huge problem at the same time, it never, never tends to work out. So and I can go into more detail on kind of how we walk through that, the meetings, if we want to as well.
JDM: It’s so important, though, because it’s something that we’ve kind of coined the term of. We call it the Medusa, which maybe we should find a friendlier term. But how can you tie, you know, strings to every part of the business where when something in one area falls out of an optimal state, that’s going to affect another area? I don’t know, shipping and receiving versus the job site. Right. How do you, what’s the workflow to inform to even see that that’s happening in the first place without making a phone call or send up a smoke signal? But how can you build solutions that very naturally serve each part of the business, but also notify the others and help the business run more cohesively? So practically in what we were just talking about, like, let’s call it the CRM, do you have your triage sheet? Do you send it separately to the different departments and then bring them all together in the same room? How do you map out the current state? What does that actually look like in that situation?
NU: Yeah, perfect. So there’s a lot that goes into this. And honestly, when we’re talking about the scale of the problem, it will kind of adjust our approach a lot when we go down here. But there’s kind of a couple key points that we always make sure to hit on. So the first one, as we said, that initial vetting process of the idea and then that leads into the prioritization. So let’s say we’ve now greenlit the idea. It is something we need to solve. Right. And at this point, we might not always have a great idea of what exactly it is. Right. It’s hey, we’re trying to solve a customer tracking, customer communication problem. Okay, we don’t necessarily need to get super far down the road. If enough people say that moves the needle, let’s go and take a look at that. That’s really all that initial vetting process is looking at.
Now, what we’ve done is the next step is identifying the stakeholders and saying, hey, who are the people that we need to get in the room that will be able to actually make the decisions on that? A lot of the times that’s going to be people a little bit further upstream in terms of a little bit more of either managerial capacity or the individuals that are actually, you know, have the authority to make decisions. Because a lot of times if you get somebody in the room that is a product of a lot of these processes, they can identify some of the pain points, but they won’t necessarily be able to see the big picture. So a lot of times—
JDM: Yeah. That’s kind of the difference of like a power user versus like somebody who’s responsible for a product. And sometimes they’re the same people. That’s actually super convenient because we can get them in the room and they could wear both hats. Sometimes they’re not and most oftentimes they’re not.
NU: So we usually identify at least a couple of key stakeholders in those processes and they’re in charge of going downstream and gathering that information. And the reason we do that is because we can’t have 20, 30 people in the room. The second that number gets even above five or six, it starts getting out of control. We have opinions on the wall. Nobody can decide on a single thing. Too many cooks in the kitchen. Right. You’ll hear that in kind of anything you do, that’s really where it goes down there. So having key stakeholders who are in charge of gathering downstream information is the best way that we found to make sure that we are actually moving forward and having the ability to make decisions on processes without sacrificing the information downstream.
So now the first part of that process might be identifying the individuals that you need to do. And that actually might be a meeting or the place you need to start, because a lot of times and one of the things we faltered on first is we try to solve a problem that we thought was siloed and didn’t have a bunch of connections, but ended up really talking to five or six different departments. And we didn’t find that until going a little bit down the road. And so starting with that and trying to open up whoever you’re working with and saying, hey, is there any upstream, downstream here? Is there right are you sending this up? Is this going out? Is this you know, even if you’re based in the office, is this relating to the field at any point? What does that look like? And who’s involved? Starting there really allows them to start thinking about the big picture in terms of, hey, this actually isn’t just affecting me. This is affecting everybody downstream as we go along. So that’s kind of the first point is identifying the stakeholders, making sure you have the right people in the room, but that they also have done their due diligence in, you know, going downstream and making sure that they have all the information they need there.
The second thing is really not trying to get the individual to craft up the technical solution themselves. Right? Again—
JDM: Yeah. This one’s super important.
NU: Yeah, it’s, right. We don’t ever go into meetings and say, hey, if you could have an app that solves this problem, what would it look like? One, a lot of people would be uncomfortable with this question. Right? I mean, they don’t know what that is. They don’t know what that looks like. Number two is they start drawing some thing in their mind. Right. And you immediately are putting barriers around their solution instead of getting them to open up, which is really the key to the requirement gathering process. And so we usually start with kind of two, you know, questionings that really help.
The first one is going through a best case scenario. Right. So, hey, we have this problem. What is the best case scenario to finish it? We’re not talking about an application. We’re not talking about that. Right. If that’s hey, my foreman in the field can fill out something on his iPad. He can ship it over and then at any point he can check to see what the status of his order is. Or I’m out having dinner with a customer and I need to log what I did, I need to be able to pull out my phone and log whatever that is, and then everybody in the company can see it on their dashboard the next morning. Okay, those are real best case scenarios that we can start dissecting and talking about and start driving through there, which is a lot more approachable for even individuals that haven’t done a lot of process mapping or requirements gathering any of that. They’re able to say, oh, yeah, like I’m the subject matter expert. Let me tell you what that would look like, and then we’ll talk about some of the details and go from there. So sometimes starting at the end, whether that’s, hey, what data do you need out of this process? Right. Sometimes we start with as simple as that. Hey, if this is really just an information gathering process, what information do we need out of that? And let’s back up into kind of what the gathering process looks like.
JDM: Yeah, let me.
NU: But that’s really— yeah.
JDM: Piggyback on that. So this goes back to an old and everyone has heard this at one point. But like, you go back one hundred years and you know, Henry Ford, if he asked people what they wanted, they would say, oh, I just need a faster horse. Right. So sometimes when we ask people like, oh, what do you want? They’re kind of stuck with in the limitations of their own world view or past experiences or tools they’ve used in the past. For example, somebody say, oh, we need a pre task plan. Right. A pre checklist for safety before we go do an activity. And you ask somebody, what do you want the pre task plan to be, you know, in a digital platform or whatever solution. And the way that they think about it is, oh, it needs to look like an eight and a half by eleven and it needs to have fillable boxes. Right. Because that’s the mindset. They can’t think beyond the thing that they’ve experienced. So that’s like one of the things where, they’re really limiting themselves, confining themselves. But if we asked them, no, no, forget that, just like what would that look like for you? Then they also can’t conceive that. So sometimes we have to, like, help guide them and we can start a digital form or some pie in the sky idea. And this is really where the, you know, Nate’s a genius comes in, is he helps refine and go, okay, so what does that look like? Okay, what does that look like? And then we go, oh, we get to a thing. We go, oh, that’s a very useful look. Let’s back up and go, okay, what is this other thing look like then?
So anyway, that’s a real—when you have somebody at like an executive level try to do that, who this is a part of their normal daily routine, it can get messy. Or the person in the room with the most authority starts making decisions completely—it’s not their area of expertise. They’re not the user. They’re not going to live with the consequences of these decisions. Or sometimes we have peers in the room. They all—we have for example, we have four vice presidents of operation in our business. And one of them, who shall remain nameless, is the loudest one in the room, okay? It’s just because that’s his personality. Naturally, he’s loud. He talks a lot. And, you know, we can’t fall into the trap of the loudest person in the room gets their idea across just because they’re, you know, the most influential or the most passionate about that thing, doesn’t mean that thing is the thing that needs to happen. Right. So having a moderator like Nate, who is independent of what the process is, because his responsibility is to make that process the most impactful with the best user experience, he doesn’t really care whose idea wins out, but he’s going to help you refine that as you go on.
JC: Yeah, it sounds like Nate in true user stories rather than any sort of solution design. And is there also a current state process map that makes its way into the requirements gathering?
NU: Yeah, so a couple of things. Don’t focus on the technology, right. Really focus on the what we’re trying to solve. And that’s the other thing. Right. So I started my first suggestion was, hey, start at the end, right. Best case scenario, start at the data side of things. What’s the data outcomes of those? The next thing. Right. Say that wasn’t very successful. You didn’t get a whole lot there. The next thing is to really focus on the pain points. What is painful about this process? Honestly, that’s a really easy question to answer for anybody that’s close to this. It’s not, we’re not asking them what’s inefficient about the process. We’re asking them what causes pain, right? Now that is the same question, essentially, but it’s a little bit more approachable in terms of, okay, when I’m thinking about what causes pain, that can be time spent on the process, that can be the output of the process causes pain, that can be downstream, they aren’t getting what exactly we need, upstream is not getting what we need. Right. All kinds of different things that really allows us to really see the key problem. Again, a lot of times when we go into a lot of these meetings, we have an idea, problem statement that we’re trying to solve. And the second we start dissecting it and breaking it apart, most of the time we pivot, you know, we’ll still have the same core idea, but we end up pivoting to almost a completely different concept. Right. This is called root cause analysis. Right. That’s kind of its general term. But asking those questions and getting down to those, hey, what exactly are we trying to solve here? That could be the hardest question when we go to start, is—
JDM: This goes back to the Paul Akers 2 Second Lean is basically, really simply for those guys have read that book, he just started asking his people like, what bugs you? What bugs you? Sometimes that what bugs you is the overarching process. And then we kind of break it down, you know, and it goes and we go, okay, yeah. About the data collection. What bugs you about the data collection? Right. And we just kind of refine it that way.
But, Nate, can you talk to Josh’s question about what kind of documentation do you guys collect during your—do you collect it, do you store it, how useful is it when you start implementing the digital workflows? What’s that like?
JC: And what tools do you use? I think you used Vizio because you sent me a few of those.
NU: Yeah, yeah. So in terms of kind of, you know, the exact processes, so first thing we do is identify—it depends on kind of who we’re working with. Some people are really comfortable with creating a process map that have been through this process before. Not a ton of people and a lot, especially when you first starting some of this journey, that won’t be as approachable, but so many in your business should at least understand what a process map is and how that helps really clarify what we’re talking about. You can talk all the time about, hey, this moves from information to information. But again, if you have a process that starts jumping from department to department and each person has specific roles, it becomes very difficult very quick when you don’t have a way to visually see and confirm, hey, this is exactly what we’re talking about. We’re talking the same language here. So we do always either get a process map from the individual that owns that and start there, or usually what we do is through that first kind of finding your root cause analysis and understanding and starting with, hey, this is where we’re at current state and then this is where we need to end up to be. And a lot of times that end up process is really just circling a couple of things on that current state and saying, hey, this is our pain. Right. And it’s just another way to visibly see what we can either talk about by some of those leading questions or by visually seeing some of that. And yeah, so we use Visio. There’s a ton of other software out there in terms of creating those types of documents. But however you’re doing it, visualizing, hey, is this a data transformation? Is this a people involved individual? Right. We always talk about the funny kind of whenever somebody tries to put a name on a workflow mapping, we always erase that—or that’s always the gap is, hey, well, Susan is the one that processes these things. It’s like, well, what’s so special about Susan? Well, she’s the only one that knows, right? We call it tribal knowledge. You can call it whatever you want, but that is the items that really causes the workflow to fail is if there is a single stopgap or if it’s something, what that usually means is that something we don’t fully understand.
JDM: Yeah. Susan does a thing. We just don’t know what that thing is. So we’re just going to put Susan’s name in as the step in the map. Yeah.
JC: Do you ever—so, it sounds like you guys have gotten pretty good at this. Do you ever have to go back to the well and say, all right, we think we have it figured out. Then you get the stakeholders together again and just kind of confirm, like this is our understanding of the current state. This is our understanding and what we’re going to go attack. Our next episode will be about solution design. So, okay, you have the requirements now. How are you going to go design the solution? What are your tools, your processes and so forth? A lot of that is kind of covered in this recovery requirements gathering, but there’s some crossing of T’s and dotting of I’s that we certainly, we find a lot of value in solution design and so forth, and we’ll go through solution design validation and all of that. Do you ever have to go? Last maybe question or two. One of them is, do you ever have to go back to the well with the stakeholders and do it again?
NU: Oh, yeah. I mean, so one of the things I was talking about. Right, there’s a lot of different ways to approach each of these things, and what you start getting good at as you do this very often is, you know which approach to use based on the people that you’re talking to. So whether it’s best case scenario, right, asking the pain points, if somebody’s very technical, usually those workflow diagrams are the best way to get across, kind of, hey, look at this. Right. If you’re talking to an engineering type or anything like that, that’s a good way to do it. Sometimes it doesn’t work.
JDM: Sometimes, Nate has to like observe. You know, he has to physically sit with them. Accounting was a great example of this, right, because it was hard for them to write out in a document or even they did their best to map their process, you know, like setting up a new customer process. But it was so involved, even though they have the document, he had to sit with them and really experience the thing that they are going through as a pain point as, like, another layer of like validating some of the things that they are saying. Not that he didn’t believe them, just added some value for him, right?
NU: Right. And it allowed you to gather context that you might not always see right away. And so, yeah. Sitting with them, if that’s a possibility, that’s the best case. Right. If you have the time and the opportunity to do that, there is no better way to truly learn about some of these process in that way. But a lot of times, even when you get to those, there is some times where it’s a process that’s relatively new, it’s not very defined. And those are the tough ones really to crack, because no matter how many times you put it through a digital solution or whatever that looks like, sometimes, especially if the process doesn’t exist and we’re trying to create a new one as well as digitize it, that problem can be really difficult.
And we kind of solve that in two different ways. And it’s really the same thing. It’s prototyping and that can look at two different types. The first one is prototyping it out on paper. So a lot of times when somebody comes up and is dreaming up this big idea that needs a technical solution but can be tested out on paper first, right, paper forms, whatever that looks like, that’s the easiest way. It’s the least amount of capital and allows us to prove that idea. So a lot of times we’ll challenge those stakeholders and say, hey, guys, can you write, just try out this material ordering process, for example. Have them fill out this information, bring it back to purchasing. Let’s do it the old way. Let’s see what that looks like. And then we can look at the pain points to that process. Well, if that process didn’t exist in the first place, there’s no way we can kind of learn from it. So that’s kind of the first way is kind of prototyping on paper.
Now, a lot of times that is pretty painful and a lot of times setting that up isn’t super useful, which is when you get into technical prototyping. So that’s using whatever tool you’re using, whatever software you’re utilizing, and coming up with, hey, we know we don’t have the full requirements. Here’s where we’re going to check in. Right. This is what we have so far. Let’s create what we have. Let’s see what it looks like, beta test it, whatever that ends up looking like, and let’s continue on. So those are those check ins with the stakeholders that you’re talking about in terms of it’s almost impossible to get all the requirements straight up.
JDM: It’s impossible.
NU: It is. Sorry. Not almost impossible, it is. In terms of a lot of times it comes down to use, right. Now you try to get as far down the road as you can because that’s the less pain that you’ll get. And especially for big ticket decisions, right, you don’t want to be adding in a new department three quarters of the way through the process and then redesigning the whole solution. That’s when you’re going to get a lot of those rework and delays. But capturing the idea of the solution, the individuals that are involved in the basic workflow and then knowing you’re going to have to iron out those details later. But if that’s part of the solution design, a lot of times it’s not as painful as thinking you have the full solution going in there and then all of a sudden you get hit with, you know, seven or eight new features that were never even dreamed of when we were going about it.
JDM: No one mentioned them at all up until that point.
NU: Right. Yeah.
JDM: So what is your sprint cycle like and how often are you having sprint cycles and what do you do with them? Are you checking in with a customer at each sprint cycle?
NU: Sure. Yeah. So it really depends on the, as I said, how full that requirements process was able to—how much we were able to vet out. If we really do feel really comfortable on it, we know what their vision is, et cetera, we might not check in. And so we have, you know, a minimum at least a viable product that’s a little bit further down the road. Other times, it’s if we end up with, hey, we’re not really sure what this looks like. I think we have an idea of the vision, let me go and try to create something for that, that’s where that minimum viable product comes in in terms of, hey, the second we have something to show you, we’re going to get in front of you and we’re going to make sure we’re validating what that looks like. Hey, is this really your vision? Is this really your vision? Because, again, you can talk to someone in a room, you can sit with them, you can do all these different things that really does help you get towards that, but a lot of times for these big overarching solutions, prototyping and beta testing is really going to be your biggest learning point, especially when you have, like geographical issues in terms of you have like seven or eight different—same thing, right, where you have different jobs out in the field, but they all do a little bit different things. It’s almost impossible to go out and really live each of those different solutions. Right. That would take just as long as it is to get the idea, get the general requirements, go in there, and build some of it and then go back out and make sure that that’s actually testing it out in the field. So, again, depends on the situation. And really, you’re going to have to read your stakeholders, read your confidence level in those requirements when you’re gathering that before deciding how frequent and how often those prototypic need to happen.
JC: So the message there and the takeaway is requirements gathering doesn’t necessarily end.
JDM: Yeah. Josh, just to reiterate some stuff, I know we’re wrapping up here, but the, yeah, it doesn’t end, because we’re constantly making small, small adjustments throughout the sprint cycles and the varying degrees of stuff that we have. And I know some of the other topics we’re going to talk about later, but I mentioned at the beginning of the call or of this podcast was like, hey, we were trying to approach our gatherings requiring something like a systematic, scalable way. And as you can hear, there are a lot of nuance in gathering requirements because the degree of difficulty, the impact, the effort that we talked about, right, the risk, the frequency, all of those things. So we don’t have a systematic way of gathering requirements other than we have really good people like me whose responsibility it is to do that thing, and you got really good at it. Now Nate is navigating all the gray area, all the nuance. Right. So, yeah, it’s not a checklist. We’re asking human beings to be the one to navigate this gray area. And we can get into other topics later on, like other podcasts about like the type of people that we look at for our team on Corbins Electric that worked for Nate on the NOX team on their background and their experience to add to the team to do just that, because it’s a little teaser. It’s not as straightforward as hiring a developer per say, right, because we need somebody to navigate this gray area and not, you know, not follow a wireframe. So anyway, that’ll be more topics later on, right?
JC: 100 percent. In parting, if there’s one, we’ve talked for the last hour on this subject, it’s so important for anybody listening that you get this right, that you don’t have to build things three times and also so that people use them, they get adopted, which is another topic later on. But what’s the one piece of advice from either one of you guys on the topic of requirements gathering that you would leave any listeners who are interested in the topic?
JDM: The number one thing I’d say is don’t be discouraged by your failures. Just don’t make the same mistake more than once. Learn from your mistake. Don’t let that discourage you. This is a process you’re going to learn. Don’t let that discourage you. Just don’t make the same mistake twice. That’s all.
JC: What do you say, Nate?
NU: I think Josh kind of hit it on the head there in terms of the really navigating the gray area is going to seem really daunting at first. But those patterns will quickly start to emerge in terms of when to use what tactics, when to really dive deep and when not to. It’s really a practice thing. But by utilizing a couple of those different, you know, practices and stuff, you’ll find that even the people you work with will start to learn what that looks like. And that’s really when it gets cool. When we’ve worked with a stakeholder that has already been through this process once or twice, I mean, it goes from six meetings to one meeting and we’re able to get in and they’re like, hey, I’ve already thought about the downstream, the upstream. I know you’re going to talk about growth and scalability. I know you’re going to talk about this X, Y and Z. And I’m like, well, shit, why am I here? Right. So that’s going to be the really cool part. You’ll learn that as well as the people involved and you’ll honestly make your company that much more of that continuous improvement and be able to pivot, whether that’s process or business decision wise really helps you think about problems in a different way, which is exciting.
JDM: And I know you guys do this, like Geoff and Josh, you guys do. You help your customers through this process. We do this also through NOX Innovations like help customers through this process. We may not do it for them, but we certainly don’t want to have to have people create the same mistakes that we did. So we can help with that. This is all about our big overarching strategy, like our purpose as Corbins Electric, like a change in the construction industry. We want to help other contractors or really anybody to get better at this. This is going to be the thing that helps people move their business forward. So, anyway, we’re available. They can reach out to you and they can reach out to us, and we’ll gladly have more conversations on this.
JC: Yeah. You guys can find us on the Internet. NOX Innovations, Corbins Electric, Hexagon’s Xalt Solutions. But I think that’s a good place to wrap. So, first of all, thank you. And by the way, I was going to say, when Geoff and I were talking the other day, our fundamental identity here at Xalt is problem solvers. It’s not technologists, it’s problem solver. That’s what we’re passionate about too. So it lines up really nicely. So I think we’ll wrap there.
Thank you, JD. Thank you, Nate. Thank you, Geoff, for being on.
Everybody, if you want to find this podcast, which I think you already did, you can find more on hxgnspotlight.com or on SoundCloud or Spotify. But thank you very much for your time and attention, and we’ll see you next time.
