In this episode of ‘Solving Problems with Technology’, our host Xalt Solutions’ Robyn Aaserude continues the discussion of digital transformation and solution design best practises with Corbins Electric and Nox Innovations, taking a deeper dive into what is needed to configure the right solution for your business and what to consider during the process.
RA: Hello and thank you for tuning in to this episode of Solving Problems with Technology on HxGN Radio. I’m your host, Robyn Aaserude. In this episode, we’re going to be talking about yet another important aspect within a company’s digital transformation journey, and that’s configuring the right solution. In prior episodes, we worked with JD Martin, JD’s VP and Business Solutions Manager at Corbins Electric. We’re welcoming him back. Nate Unruh, Business Solutions Manager at NOX Innovations, and Geoff Wakefield, our Hexagon Xalt Solutions continuous improvement expert. With that, welcome back, gentlemen.
All: Thanks for having us, Robyn. Good to see you again.
RA: Appreciate you guys carving out the time, of course. You guys have given a lot of insights, a lot of comments to build up to this point on a lot of different unique topics. I would like to just, before we begin, give a quick recap for our listeners.
In episode one, we discussed really the importance, what kicked us off, the importance of digital transformation. We discussed, you know, why at Corbins and NOX, why are you guys targeting and fixing broken processes within your organisation? What’s the real value there? We compared things like digitising versus digitalising and digital transformation and kind of cleared up some of the buzz words that are happening out there. We also discussed the impacts, the known or unknown, to your culture and the lasting fruit and change that’s brought about as a byproduct. Be sure to cheque that episode out. Episode two, we discovered the importance of requiring gathering requirements. There it is.
We learnt about the proper steps to take, who’s involved within the organisation departmentally, what are the key pitfalls to avoid? Episode three, we expanded on the topic of solution design. So, you have those requirements, what are you going to do to document? What are you going to do to design the solution? What are some best practises to follow? What tools, what software tools are you going to use? And that leads us to today. We’re going to spend some time on the topic of configuring the right solution. We want to explore, highlight what are some best practises when configuring the right solution? With that, let’s get started.
Nate, I’d like to have you start first. So, how do we do it? We have this solution design. It’s started formulating this idaea. It’s a blueprint, a document. It’s been reviewed, it’s been modified, but now it’s time to implement. Where do we begin when it comes to this workflow? What are some important steps to take? I’ll hand it off to you.
NU: Yeah, thanks, Robyn. So, this really gets into some of these specifics of actually building the solution, and this will look different for all kinds of teams, depending on what they look like, right? If you’re an individual building something out, if you have a huge team of developers, whatever that looks like, that will be the first idaea is really make sure that you’re focused on your team dynamic, what that looks like, who’s going to be involved, and make sure each of the roles are defined. So, you have somebody that’s on the kind of work management side, the product management, and you have the individuals that are actually doing some of the development of the solution. And then you’ve identified your key stakeholders. I know we’ve mentioned that quite a few times throughout this process, but those outside individuals that aren’t necessarily part of the direct team will really have a big impact on the success and failure of this, because ultimately, they’re the ones that are deciding that and we’ll get that out the door and launch. So that’s the first thing is taking a look at your team, what that looks like.
And then the second thing is breaking down the project into actual work tickets. And a lot of times it’s easy to try to tackle, you know, any size project with varying levels of detail and it’s much easier to approach when you actually split it up into various items, right. And this can look a lot of different ways for each workflow. You can split it up with kind of back-end database development. You can split it up with front-end and designing what the UI will look like. You can design, right, even if it’s just more workflow directing of what the flow of the application looks like. All of that is easy to split up into those work tickets once you understand, hey, this is how we want to approach the kind of development cycle. And that gives you an idaea of how you want to approach the rest of the project. And a lot of times it does take a little bit slower to get going on that. But that organisation, that realisation of the actual work involved is really important.
I’ve seen a lot of teams get caught up in, hey, let’s everyone just kind of work towards a general solution, right? We all know the end goal, and let’s just go tackle that. And a lot of times it’s, hey, you’re working on the front end. We’re in on the back end. Let’s get everything going and it’ll all work out. Well, a lot of times you just have a lot of opportunity to get caught up. And a lot of times that’s where you see a bunch of delays where either teams aren’t focused on the same goal or somebody is creeping into another person’s development side or whatever that looks like. And so, if you’re organised at first, that’s usually kind of our kicking off point to begin that development cycle. So, between figuring out what that looks like with your team dynamic and breaking it apart into smaller work tickets, I think that’s the kind of key to really starting off on your solution design, no matter what you’re using.
RA: That’s great. Do you guys—you manage a small team, keeping these guys on target, on track, what’s that process been like, delegating and getting these guys to move the needle, right? Ultimately, it’s going to be impacting your end users. So how do you keep these guys organised? Do you have a formal QA process that you’re checking in to make sure these workflows are good to go before they end up in production?
NU: Oh, yeah, absolutely. Yeah. So, the biggest, I guess, thing we’ve learnt over the last honestly last couple of years was the full solution is usually not what you want to have that kind of end goal in mind, right? That’s usually what you get from a stakeholder. Hey, I need this ready by X, Y, Z. And that’s always something that you want to keep kind of in mind, but you really need to break it down into much smaller portions, right? Phase one, version one, whatever you want to call that. And that’s going back to that kind of prototyping idaea that we touched on before is you really want to balance those stakeholder deadlines with also the internal deadlines. So, a lot of times what we’ll take is say, “hey, we have two months to finish this project. Let’s make sure that we have version one done by X, version two done by X, so version three that we’re releasing, that’s going to be our kind of full feature, complete solution that we are okay with”. And what that does is that creates not only cheque in points and helps you keep on track, because we’re not only checking in with the stakeholders when those versions are out, right. Those are our prototype versions. But we also understand we don’t get that close to that deadline and all of a sudden we’re scrambling. Right. If version one has a lot of issues, we know right away in that scenario that we need to move forward and make a lot of changes.
And so, you know, you mentioned the QA process. That’s obviously a big part of that and a lot of times, you know, work can be completed to some extent, but if it doesn’t go through the QA process, we don’t even count it as complete. And the biggest reason behind that is it’s pretty easy to get something that looks correct or make an attempt at something. But if that’s not up to the quality standards, you’re going to go back and redo, and redo, and redo over and over again. And so, a lot of times, you know, that QA process will look different depending on kind of the technology we’re working with. But it has to go in, at minimum, each of those version releases. And oftentimes if you can package kind of features together in terms of, right, this is our entry point, this is our visibility point, this is any kind of technological separation that you can have there, it’s great to throw those QA opportunities in the middle of there, right? And the formalised QA is really the important part. If everyone’s looking at it differently, if those quality standards aren’t standardised, then the quality and the feel of your apps will be different from product to product, from stakeholder to stakeholder. And that consistency and reliability in software is one of the best—it’s one of the most important attributes that you can have for a good end product there.
RA: And just for our audience, a question for you, JD. How many—just to give some context here—how many workflows do you currently have running in production? Because you guys have gone through this formal process of implementation. Just to give the listeners here a sense of the accomplishment and the work that you guys have done following some of these steps, how many, I guess, unique workflows do you guys have in production today?
JDM: In production like that, we’re using?
RA: Mm-hmm.
JDM: Not in production like being built currently?
RA: Correct.
JDM: Those are two different lists. As the unique workflows, it’s got to be, I mean, unique workflows, probably 40. I don’t know. It’s hard to say, Robyn, only because so many of our workflows, it depends on how you define “unique.”
RA: Mm-hmm.
JDM: Like, point, end to end, completely contained. A lot of the workflows of—one of the reasons why we use, you know, Xalt as a mobile workflow platform is I have the ability to be able to integrate lots of workflows for different people in their roles. I kind of look at it more like our workflows are like a river, and it’s constantly flowing, and we could have these offshoots. We put information in the river. It flows downstream. Some people pluck that out. Some people just need to know it went by. But it’s really, it’s an ecosystem now. It’s not just a bunch of applications that are self-contained.
I don’t know. What’s an example of one?
RA: Forty workflows is amazing. I think, you know, in my role, in my world, I’m talking to contractors and they’re excited and they should be for solving one. And you guys, and I want to highlight the differentiating factor is we go through these, we pick the right solution, we configure it, we build out the workflow because of a good design, we go through a formal QA process, and I mean, 40 workflows is an absurd amount.
JDM: Yeah. Don’t get enamoured by the number. That number really doesn’t matter. What matters is, are the workflows that you’re building adding value to your organisation? Are they improving processes? Are you able to get—and how you define “value” is really, that’s unique to different companies, different people, different situations. But for example, is it are you able to increase the speed in which you do something? Are you able to decrease paperwork, like physical paperwork, or are you able to decrease—a lot of times when we say “paperwork,” we mean data entry nowadays, right? Are you able to get information in front of people so they can make decisions in a timely manner? These are all things that add value. Is there automation that you can put in place that would reduce a human being doing that thing so you can have that human being do something else that automation isn’t a solution for yet? So, yeah, don’t get stuck on the number of 40 workloads. That’s just—we didn’t ever set out to build that many. We set out to build two and that was capturing time from our field—we call it a daily report—and material requisitions. We said if we set out to build those two successfully, it would add enough value to our business that the cost of the platform and the people building it, we would have ROI in the first year. We ended up realising that in the first eight months.
RA: Wow. First eight months, is a unique story!
I’m interested to know, Nate, I know you have a backlog of projects. Can you give us a little bit of insight on a project maybe you’re working on right now that is in this implementation phase and maybe something that’s a little closer to home that’s not delivered yet, but what is an application that you’re working on that meets this criteria in we’re doing the right solution, and what’s the next steps? Maybe you are in QA and what are some challenges that you’re working on in having to work through related to this specific workflow? Are you able to share one with us today?
NU: Sure. Yeah. I mean, right now we’re, actually one of the smaller projects that we’ve come across in the past little while, and we’re working on a simple kind of apprenticeship tracker in terms of tracking our apprenticeship involvement, the status of all of our guys. It was a quick win for our workforce development team and it’s currently going through the QA process. But that’s a good one. Kind of good example of one of the real challenges of solution design comes down to managing those priorities. Right. And that was a good example of it’s a small project that we in terms of impact and it had a large impact, but we knew it was going to be a quick win. And so, it kind of shot up above some of those other projects that we had in there, and we pivoted pretty quick on that. Got it out in about a little over a week, which is great.
But the biggest, I guess, focus on that is knowing that that pipeline and those deadlines and the expectations are always going to be moving. Right. We’re working inside an ever-evolving environment that those deadlines, those priorities, everything that we get, it’s a constant stream of change and understanding what that looks like. So, when we go down to, you know, we have this wonderful chain that looks great, right, and oftentimes it seems like, hey, we’re just going right to development, prototype, QA, release, you know, success, well, that’s hardly ever the case, right? A lot of times we pause, work on something and go forward. But a lot of times those roadblocks and priority changes and other things like that where they really have a large impact is if you didn’t have a good plan to start with, right? You didn’t understand the requirements. You didn’t have good documentation of what that looks like. You didn’t have a good development plan where you can stop, have a stopping point, go pick that up at some other time, right, take a look at and be able to hand that project over to somebody else and say, hey, here’s the requirements. This is what we’re looking at. Because if you can’t do that, then any time you have a change or update or anything like that, it just completely destroys the process, and you have to kind of start from scratch. So, knowing that that’s part of the process, ensuring that’s almost intended in the cycle for your solution design is extremely important.
RA: Mm-hmm, mm-hmm. Do you find engaging with—is it too soon to engage at this step with kind of this implementation QA—we’re starting to shape the application itself—are you engaging with the end user at all at this step? Is it too soon? Are you doing QA testing within your own kind of small team? Who’s checking the work as you go?
NU: Yeah, and that’s a great question. I mean, most of the time it varies on stakeholders’ stakeholders. So, some of them that are more involved have a lot of time to review each step of the process. Oftentimes we’ll add some more cheque ins, but oftentimes we’re building applications for individuals that don’t have a lot of time to review some of this stuff. Right. Executives, project managers out on job sites, other things like that. It provides a lot of—and that’s really where the priorities and the emphasis on gathering those requirements as best you can up front and asking those right questions becomes so much more important, because while we’d love to have, you know, that stakeholder kind of sitting there, checking in every couple of days to see where we’re at and being able to review that and having, you know, that’s just not feasible when you look at an organisation where this is, you know, they might have two hours a week to review that stuff, if you’re lucky, because they have a job. This is important to them, but that doesn’t mean that they’re going to drop everything and go help you out. So, it’s balancing that with what can our team do to make it easier for them to understand the solution and get something in front of them. So, we’re not going to show them something that’s a really low level. You know, we always talk about the MVP, the minimum viable product. And a lot of times that, again, as I said, it differs from stakeholder to stakeholder, depending on how much contact we’re able to have with them. If it’s a weekly cheque in, then we might show them something a little bit rougher, not exactly defined. But if we have one meeting a month with that individual, then that needs to be pretty polished. We need to make sure we’re understanding what we need to show them and how that looks so that we can have a productive meeting. We can use that time appropriately before continuing on.
And like you said, if you do try to kind of move more towards that waterfall model of, ‘hey, let’s just build it and then close our eyes and hope everything works out and never cheque in with stakeholders ‘—there’s a lot of problems that come up with that one. You almost will never hit the mark with the workflow, no matter how good your requirements gathering is. But number two, you also lose a lot of stakeholder involvement, right? Solution design really sounds like it’s obviously, you know, 90 percent of the work is on the solution design team, but the stakeholders still, like the rest of this process, has a huge, huge impact on this in terms of, hey, is he still bought into the process and what this looks like? Is he investigating and asking questions out in the field for the actual process? And how can we make things better as we continue to go along? So, a lot of different kind of aspects of, you know, their involvement, balancing that with who they are, you know, how comfortable they are with this process, and how much time they have.
RA: Yeah, stakeholders are key. They got full time jobs. They’re out oftentimes either in office, out on a job site, in your case. You know, they’re managing people and they’re trusting your work and that you’re behind the scenes doing what you need to do.
To segue a little bit. Geoff, I know that you have some experience building out workflows. You’re taking this solution design and delivering a product. I guess, how do you make sure the workflows that you’re building for customers are meeting the intent of the solution design itself?
GW: Yeah, great question. I start by trying to have a good solution design, as we talked last time. But in some cases, you know, you get what you get or you get a list of requirements maybe scribbled down on a napkin and say, hey, figure out how we can make this happen. And so usually try to come up with that minimal viable product that Nate had mentioned before. Something that captures without a ton of effort, what the intent of the workflow is. Hey, we saw it as this in the solution design, you know, and sometimes that’s written by someone who doesn’t totally understand the features and functionality of what we’re capable of doing. And then start to iterate and get some feedback as quick as possible as we’re iterating through turning that solution design into an actual deliverable. As that iteration is happening and that instant feedback is there and that changes things, there may be more or less requirements that end up showing up, but getting that involvement from the end user, from the customer, as soon as possible and making it a collaborative experience seems to work better than waiting until the end and realising that while you delivered on the solution design, that may have missed the mark on what the customer was expecting.
And I’ve seen that happen outside of electronic workflows or things like this. But even in implementing physical changes to like a factory floor where when the inputs of what we want weren’t very clear, we said we wanted to achieve change. We changed things, but we didn’t quite meet that direction. And had we checked in sooner, had some defined, you know, points where we could evaluate the work we were doing and getting that feedback, we could have changed course a lot earlier and saved a lot of time, effort, and energy.
RA: That’s a really good point. And again, this isn’t just for construction. This is for all different types of businesses, all different types of industries, anybody that cares about, you know, transforming their business.
JD, I guess one final question as we wrap up the day. What points of encouragement would you give to somebody that’s maybe just starting out or maybe they’re in this very step? Maybe they’re struggling with implementation. From a leadership perspective, how are you encouraging the teams that are building these things out in case they do run into roadblocks?
JDM: Well, it’s really easy to say very cliche things like don’t give up. If you go listen to the previous podcast, you have an idaea that’s going to help your company, you think it’s going to add some value, you’ve designed it—we talked about last podcast like, okay, you designed it. It had some flaws. Let’s go reconfigure it and get it going. When you start to see a little bit of success, build on it, celebrate it, talk about it. You get other people excited about it, you get them on board, you build some momentum that way. And during this entire process, even though you or the individual working on these aren’t the best at it right now, you’re going to gain experience over time. I wasn’t very good at it at first, arguably still not, so I have smarter people than me like Nate do stuff. But Nate and I’ve learnt a ton. We have a team of people working on our stuff for Corbins and they’re learning.
Here’s one thing I’d like to put in perspective. We talk about this on the construction site also. It applies to this. A lot of contractors or just a lot of companies want to use the skills and experience of their people to build projects, whether it’s a construction project or an automated workflow project. We like to flip that on its head. We want to use our projects to build the skills and experience of our people because that builds on itself. Now you have people with more skills, more experience to help build other projects. And our projects are going to get more complicated, as Corbins’ projects have, with mobile workflows, more complicated, more involved. So, we’re just building on that on both sides. And anyway, I just want to keep that in perspective a little bit.
RA: Yeah. That’s great. Are you guys approachable? If our listeners want to reach out to you, what’s a good way to get in contact with you, JD, at Corbins Electric?
JDM: Yeah, you could find me on LinkedIn or just email me, jd.martin@corbinselectric.com.
RA: Okay. And Nate, same. Google search NOX Innovations? I know you guys got a pretty amazing website up. Can people reach you? Are you easy to get a hold of?
NU: Yeah. As JD said, I think LinkedIn is probably the easiest way to kind of reach out and start that dialogue. So, I would say LinkedIn.
RA: Well, I think it’s a good pause point for today. Thank you so much to the guests. JD, Nate, Geoff, really appreciate your insights, your inputs. We’re going to be building, expanding on these ideas, so stay tuned into future episodes.
Be sure to check out all the latest podcasts from across Hexagon at hxgnspotlight.com or on SoundCloud Podcasts and Spotify. And thanks for tuning in.
