Scott Rutherford:
David Kaiser, thanks for being here.

David Kaiser:
Yeah, thank you for having me. I always enjoy our conversations.

Scott Rutherford:
We're going to explore systems rollouts today. I was hoping for the general audience we could try to just explore, well, what are we talking about with the systems rollout? I'll name drop a little bit. People have heard of Oracle or Salesforce or Sage, but when you talk about a system rollout, what are we talking about within a company?

David Kaiser:
Well, it's essentially when a particular company is either consolidating various parts of their business onto one single system. It's essentially when they're upgrading into a new system. A lot of companies that we've seen over the years, they'll grow through acquisition, and when those acquired pieces come into play, they're coming in with different systems and different processes. And so they'll take a big moment to actually get everybody on the same system and therefore the same process. That helps downstream with high-level reporting. If they have any system-wide changes they want to push down, they can do that across the company because everyone's on the same platform using the same process.

Scott Rutherford:
Right. So we talk in business about people and processes, and it sounds like this—there's a technology piece of this which is the foundation. But what we're going to be talking about today is really the people and the processes around that. Help us understand why those pieces are critical to the success of the technology launch.

David Kaiser:
Everyone's really familiar with project management. We use it just putting together a grocery list and feeding your family throughout the whole week. We've all been pulled into projects on “other duties as assigned” throughout our roles. And so there's a lot of clarity in that, and that is essentially the what and the how. So what are we going to be doing? How are we going to get it done?

That bit that's more than the technical piece that makes projects really successful is the change management side of things. And that really, if you boil that down in the simplest terms, is the who and the why. So who will be doing the work, who will be transitioning that work, and why do they actually care about doing that? Why is this important to the company as a whole?

Scott Rutherford:
So let's dig into this using the example. You've worked on multiple projects like this, but you just finished recently a large Fortune 500 healthcare industry company going through a large platform migration. Tell us about that rollout. What was it, and what were the challenges?

David Kaiser:
Yes, so I've been working on system implementations all the way back to 2008, and then with Axiom this was actually my third system implementation project. Just prior to this was on a very similar company in size and industry. And so we've had a few—we’ve had a really good run over the last couple of years with some really robust projects working on some major system implementations.

On this particular client that we just wrapped up a couple months ago, this was that example of where you had a company that had grown through acquisition. And so they had different large pieces of the company on different systems and therefore different processes. It gets really hard to report across. It gets really hard to make big system-wide changes. And so they were standardizing all of their core processes onto a standard suite of several different systems.

Scott Rutherford:
So in that hypothetical, the company has identified the need for a change. They've already started down the path of identifying their solution. At what point did you enter into the project and how did you approach onboarding yourself and developing a scope of work?

David Kaiser:
Yeah, so with these larger companies, these projects take multiple years. So where we came into this was actually just before the rollout of the systems themselves. They had been in preparation, working with subject matter experts and the teams in operations to actually get the alignment, build out the systems. Some systems were completely new, some parts of the business were standardizing to an existing system. And so there had been several years of work already in play for that.

Where we came in as learning consultants was in the rollout of that system. We came in several months prior. We had to learn the systems, kind of understand what was going into them. We had to get ready to actually be able to train them. And with large companies like this, they'll do this in a phased rollout where they'll take one piece of the business at a time and roll out those systems. So you'll still have one foot in the old ways and one foot in the new ways. And then methodically we’re working across all parts of the business to get everybody onto the same system setup.

Scott Rutherford:
Right. So what did that look like? If you give me an example maybe of one of the—was it tailored by function or group? Or an example of how you approached supporting a learner or user population there.

David Kaiser:
Well, so it's normally by function because the systems themselves handle a particular function. So you'll have a billing system, you'll have an accounting system. This particular client was in healthcare, and so you'll have all the healthcare records on a particular system. Depending on which end user is using it, you'll have a different profile.

So someone working in the call center will need access to a certain set of systems so they can answer those phone calls. Someone working in billing is probably going to need to have deeper access into the accounting systems and also, let's say, the claims system so they can understand and troubleshoot issues that they deal with day to day.

So there's essentially a matrix that's put together based on the different roles and what they need—what information they need to know—so that they understand what access they need to which systems. Let me say that the other way around—they'll need to know which systems they need access to and what level of access they need in their security profile. So there's a whole matrix that's put together and that then drives the training plan for them.

Scott Rutherford:
Right. That would also drive the measure of success too, because you're identifying, okay, what do they need to be able to do? How do they have the understanding to be able to do what they need to do? But also measuring—after they've gotten hands on for a bit—are they actually able to do it? So how do you establish objectives for the behaviors that you want to see?

