By Sarah Nicastro, Creator, Future of Field Service
We know that the advancements in capabilities, sophistication, and usability of today’s field service software solutions are impressive. But we also know that, regardless of the strength of software selected, there are many opportunities for projects to go awry during implementation that have little to do with the software itself. Despite the best of intentions, companies can find themselves in a quandary during deployment.
Recently Katie Hunt, Service Operations Leader at APi Group, joined us on the Future of Field Service podcast for a discussion fresh off of the company’s software upgrade. If you’re not familiar, APi Group is a business services provider of safety, specialty, and industrial services in over 200 locations with more than 15,000 employees worldwide. Katie led the team on the software upgrade and, having just wrapped, had some really insightful best practices and lessons learned to share.
Best Practice #1: Know Your Why
Katie’s first piece of advice is to have a clear vision for the project. “Identifying your 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,” she says.
APi Group’s most recent software deployment was an upgrade of its Alliance solution for which the company’s initiatives were to standardize processes, move to a hosted environment, and to set the groundwork for scaling the business. “Being clear on your goals allows you to 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,” says Katie. “It is 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 team’s 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.”
Best Practice #2: Define Your Project Team
During your project, it’s critical to obtain input and feedback – but it’s also critical to ensure that the responsibility of driving the project forward is clearly defined. “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 a unique structure with a service steering committee, where we had one representative from each company,” explains Katie. “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 and move forward. It really took the ownership off of APi Group and put that on the companies to drive this change forward, which big success overall.”
On the other hand, APi Group learned it could have benefitted from a dedicated project manager and some additional resources. “We had the core team, which was very lean, including myself and about four other key team members,” says Katie. “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.”
Best Practice #3: Develop Guiding Principles
As your project hits the inevitable ebbs and flows, and rest assured it will, you need to know exactly what to stay focused on. To this end, Katie suggests developing guiding principles. “We defined four guiding principles. The first one 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,” says Katie. “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. The third one was leveraging the ideas and suggestions of the service steering committee, which we've already discussed, which worked very well. And then the last one was valuing time over process changes. What we were saying with this is, our go live date needs to be met, despite all the process changes being fully complete.”
Having these guiding principles in place at the start is important to keep clear on what you’ve defined as most important, because competing priorities are sure to arise. Your defining principles don’t negate additional priorities or opportunities from being incorporated but ensure that you stay focused first on achieving the principles you’d set. “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,” explains Katie. “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.”
Best Practice #4: Testing, Testing, Testing
Katie explains that there’s truly never enough time to test enough and success is a balance of ensuring you’ve done enough, in a variety of manners, to feel confident without holding up forward progress. “Testing: we love it and we hate it because there's never enough time for testing and there's so many different methods of testing. And it's just so crucial,” says Katie. “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. It’s important to have a really, really solid plan for testing. 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 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 notes the importance of not just testing but rehearsing. “Rehearse like you want to actually execute. It's like a military thing. I would say that's one thing that we did well, especially with rehearsing the actual cut-over, but also with testing,” she explains. “One thing that I would suggest that had been used at APi Group before I was on board was the testing matrix and really holding the companies accountable for 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.”
Best Practice #5: Provide Ample and Effective Training
When Katie and I outlined our podcast discussion, I was quick to group training in with change management – and Katie was sure to point out that it is absolutely important to stand on its own. “I’m very proud of how our team handled training. We created videos within our LMS system with APi Group. We kept them short, no more than five minutes, because the 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,” describes Katie.
So APi ensured there were a variety of formats of tangible resources, but also prioritized live trainings and encouraged interaction. “We had weekly live stream 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 through chat,” explains Katie. “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.”
Best Practice #6: Don’t Skimp on Change Management
If there’s one thing I’ve learned in my years of covering this space, it is that software projects often fail due to the tendency to de-prioritize or under focus on the criticality of change management. “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,” agrees Katie. “This is definitely something we did not want to lose focus on. And we did have times where we slipped; everyone does.”
One critical aspect is ensuring that your stakeholders feel invested and take ownership, and this is accomplished through early and often communication, explaining the “why” and how the change will benefit them, and allowing time and opportunity for feedback. “Our strategy overall was not to push this on the companies, but to 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,” says Katie. “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. We 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; 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. 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.”
Best Practice #7: Set KPIs to Measure Progress and Success
You won’t know how far you’ve come if you don’t know where you started. “This is one thing we definitely could have done better, and I think it circles back to our team structure with 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,” explains Katie. “The downstream effect of that was that 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, 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 o- budget, which is what most people focus on. We could have been more granular and had more holistic KPIs and to do that I think it is important to make sure that you have somebody dedicated to that aspect of the project.”