Katie Hunt, Service Operations Leader at APi Group, shares with Sarah insights gleaned and lessons learned during the company’s recent field service software upgrade.
Sarah Nicastro: Welcome to the Future of Field Service Podcast. I'm your host, Sarah Nicastro. Today, we are going to be talking to you about seven keys to software upgrade success. If you have ever been in the midst of a software upgrade project, you know that it is no easy feat, and there are plenty of lessons to be learned along the way.
I'm excited to welcome today Katie Hunt, service operations leader at APi Group. Katie, welcome to the Future of Field Service Podcast.
Katie Hunt: Thanks. It's great to be here.
Sarah Nicastro: So before we dig into these seven keys to success, which I'm excited to share, tell us a little bit about APi Group and your role. And I know that this is a topic that is very fresh for you because you had just come off of a major project. So fill us in.
Katie Hunt: Yes. So I'll start with APi Group. APi Group is a family of companies that provides business solutions for safety, specialty, and industrial services. We have over 15,000 employees and are in 200 locations in the US, Canada, the UK. And what's really unique is that our purpose is building great leaders, which for a construction company is sometimes looked on as unique. And so while we focus on that project delivery and great customer service, we also want to grow our individuals, grow our teams ,and make sure we can share knowledge, best practices, and just push each other to the next level.
Katie Hunt: So myself, I joined APi Group after going through the leader development program. I joined after I was in the military, and that was just a very unique opportunity to learn the industry and kind of develop some skills there. And I had the opportunity to join an operating company and then lead this project, which eventually led to leading the full-time service operations team at APi group.
Sarah Nicastro: Awesome. So you are fresh, very fresh off of a major upgrade of your Alliance service software platform. So, I've talked with you a few times along the way, and I think it's an excellent opportunity to share these seven keys or seven lessons today because it did just happen. So inevitably, you go through a big project like this, and you learn some lessons along the way, but time just kind of washes them away and kind of just makes them not so clear in your mind. So I'm excited to talk about seven aspects that you have uncovered that you feel are particularly critical to having a smooth upgrade and to having a successful project.
Sarah Nicastro: So the first key or the first tip is to be clear on your why. So explain what this means and why it is so important.
Katie Hunt: So ultimately, I would say that the why equates to the vision of a project. Identifying the why is so important because it not only lets stakeholders know why we're doing this project, but then it also serves as a benchmark for project efforts. So you can avoid that scope creep, and you can make sure you're staying on task. So once you create that vision, like we did, of standardizing processes, moving to a hosted environment for those benefits, or just setting the groundwork so that you can truly scale your business, you can then communicate effectively throughout the organization and really just maintain that focus and discipline and ultimately compare all of those decisions back to that strategic vision and keep the project on track.
Katie Hunt: I also wanted to call out, it's so important to know that the whys might be different for different cohort groups. We have a very large organization, and when I'm communicating, and my teams communicating to executives, it's a different message sometimes than the end user or the branch level professionals, which is fine. But ultimately, they all need to tie back to that strategic vision, so that they're all in alignment.
Sarah Nicastro: Okay. That makes sense. So, tell us a bit about APi Group's whys with the recent upgrade. So what were the major strategic drivers that kind of led you through this project?
Katie Hunt: Sure. So APi Group was recently acquired and by J2, and we've now become a public company, in that one of the main driving factors for that purchase, and it's been mentioned by their leadership, is just our ability to perform a service and inspection operations because it's that reoccurring revenue, as we all know through hard times lately. And it's just very important. And so they are really pushing us to grow and scale that side of our business. And as such, we have over 20 companies that conduct service work, along with all the subsidiary companies. And a key factor of that is standardizing processes. So getting everyone on the same system, that was one of our key factors.
Katie Hunt: And another one was simply starting this movement to a hosted environment, to have that higher-level support, greater performance and stability, and really just setting the stage to grow the business and move to that next level.
Sarah Nicastro: Perfect. Okay. So you have these pillars that are leading you through the project, and you need to, as you said, have these in place, so that as things ramp up, as things get stressful, as things get hectic, as opportunities arise to kind of go off path, you can stay focused on what it is that you have set out to achieve. So that's the first key.
Sarah Nicastro: The second is defining the team that will be responsible for leading the project. So tell us what you learned here, in terms of this point.
Katie Hunt: Right. So this project was unique, in that we really relied on the operating companies to provide insight and guidance and decision making across the board. We had the core team, which was very lean, including myself and about four other key team members, but we did learn that we could have used a couple more people, not only a dedicated project manager to delineate the project management from business decisions, but also just having an extra set of eyes for different perspective. So that was a lesson learned.
Katie Hunt: But one thing I think we did extremely well was rely on the operating companies to provide feedback. We had a unique structure with a service steering committee, where we had one representative from each company. They came together, and they really made the agreement upfront that this would be the decision making body. Even if everybody didn't agree, we would move forward with the decision of that committee, so that we could standardize processes. And so although we had great discussions and sometimes people didn't agree, we were able to make those decisions, move forward. And it really took the ownership off of APi Group to push this initiative, and it put that on the companies to drive this change forward, which was phenomenal for our team and just a big success overall. So we definitely recommended that for future projects.
Sarah Nicastro: Yeah. I think that's a really good point because if you're going to have issues up for discussion or perhaps discrepancies in opinion, all of those things, if you're doing it by committee, it gives the sense of being far more fair. So if you handle those things on a case by case basis, it's easier to have someone be upset about decision that was made. Whereas if it's just an understanding of we're going to discuss, we're going to vote by committee, and whatever the outcome is, the outcome is, that would alleviate a lot of frustration, I would imagine.
Katie Hunt: Right. And I think it gets buy-in, too, from the committee.
Sarah Nicastro: Yeah, absolutely. All right. So number three, key number three is to develop guiding principles, so that as the inevitable ebbs and flows of the project occur, you know exactly what to stay focused on. So, tell us about what APi's guiding principles were, and if you have any examples of kind of how and when they came into play.
Katie Hunt: Sure. We had four that we outlined. We actually did a full vision with guiding principles, some goals, and that kind of thing, just so everyone was aligned. And the first one that we focused on was maintaining focus on end user needs. We didn't want to have a holistic technology solution that didn't meet what the end user needs from the field professionals to those office leaders that are really the ones executing the work.
Katie Hunt: Our second one was being open to changing processes. Change is hard, but we know that we all agreed, hey, we might have to change our processes. We're doing this for the betterment of the group. And that was just an agreement up front.
Katie Hunt: The third one was leveraging the ideas and suggestions of the service steering committee, which we've already discussed, which worked very well.
Katie Hunt: And then the last one was valuing time over process changes. And this one was a little bit unique that I'll expand on because we really, when we were conducting the project, had a couple constraints, including time, the scope of work, and the budget. And what we were saying with this is, our go live date needs to be met, despite all the process changes being fully complete.
Katie Hunt: And so an example of that was where, as we grew closer to go live, we had a list of items that had not yet been implemented. And we prioritized, made sure we hit those really key items, brought them forward before go live. And we're still working in sprints after go live, to continue to refine the system. So we wanted to view go live not as a stopping point, but really as something we could continue and use as a springboard to keep developing our processes, systems, et cetera.
Sarah Nicastro: Okay. So these four guiding principles are what really kept you focused on those four aspects that you felt were most important for the success of the project. Do you have any other examples of... Within the project, where one of these came into play and kind of steered you back on track, if you will?
Katie Hunt: Yes. So one good example, I would say, is the focus on the end user need. It's very easy when you see the bright, shiny object, and you want to go make this cool change, but then during the actual testing and training, the end user gives us feedback that, hey, this is really not what we want. And so what we really tried to do is, during our testing and training, we utilized a Microsoft team session and page, and it was open forum session. Anyone can provide feedback. We documented everything, to make sure that they had feedback. They were heard. I think at one point we had 480 responses or something.
Katie Hunt: But you're just going through these and really trying to make sure that the end user knows that, one, they could speak up. There was no ramifications. They were being listened to. And then we understood that their needs were very high priority. So we had to take a step back a couple of times on some enhancements we thought would be beneficial and really look at it from their perspective. And so we did that as much as possible.
Sarah Nicastro: That makes sense. And I think what you said is a really good point of not only for the project team, but for everyone involved, to make sure it's communicated to look at the go live as just the starting point. So that people understand if there's feedback they've given that can't make it for that go live cutoff, it doesn't mean you're not listening, and it doesn't mean that it's not going to get incorporated. That there's going to be opportunities to continue to evolve what you're doing, but being able to use those principles to keep you on track with not just continuing to brainstorm and never actually getting the result out. That makes sense.
Sarah Nicastro: Okay. So key number four is the importance of testing. So talk to us about all things testing.
Katie Hunt: Oh, goodness. Okay. So testing, we love it and we hate it because there's never enough time for testing, but there's so many different methods of testing. And it's just so crucial. I would say one thing I learned that I did not know going into this project, was how many different methods and different types of testing you could do, from the load testing to the off-road testing, to the scripted testing, to automated, there's just a whole gamut of how you can test the system.
Katie Hunt: And I think going into it, one, just having a really, really solid plan. Before I came on board, the team already had an excellent script of testing items and what we needed to do. So we had a really good baseline that we could springboard off of and really develop and test. And then we just wanted to make sure that we put the system through the paces and tested as if we were conducting real-world operations.
Katie Hunt: And that was the key thing, was rehearse like you want to actually execute. And it's like a military thing, I've learned, you want to rehearse, rehearse, rehearse. So I would say that's one thing that we did well, especially with rehearsing the actual cut-over, but also with testing.
Katie Hunt: One thing that I would suggest that had been used at APi Group before I was on board was the testing matrix and really just holding the companies accountable and checking in and asking the question of not only who has tested, but when and what. Because if you have a whole group that focuses just on one end of the testing and you miss the portion where you need to invoice the work order, rather than just create it, you have a gap in the testing. So by spreading it out and having the end users do the testing and staggering it correctly, I think it's very, very beneficial. And that's one of the most crucial phases that we possibly could have gone through.
Sarah Nicastro: Okay. So you said at the beginning of this question, there's never enough time for testing. Okay. So that makes me wonder, how do you strike the right balance of testing enough without, again, holding yourself back from ever crossing the finish line?
Katie Hunt: So this goes back to our initial constraint of time, that being just a key factor. We almost had a point where we were testing and continuing some configuration and development at the same time. So this is a lesson learned for us, is making sure that you have the schedule outlined, where you have the users in the system soon enough to catch any bugs or issues or concerns, but having them in late enough so the development is done, so they can have a good testing experience.
Katie Hunt: So really, I think we did a really good job of having a test phase and then almost a recovery phase to address those issues, and then have a second testing cycle. But one thing I would say that we could have probably done a little bit better job on is clearly annotating, during those testing cycles, specific items to test as well as specific items not to test that were still in development. And that way, it's just very clear. But at some point you have to go live, and I think it's one of those things, it's a judgment call of what are priority one items, what are priority two, and what can we live without until after go live. And that depends on the company and system.
Sarah Nicastro: Right. That makes sense. Okay, good. All right. So key number five is providing ample and effective training. So tell us how you tackled training and any advice you have for folks here.
Katie Hunt: Okay. So I will say training is one item, I am extremely proud of our team on this. We receive some very positive feedback, and we're continuing to use some of these items as we move forward. We really tackled it by... We created videos within our LMS system with APi Group. And we kept them short, no more than five minutes, because attention span of most people is not more than that when watching the training videos. And then we also made cheat sheets. We made quick reference guides that folks can print off on a one pager for key topics, put it in a little folder, or guys can throw it in their trucks, as they're out on site, and just references as needed. And then lastly, we did make those user manuals that are very in depth. They have screenshots, they answer those tough questions, deep dive, and really, people can search them and use the PDF and that kind of thing if needed.
Katie Hunt: The other item we did is we had weekly live trainings. This was a suggestion by one of our steering committee members, and we essentially dedicated a topic each week, and we opened it up on teams where people could just ask questions. They chatted questions. We had the live stream. And basically, we had really good participation. I think week after week, about 150 people would log in, ask questions, and share ideas. And I think having that service community through our team's page has just been a really good benefit, but we are going to continue to take those trainings and use them for onboarding new users and then refine them, probably quarterly as we move forward, just as a continued resource. Okay.
Sarah Nicastro: So when you're doing these trainings through the teams page, and you're having these interactions, are you able to capture... Obviously, you had your testing phase, and you captured feedback, and then you incorporated it into the system. As you're training, so obviously this wouldn't be feedback that isn't necessary for go live by any means, but as you are training folks, and there's something that they think of that's just a good idea, so it's something that maybe you didn't think of during the critical phase of the project, but now that it's out, it makes sense to incorporate, are you capturing those insights and able to have access to that information and decide how and what to work on?
Katie Hunt: Yes. So we did push the training ownership on the companies. That's one thing I failed to mention is that, although we're developing all these resources and the weekly trainings, we are asking the companies to do that as well. But in that, if they were to find something that they wanted to add, let's say a change request or something that's a configuration change, we are essentially conducting two weeks sprints, and we're still ongoing in that phase right now, where they can submit that request through our ticketing system or on teams and let us know that they think they want this idea, provide the justification. And then what our team can do is test it out, research it, run it by the steering committee still. And if we think it's something we want to implement, then we will bundle that together in our bulk migration of code every two weeks or three weeks, as those changes become ready.
Sarah Nicastro: Okay. That makes sense. Okay. So key number six, one of my favorites, is prioritizing the need to manage change. So I think when you and I initially talked about doing this podcast, I maybe suggested putting training and change management together, and you very rightly said, "No, no, no, those are two totally different things." And you're right. You're right. That's actually a representation of, I think, some of the mistakes that often gets made in the industry, is this tendency to kind of de-prioritize or under focus on the criticality of change management.
Sarah Nicastro: So tell us, from your perspective, why it is so important and what your experience was, what you think you did well, what you would maybe do differently, how you tackled this.
Katie Hunt: Sure. So, the first thing is, change is never easy. And I really think, even though this is a very intangible part of the project, it's one of the most important, just because it often gets pushed to the side when the budget gets tight, or you're short on time, and you don't have time to effectively communicate. So I would just encourage, this is definitely something we did not want to lose focus on. And we did have times where we slipped. Everyone does. But at the same time, I think we did a pretty good job of circling back and making sure that we communicated this effectively.
Katie Hunt: Our strategy overall was not to push this on the companies, but to really have the companies take ownership. We are 100% there to support, assist developing these training tools, develop the testing, outline the plan. But for a three person, four person team, it's not feasible to train and really manage that change for 20 companies, 3000 users. It's just not feasible. I don't have enough hours in the day for that.
Katie Hunt: But so really, we pushed the ownership on the companies, but we did everything in our power to explain the why behind these changes. And if they had pushback, if they had feedback, we would listen. And there were times where we didn't make a change, or we've switched the processes, but we did that in a standardized manner to make sure that everyone was in alignment. And so really, I think we just constantly tried to solicit feedback, really tried to over-communicate whenever possible, and focus on what I think is the most important resource of the project, is the people. No matter the technology, no matter the system, if the people don't support it, and the people don't understand why, and they aren't getting what they need to conduct their work and be successful, the project's ultimately going to fail. So we didn't want to lose focus on the people. We wanted to maintain communication and really just make sure that people understood the why of the changes and how it helped them personally, not just the company overall.
Sarah Nicastro: Right. That makes sense. I'm curious, you said there was a couple of times you slipped, and everyone does. I don't know if it's too much to ask. Is there an example you can share? I just think it would be helpful for someone to hear, in reality, what that looks like and how you circled back to kind of work on something that is an inevitable. No one's perfect. So you're not always going... No matter how critical you know it is, you're not always going to do things perfectly.
Katie Hunt: Sure. I think one of the best examples, especially during testing, when it's very high paced, and especially how we manage the reporting of different questions, issues, process changes, et cetera, it was fast and furious on teams with people reporting, emailing, calling, having so much feedback. And we were trying so hard to document everything and capture it and respond and execute. And I think sometimes, I know me personally, I would get caught up responding to tickets and responding and solutioning the symptoms and making sure we got these tickets closed, rather than looking at the root cause of why someone is asking this question. Is it a lack of understanding of training, or is it maybe the process isn't correct, or the system does have a bug. And so really just taking a step back, kind of soliciting some advice from our core team and then the steering committee and say, "Hey, can you guys test this out? Am I off base here?"
Katie Hunt: And really, it takes time, and it's harder than just responding to tickets or responding to people with the first answer you can come up with. But I think in the long run, knowing that we're taking the time to really deep dive into these issues and find a good solution and good process change helps in the long run, rather than just that quick, "Oh, we got your ticket closed. You're good to go." So, it is hard and it does take time, but I think as long as we circled back to maintaining the focus on the why and the people, it worked out.
Sarah Nicastro: Yeah, no, that is a really good example because you're going fast, you're in problem solving mode.
Katie Hunt: Exactly.
Sarah Nicastro: So you get this issue, and it's like, great. I can fix this. Boom. Without thinking, I wonder why they're asking this question. Maybe they don't totally get this part of the objective or what have you. I think that's a really good point.
Sarah Nicastro: And it sounds like... I tend to think one of the most important aspects of change management is making sure people feel heard. And there's a difference between people feeling heard, and you always agreeing or acting on feedback. So they're not the same thing. You can let people know that they're heard and that you value their input, even if you're not using it.
Sarah Nicastro: And so I think that it's important to understand that because I remember one of the companies, I'm not going to remember which company it was, but a number of years ago, we were talking about change management, and they said every single piece of feedback, they made sure it got followed up on. If they had a meeting, they would write it all down. And even if that was saying, thanks for your idea, but we didn't use it. But they still wanted people to know that they were listening, so that they would continue giving that feedback and stay engaged and feel a part of the process. So good stuff.
Sarah Nicastro: Okay. So our final key, number seven, is to set KPIs from which to measure progress and determine the project success. So talk with us about KPIs.
Katie Hunt: So I would say this is one thing we definitely could have done better. And I think it circles back to our team structure. And that was just an aspect of, we had individuals filling multiple roles. We had one individual that was the project manager, as well as the business process lead. So they're not only managing logistics, resourcing, budget, but they're also doing the process analysis, business decisions, and architecture. And having that, something's going to slip through the cracks. So I think that was a lack that we've identified for future projects.
Katie Hunt: And what the downstream effect of that was, is we did not really have project KPIs. Our BI and metrics team has done a phenomenal job of creating operational performance metrics. But in terms of the actual project itself and key milestones, making sure vendors are on track, making sure our other work streams are on track, that the operating companies... I think we could have done a better job measuring those milestones and KPIs and actually having other KPIs rather than just on time and on budget, which is what most people focus on. We could have been more granular and had more holistic KPIs.
Katie Hunt: But I think it's very important because it really keeps that project on track, in scope, on budget, and on time. And so I don't have much on this topic because it is an area we can improve, but I would say it's important just to make sure that you have somebody dedicated to that aspect of the project.
Sarah Nicastro: Yeah, that makes sense. Okay, Katie, I have two bonus questions for you.
Katie Hunt: Oh, gosh.
Sarah Nicastro: So the first is I know you come from a military background, and I'm curious what military learning you found to be most helpful for you within this process. So what's something from that part of your history that proved to be very useful in this project?
Katie Hunt: So I would say that one of the biggest one is rehearsals. Before any mission, any military exercise, anything, you always rehearse. You run through the motions until you can't forget them. And specifically with this project, the cut-over and that cut-over weekend, we rehearsed, I think it ended up being four times, and the original scope had only one rehearsal. And so we added those on, simply because it wasn't right when we did it the first time, and we kept doing until we got as close to go live as possible.
Katie Hunt: I think also just testing the capabilities and making sure you put both the people and the systems through their paces. Similar to rehearsals, you want to push those things to the limit when you're practicing, so that when you're actually executing and lives are on the line, you can execute how you need to. So I would say those are the big ones. That's a tough question. There's so many things I learned in the military. It's hard to kind of go through them all.
Sarah Nicastro: I bet. Okay. Last question is... I know this was a different experience for you. It was a new challenge for you in your career. What do you feel you, as an individual, what was the biggest lesson you as a person learned throughout this project?
Katie Hunt: I've actually had this conversation with my team a little bit, and really, it goes back to your point of listening to everyone's feedback. But ultimately, it's okay to say no, and it's okay to push back a little bit and make sure that you look at all the perspectives, you hear everyone's input, but ultimately, you can say no, and you can push back a little bit, in terms of what your final decision is. And you're never going to make everyone happy. I think with a project this large, that was a tough lesson because I love for everyone to get along and work well together and collaborate. And there were people upset at different points in the project. And it's not personal. It's really just what's best for the business and what's best for the organization overall. But yeah, just it's been a challenging experience, but at the same time it's been pretty rewarding. And I would just say the people I've gotten to work with and the team has been phenomenal. So I'm just grateful for all their work that they've put in.
Sarah Nicastro: That's really cool. I think it's awesome. I'm sure it's been challenging, but it is always rewarding to push yourself out of your comfort zone, and to really do different things and learn different things. So I'm really excited for you. I really appreciate you joining us today and sharing these seven keys to success, and I look forward to connecting again soon.
Katie Hunt: Well, thank you very much for your time. I appreciate you having me on.
Sarah Nicastro: Thanks, Katie. You can check out more of our content by visiting us at futureoffieldservice.com. You can also find us on LinkedIn as well as Twitter at the Future of FS. The Future of Field Service Podcast is published in partnership with IFS. You can learn more about IFS Service Management by visiting www.ifs.com. As always, thanks for listening.