David Kaiser:
Well, this particular client, they're very good. They're very good on a lot of different levels on this. For this particular question, after every single training program, they would assess that and then they would actually go back later on and assess them again.

They also had a really robust change program so that if we encountered anything during the training and the rollout, we would get that feedback. And especially as trainers, we're the ones speaking to everybody, all the way down to the end user. And so we would get that feedback often, and we could feed that into a change document so that we could see the change. If the change needed to happen at the system level, it would get communicated there. If the change needed to happen in what we were teaching, it could happen quickly. And so they were very quick to respond, and they had really good processes in place to do so.

Scott Rutherford:
Yeah. So that rapid response and that agility—we talk about that as being a benefit to projects overall. But in a complex one, where you need to correct before a wrong direction gets cast in stone, that's particularly important. What other learnings would you share from this example, this particular launch? What did they do well that others can take and apply to their own projects?

David Kaiser:
I think the agility piece that you mentioned—this showed up in several different places. I mentioned earlier about the system changes. They took the opportunity to centralize all of their documentation into a central receptacle. So instead of having it in file cabinets and shared folders and developed by the teams themselves, they had a central team that would develop all of your QRGs and your walkthroughs. And so if something changed in the system, that team was actually engaged as part of the project plan for that change. So what you had was a standard receptacle for all these materials and quick updates.

Scott Rutherford:
Kind of a rapid response then, if not real time.

David Kaiser:
Yes, they are. I mean, they were much faster than anything I've seen. And then, when you go to that standard receptacle, you know that you're always pulling the most recent version of that document, which is version control—one of the biggest pitfalls that you run into with any kind of documentation.

Scott Rutherford:
So thinking about, again, this is a large systems implementation. These tend to be owned by people in IT, people in operations. HR tends not to own these. But what we're talking about here is the importance of getting alignment between the people side of the business and the ops technical side of the business. So if you're listening to this and if you're in the seat as the skills person, the human skills person, what could someone in that role do to make sure that they're part of the process and helping to support the successful launch?

David Kaiser:
So now we're getting into the change piece—the who and the why. The first place you would start with this is aligning business objectives. You could go all the way back to just the mission and the vision of the company and then work from there.

For something like an insurance company, they're very focused on what their client experience is—do they feel like they're being served? It's a very passionate business. And so by implementing new systems, you get better information, better engagements with that client. And so people feel better about working that way. That industry already attracts people that really care, and it helps them serve that.

If you connect this whole rollout to the why—why we want to serve our clients better and why we truly care about that—what that does is it gives people license to add more value, add more ideas. It makes them more resilient to change. A lot of times when you're coming in with the system implementation, somebody may have been working in the system for years and they're a subject matter expert in that system. And so it can be disempowering sometimes to have to learn a new system because it kind of resets the playing field. That change can be hard. By aligning it to something bigger than ourselves, but something that we all value within that company, people can really step up and they're motivated by something bigger than themselves.

Scott Rutherford:
Right. And that’s a very different way to approach change management—understanding people’s motivation. The default, and I’ll be a little crass here, is to say, “Okay, it’s a new system, you get on or get out.” Which I’d be lying if I said that doesn’t happen sometimes. But that’s relying on a whole different type of—well, I’ll put “motivation” in air quotes—but it’s a different way to try to leverage behavior. What you’re talking about is much more intrinsic motivation, right?

David Kaiser:
That’s right, yeah. That’s the exact term I always use—extrinsic versus intrinsic motivation. Extrinsic motivation is what gets people through the door: what you pay them, the benefits that come along. Intrinsic motivation is about prestige—it’s a really big motivator—and the question, “Is what I’m doing important?”

You know, I mentioned earlier, you have a really passionate workforce that works in insurance. Helping others is an intrinsic motivator, but also creativity and opportunity, autonomy—all these things where you can actually do meaningful work. That’s a fantastic way to motivate.

If you have somebody that is looking for more opportunity, that wants to try something new, they come up with a lot of good ideas. They’re really great people to add to projects like this, because at some point something will go wrong. These are the type of people who don’t get flustered by that. They step up and say, “Okay, how are we going to fix this?”

Scott Rutherford:
Right. And that’s—when we were talking in prep for this podcast—we talked a little about enablement versus pushing, right? And that’s kind of where we are here. So talk me through the difference it can make when you have people who are aligned with the mission working within the project to help push it forward. What does that look like in practice, and how does that change the result and the outcome?

David Kaiser:
Well, thinking about it from a leadership perspective, one thing that happens with every single client I’ve had is at some point you have so much on the line—both personally and professionally, but also for the company and for the client. When you’re doing this transition, it’s a very risky prospect.

At some point, your motivation can switch to fear—fear of failure, fear of being the one that messed it up and potentially losing your job. It could be fear of the client changing to another company because they’re so unhappy with the service they’re getting.

And with fear comes a heavier sense of control. You want to start controlling every point of that, and that breaks down autonomy and creativity.

From a leadership perspective, you have to be cognizant of what’s driving you. Do you have the courage to actually push something through and take a little bit of risk, or are you being driven by fear? If you remove that fear element, that opens up your people to create solutions, to try and pilot different ideas. It creates a psychologically safe environment for everyone to work together and find solutions in the most efficient way.

Scott Rutherford:
So let’s take the conversation back a little bit—using this project as a case example. We’ve talked about understanding how we motivate folks to carry forward, but I wanted to look at the structure of the project. You mentioned the project was already underway, you had multiple phases of work. How did you structure the human factors work—the change management, the learning—around things like solution engineering, training, facilitation, go-live? There are different needs around each of those buckets. How do you approach and move forward in each of those areas?

David Kaiser:
I think the biggest piece of this for us in this instance was that we were working at the front line, helping with adoption. You’re getting that frontline resistance to a system, so it’s really important to understand what was happening prior so you can show the value in the new system that’s coming online.

We had to break it down and really understand where the benefits were so that when you’re going through this, you could give the context of the past to then paint how this was actually helping them—reducing time, improving efficiency, helping them answer questions better.

Then in live training, you have to understand the system and the process enough so that when people bring up ideas, you can either find a solution for them in the moment, or park that and find a solution using the SMEs who are assigned to that process. This company was really good about having embedded SMEs in all the different functional teams that we could reach out to and discuss, “Okay, how can we answer this particular question?”

If it took a system change—if there was something they just could not do—then there was an escalation structure in place for that as well. It could either go to change the materials or to go change the actual system process itself.

Scott Rutherford:
Right.

David Kaiser:
So we had different levels of issues that would come about, and a lot of times they would come through us because we were right there teaching the end user. A lot of the solution design and engineering had been done already—the first pass was complete and built out—but there are always things that get missed once you start going live. You turn the system on and realize, “Oh, we need to do this a little bit differently.” We had very clear processes on how to get those resolved as quickly as possible.

Scott Rutherford:
Yeah. And there’s almost a way to look at it and say—you mentioned training frontline staff, and anyone who’s worked frontline knows it can be a thankless job. But there’s sort of an old truism that if you want to know what’s really going on, talk to the folks on the front line because they know where the brand is, where the disconnects are. They see it and they live it.

So when we’re talking about training that frontline team on a new system, it’s natural that the person doing training delivery is going to be their first point of contact, because you’re right there with them. But you also have to build—I’d say credibility—with those folks, because if they raise an issue—whether the training materials are off, or there’s something in the implementation that doesn’t work—it needs to be addressed pretty quickly. Otherwise they’re going to be looking at you going, “Well, we told you about that last month. What’s going on?”

David Kaiser:
That’s a really good point, and it even goes deeper than that because that’s just honoring their feedback and giving it weight. You have a duty to give that feedback and make their job as streamlined as possible.

But also in these trainings, we stress the importance of what their job is. Every single job in the entire company is part of a larger machine, but it’s all absolutely essential. It’s an opportunity to honor what they do and celebrate what they know and the contribution they’re giving.

This goes all the way back to the first implementation I ever worked on—it was for a cash accounting team. People would come in, they would do bank account uploads, and it was a very mundane job. But we really stressed the importance of that job because by doing it on time, cash sweeps went in, money moved around, and we were able to, you know, buy a new tractor over at a mine site. What they did seemed mundane, but we stressed the importance of it.

That goes across any role in any company. It’s important to stress the value they’re adding so they know they’re doing something important. And the second piece is the system piece—making sure they understand the value the system is bringing to them. And if there’s something they can improve through their ideas, honoring that by making sure it gets escalated properly.

Scott Rutherford:
In our conversation the other day, we started chatting about—I wanted to ask you to take us through sort of the roadmap or best practices that can support user adoption. These each require a little bit of explanation so we understand what they look like. Can you take us through, in your experience, what the checklist for best practices looks like—what needs to happen to set yourself up to be successful?

David Kaiser:
Successful, yes. So in change management, the two models I’ve worked with the most are Kotter’s eight-step model and the McKinsey 7S model. I like Kotter’s model because it explains a lot of the theory behind why we do what we do—why these things are important. We talk vision and mission ad nauseam in so many circles, but they really are important. Kotter does a good job of explaining that.

The McKinsey 7S model—if you’re building out a plan—is a really great place to start, because it’s a very obvious step-by-step process to work through.

This response I’ve put together is kind of an amalgamation of those two—it’s the highlights and then my own personal experience.

If you’re looking for best practices, from a change management perspective, it always starts from the top. You need to have the sponsorship of leadership and the governance in place. Are there steering committees you can escalate things to? Are the escalation paths really clear?

In this last case, we had very clear governance on escalation, which removed barriers to getting things done because we had a clear understanding of who we needed to talk to. So sponsorship and governance—that’s the first thing you set up.

From there: vision and strategy. What are we actually trying to do? How is this impacting our clients? How is this impacting end users? Why is this adding value? Why is this important? Being really clear on that creates a common identity for everyone involved in the project and in the company, because we’re all working toward the same thing and value the same thing.

Then, mapping out stakeholders and impacts—this is in that solutions design phase. As we change things, as we move people over, who’s being impacted? You want to get ahead of the communications so they know. On these larger ones, people often know years ahead that something’s coming. Sometimes they know nine months ahead of time that their cutover date will be September 4th. They can either dread that date or be excited about it—but they can prepare both mentally and with their skills to be ready for that date.

Standing up a champions network—I’ve heard them called ambassador networks. A common term is SMEs, but essentially you want not only people who are best in the process, but who are influencers. They care, they’re passionate about helping people. These are the people who go above and beyond because they care.

I ran into some world-class champions at this last contract—people I admire so much that if I ever go back to that city, I’d call them up for dinner. They’re the ones who will be down on the front lines after the training team’s gone, after stabilization for the project is done. They’ll pick up the process and the system feedback and run with it. They’ll also help immensely with training.

Scott Rutherford:
And linking this also into HR and people management can be an important kind of cross-pollination, because the same people who might be the champion in the project might also be someone that could be looked at—or should be looked at—as a potential high-potential program participant, or someone for whom this is a stretch assignment.

David Kaiser:
Yes, yes. Because often they’re still doing their normal day-to-day work, and they do this because they really care. This actually goes back to our comments about intrinsic and extrinsic motivation. These people are highly motivated by intrinsic motivation—by the prestige, by the creativity, by the autonomy. They want to make a difference, and they love what they do.

Scott Rutherford:
Yeah. And by giving them an opportunity, really recognizing their passion and their skill, you can help their personal growth, their professional growth. But it also seems like an outcome of this—something maybe not within the written scope of the project—is that we’re supporting the growth of people and their skills, which makes for a healthier, stronger organization.

David Kaiser:
It’s an important benefit, because as those people rise, they create a vacuum that pulls up others behind them. You end up getting this excellent talent pipeline by giving these opportunities and the chance to make a difference.

Scott Rutherford:
Right. So I’ll stop my aside here, but you’re taking us through best practices—so yeah, we have the champions. What’s next?

David Kaiser:
All right, what’s next? This is more on the project management side of things—setting up objectives and KPIs. That’s really important. I’ve worked across multiple industries—mine sites, hospitals, all kinds—and they all measure things differently. But setting up KPIs and metrics is crucial because you have to give milestones. People measure time in their head, and they measure their progress through KPIs.

It’s important from a leadership perspective to understand project success, but it’s also very important at all levels to understand the value that they’re adding. If you have strong KPIs that are linked to true value-adding tasks, and you can see improvement there, people see that the sacrifice they made to do this implementation was worth it.

From a project perspective, these are just a few examples, but they cross over. Designing role-based training is another. On this last project, this was really well done—having a solid matrix to understand which systems are needed and, most importantly, which access is needed. Access can be one of the hardest things to manage. It seems simple, but you might get someone into the accounting system, yet they don’t have visibility to what they need to see. That could take weeks to sort out and creates unnecessary frustration.

So understanding what those roles are, making sure the access is set, and then giving them targeted training goes a long way. Having issues in those areas is just unnecessary noise—and it’s already a noisy time—so it’s very important to put that pre-planning in place.

Scott Rutherford:
So, and you mentioned—we’re setting objectives and KPIs. Obviously, you alluded to one objective that most people would point to first: “Okay, I know what my cutover date is. I know when the deadline is.” But so much of the work comes post-cutover—support, reinforcement, sustainment, all of that.

David Kaiser:
Right. And when I was saying KPIs, I was thinking operational KPIs. There are definitely project milestones so you can see the project moving along. Those are so high-level and so critical they rarely get missed, and if they do, it’s a very big deal.

These operational KPIs—like rework or error management—you can see very clearly what was being measured before. And if you see that error rate go down, it proves the value of the system and the effort put in to learn that system and improve the process as a whole.

Scott Rutherford:
So you mentioned earlier that it’s pretty common that a platform project gets underway and then learning comes in somewhat later. I wanted to get your thoughts on both ends of that. When should the human-factor side—change management and learning—come into a project? Is there such a thing as too early? And what advice would you have for someone who’s already somewhat down the road and hasn’t really started thinking about the people and the change?

David Kaiser:
The training—the human element you just mentioned—comes before the project even kicks off. It just manifests differently. In those initial phases, they set the strategy, create the structure—what needs to be changed, what it’s going to look like after—and then they start working on the systems and processes that support those systems.

But during that time, the people and communication piece—that strategy—has already come into play so there are no surprises. People know that change is coming.

Where Axiom jumped in as learning consultants was to make the knowledge transfer effective. You really have to wait until the solution design is done and the systems are created, because there’s so much change that happens all the way up to cutover that if you start too early, you end up with materials that are out of date and no longer useful.

Even when you get to, let’s say, the day before cutover, there are always learnings afterward where the system still changes. There’s always another cycle of training materials that are tweaked a month or two or three after cutover.

So, to your question—when is the right time to come in? From a learning and development perspective, it’s after the strategy, structure, and systems have all been put in place, the solution is designed, and if they’re creating new software, that software is ready to be tested. It’s when you get into UAT—user acceptance testing—that the processes are stable enough for you to start developing training materials.

But from a change perspective, as soon as the project is kicking off there should be communications about what it is—garnering excitement, saying, “Hey, we’re taking this company with all these old systems and moving into the future because we care and we want to be the best.” Building that excitement so that by the time those individual messages come—saying, “Hey, your cutover is in September”—people already know what it is, they’re not afraid of it, and they have the resources in place to start learning about it and preparing for it.

Scott Rutherford:
So what can happen if one of the pieces we were just talking about is missing or it isn’t handled properly? What can happen in the real world?

David Kaiser:
Well, I opened up with values and having a common strategy that gives a shared identity—we’re all working toward one thing. If you don’t have a clear picture of that value, if that shared identity isn’t strong, then adoption can feel forced. People feel pressured into taking on something, and you get resistance that just naturally occurs. That can be very difficult because it adds human inefficiency into a project we’ve spent so much time and money making successful.

It’s really important to reinforce that vision, mission, and those values so that people approach this as being part of something big—and being excited about it. Adoption shouldn’t be forced; adoption should be willingly accepted and creatively dealt with when issues come up. That’s a really important point.

Making sure everybody’s ready is also kind of a no-brainer, but having really good processes to understand where the skill gaps are is essential. Making sure that employees have access to the correct systems and the correct security profiles within those systems—it’s critical that employees can execute once cutover happens. It creates a monumental amount of frustration if they can’t. Once cutover happens, you get long hours, a lot of overtime, and a lot of frustration that’s unnecessary with the right amount of pre-work.

Scott Rutherford:
Right. And there has to be a value, too, in bringing in someone—I'll let you pat your own back here a little bit—but bringing in someone who’s been down the path before. Because you can advise on what the company might not see coming. You can help them circumvent obstacles rather than having to encounter each one.

David Kaiser:
Right. And escalate with the right amount of urgency—just to paint a clear picture of how important it is. At any given point, everyone in this project feels that their issue is urgent, and it’s sometimes tough to be heard among the noise.

Scott Rutherford:
So if you’re talking to the CIO or the CHRO who’s looking down the road at a major implementation, is there a final piece of advice you would give?

David Kaiser:
Yeah, I mean, we’ve spent the majority of this talking about change management—the who and the why—not so much the what and the how. And I think that’s commonly overlooked.

Like I mentioned, everybody has a firm understanding of what project management is, especially at the leadership level, because they’ve worked on great projects to get there. But I think awareness is the first step—that these models are out there.

The two that I mentioned—the McKinsey 7S model and the Kotter eight-step model—I really enjoy those. You can find them with a simple Google search. Just understand them and the concepts. When you apply those concepts to your own experiences, it becomes obvious where you could interject these ideas, and it makes a big difference.

System implementations are always going to be stressful, but when you shift that lens and use these models to go from controlling outcomes to empowering people, you’re going to deliver on the project. But there are also lasting benefits that happen downstream where you’re unlocking the full potential of your workforce.

Scott Rutherford:
Great. And I’ll put links to examples of those models on the episode page for this episode at axiomlearningsolutions.com/podcast. David Kaiser, I appreciate your perspective and your expertise, and thanks for being here.

David Kaiser:
Thank you so much. I enjoyed it.

‍