Join us as Vinnie chats with Leighann Hughart, Senior Manager in management consulting and an organizational change management (OCM) expert.
Tune in as we discuss:
Join us as Vinnie chats with Leighann Hughart, Senior Manager in management consulting and an organizational change management (OCM) expert.
Tune in as we discuss:
Vinnie
Hello and welcome back to CapTech Trends. Today, I have Leighann Hughart with us. I want to pronounce it Hughart, but it's Hughart. And we're talking about the value of OCM specifically, the combination of OCM and CX. I like to think about this as user-centered change management. And I know, Leighann, you've been working on this for a while. You have a framework around this. But for those people who are new to these acronyms, first, welcome, senior manager and management consulting. Welcome. And give us a little bit of an overview of what OCM is and what CX is.
Leighann
Sure. Well, thanks for having me. Super excited to talk about this topic. Change management can really be thought of as a systematic approach to guiding people through a transition and equipping them so that once that transition, or change, system, product, whatever it may be, is rolled out that they're successful in adopting that change. And, customer experience is really a practice focused on uncovering different customer insights, so that it can inform the creation of custom solutions that are designed to meet customer needs. So, a lot of data and research driven insights are used to inform that design.
Vinnie
So I'm going to go back to an earlier part of my career when I was an application developer, and show a bit of my ignorance and maybe some of my bias, and you can correct me. I always thought of CX as something that happened in the beginning of a project to help scope, help requirements, understand your audience, and change management happen at the end of a project. Where was the younger version of me wrong on both counts?
Leighann
Yeah. Well, I think that your thinking is actually pretty common. Change management is usually the first thing to... It's the first thing that people say, "Oh, we can cut that." Especially if you think about when an organization or company is rolling out an internal change, often the thinking is, "Oh, people are going to have to use this software. So, since they're forced to use it, we don't really need to focus too much on making sure they understand everything or that they really care about using it." And so, I think it is correct that CX is definitely critical at the beginning of an engagement because they are giving you those user insights and informing you how you want to design the product. But, change management does the same thing. Both have that end goal of making sure there's successful adoption. And, companies are always asking the age old question, "How can we launch a product and ensure that there's increased likelihood and improved timeliness of people using it?" And making sure that you have change management at the beginning of an engagement will set you up for success there.
Vinnie
Okay. I'm going to keep playing devil's advocate a little bit. I also see where if you do CX really well and take CX really seriously, it feels like there's an inverse relationship to how much OCM you need. If you really nail the CX, do you really need OCM? And I know the answer is yes, but I think I'm playing the younger me role. But if I think about someone like Amazon, or Apple, or Delta Airlines, or Marriott, or others who roll out new websites, new applications, new services for literally millions of customers, they got to get that CX right. But there's really not a large corporate OCM strategy around that. Or is there, and it's embedded in the communication and embedded in the application in such a way that it's transparent to me?
Leighann
Yeah. I think that that's making the assumption that a really well designed product equals adoption. And, I think a lot of times companies will launch a really well designed product, or program, or change, and they'll fail to see timely return on investment because of things like people just aren't aware that the product or system exists. It hasn't been branded properly or communicated to them in such a way that they care, they understand like, "Why does this matter to me?" Or, they simply haven't been given the tools to be equipped to adopt that change.
I think we have a great story where actually our OCM and our CX delivery teams partnered together, and it really just underscored the importance of the partnership in making sure that a really well designed product was adopted. We were working with a client to set up a customer ordering portal, and our CX team was creating the design flows, and they had gotten to the point where they were doing usability testing. And they brought our OCM team in to observe that usability testing. And from there, even though CX was using the feedback from that testing to make design changes, OCM was able to pick up on specific pain points as well as specific wins that needed to be strategically communicated to different stakeholders. And that then ensured that people were interested in the change and they were interested in what was happening because it resonated with them.
Vinnie
I like what you said, because it reminds me of another trend I've been working on, and that is, I think increasingly so, over the next five years and... I wouldn't even limit it to that, technology is going to become more and more ingrained in our everyday life experience, but in ways that's less and less obvious. So you don't decide to pick something up and do something with technology, it's just part of how you're acting and behaving and you think about it less. And, when you talk about adoption and you talk about change management, the old school ideas, having job aids, and having corporate communication, and putting... All those different things.
Leighann
Yeah.
Vinnie
But good design, using machine learning to know more about people, using personas to know more about people so that you can personalize that adoption curve in ways that they don't even directly feel as a technology or OCM experience, but it's helping with that adoption. And, I would even say, helping with the long-term stickiness of continuing to use that application. Are you seeing that as well? Is there a shift from more of the overt OCM to more of the design OCM?
Leighann
I would agree with that. I also think that it's about being creative in your OCM strategies. I think you hit on a myth about change management, that it's strictly training and communications. And, I think, the partnership with CX can add some creative and dynamic ways to deliver on more traditional OCM approaches so that it is less overt, but it can also help highlight the wins of the design. So, another story we have is, we were working with a client to roll out a major business transformation. It was a system overhaul of some of their legacy systems. And, it was going to help the employees a lot in just doing their day-to-day jobs, but instead of just communicating out what's in it for them through posters or giving them some quick wins through a town hall, we partnered with CX and rolled out some really interesting campaign videos that highlighted all of the quick wins of the new systems. And it was something that was scalable, we could push it out to the entire organization. And we saw directly through survey results that interest and excitement about the new systems had increased significantly.
So, it was a different way of delivering OCM and a creative way. To your point around the overt OCM versus design, I think that's a great, great point. I think there's still a lot of conversation between our OCM and CX teams around at what point does the design part need to be supported by supplemental communications or training? And it's not necessarily a design fix, but more so communications to stakeholders around, "Hey, this is how you need to navigate something to support the adoption." If that makes sense.
Vinnie
It does. And it's so nuanced, because I know this is a part of it, but there's also a surprise and delight element. For instance, there's a chart on a financial services app I use. And, I just happened to turn the phone sideways in landscape mode and the chart changed. Not only to fill the screen, but it had more functionality. And, I didn't read a help manual, there was no communication around that. But, that moment was a surprise and delight moment, not an OCM moment, where it was like, "Hey, did you know..." Clippy tapping on the screen... "Did you know can turn your screen sideways?" Right?
Leighann
Yeah, I see what you're saying.
Vinnie
Yeah. So I think there's... And I know this isn't really a question, it's more I think a nuanced thing to think through is, there are some things you need to be very descriptive about and I think there's some things you allow the user to discover, but that's just a balance, right? It's intentional.
Leighann
Yes. Absolutely. I mean, if you think about it, going back to that other story I was talking about with the customer ordering portal, we had actually in partnership with a third-party implemented a system overlay to support the navigation of the site. And, there was a lot of discussion around what is intuitive to the user that they can figure out on their own, versus what's going to reduce their pain points in navigating the system and it ultimately improved their experience by having that additional navigation and communication to help them through.
Vinnie
I was laughing when you said that, because the analogy that came to mind is, my number one place to go to figure out how to do something around the house, or in the yard, or whatever else is YouTube. And so, I'll go to YouTube like, "How do I replace a washer hose?" Or whatever. "How do I change the oil in my gator?" The first 20 minutes are like, "Okay, I'm not stupid." Right?
Leighann
Right.
Vinnie
I know where it is. I know where the nut is. Right? So, you scrub ahead until you get to the meaningful part, which is probably a 30 second bit you needed to see out of a half an hour video of someone trying to trend an oil changing video. So, the same thing I think is important with OCM, what not to say, the jazz approach to OCM, what you don't say is probably as important as what you say, so that people aren't turned off.
Leighann
Exactly.
Vinnie
Or tune out from the messaging.
Leighann
Yep, that's exactly it.
Vinnie
So you mentioned user surveys, how else do you measure success?
Leighann
So, that is where I have found actually partnership with the CX team, as I said, I'm coming from a change management background. So, for me, partnering with the CX team has been extremely insightful, because I've gotten to see some of the tools that they use that can be leveraged to understand success overall. So, both OCM and CX use measures to understand the success of either the product that's been rolled out and whether it's being used, if it's helping employees or an end user do what they want to do. I think, at a very tactical level, there's programs where you know can overlay it on a system or a product that you've just implemented and understand how long it takes for you to complete a task, which of course is important in some organizations for folks who are incentivized by efficiencies and completing tasks. So you can measure it at that very tactical level.
But the other way that you can measure success is, like I said, at a broader level through those user surveys, there's also some tactics that you can use, such as focus groups, you can do fly on the wall observations, but as long as you've set some metrics in place that you're going to measure against, of course, then you'll be successful there. But, yeah, I think it's interesting, because you can pull from both practices to identify different tools to measure success.
Vinnie
It's funny how we think differently, me being more architect-based and you being more CX-based, because yes, the user research, the time to complete task, accuracy to complete task, fly on the wall, all valid, all makes sense. I'm thinking of instrumentation of the actual code. So, compared to other digital assets within the organization, upon launch, this had a 40% higher download rate. Three months later it has a 60% higher continued usage rate.
Leighann
Mm-hmm.
Vinnie
So, basic normal instrumentation of data collection through an app or service I think can be tuned to compare how these activities... And look, it's hard, right? Because there's probably 10 other things that were done differently in the code that were promoted it to how do you know... Your example of how to measure it I think is more accurate, in terms of, "We made these changes, what happened?" Whereas mine, I think you muddy the water with more variables, but it gives it to you at a much higher scale and passively, right? Because it can keep going.
Leighann
Yeah.
Vinnie
Let's talk a bit more about how these combine. I'm very comfortable with CX, I love it. OCM as well, I've been doing projects for a long time. But when I think of CX, I think of journey mapping, competitive research, market assessments, style guides, prototyping, that stuff. And when I think about OCM, I'm thinking about readiness and impact assessments, employee engagement, having a corporate sponsor, organizational transition, those to me seem to be very defined disciplines. And I want to get specifically about now how you think of combining these. What's the shared responsibility between those two different things I discussed that you have a new way of thinking about it as a function within an engagement?
Leighann
I think the short answer is, and I said this at the onset, both are targeting adopting the end state. So, if you take a step back and look at how each practice gets there, yes of course, there's these one-off activities like competitive research that CX specializes in. Whereas, OCM, obviously we specialize in our training and communications, and of course we then get tagged as only being that. I would say in terms of shared responsibilities, I think, throughout the process of designing and implementing a change, what I've seen is, there's a lot of shared activities that we both do, we just may do it a little differently. And, to make that real, I can talk about some of examples.
So, early on in the process of just understanding what the change is and trying to figure out what the design is going to be and all of that, you're doing a lot of stakeholder research. And, that activity is super critical to both practices. From the CX standpoint, you're trying to gain user insights into the pain points and the needs of the end users. And likewise with change management, but you're also trying to understand on the change management side where you might have resistance in rolling out the change, so that you can design some strategies to effectively address that.
And so, when I think about the two together in that specific instance, you can do activities like partnering together to facilitate the stakeholder interviews and making sure that the questions you're asking are getting you the information that both teams need to effectively do their jobs. And, coming out of a stakeholder interview, you can employ a CX tactic which is creating stakeholder personas. And then from there, an OCM team can take that and develop a persona-based training plan or a persona-based communication plan. That's just one example of where I think the two can partner together. But ultimately the shared responsibility is ensuring adoption once the thing has been rolled out.
Vinnie
So, I want to be very specific tactically on this, so people know what's actually happening. I'm going to make a lot of assumptions, so you correct me where I go off the rails.
Leighann
Sure.
Vinnie
It doesn't sound like you're suggesting spinning up a new team. It sounds like the team members already exist within CX and OCM. And it doesn't sound like you're proposing any new types of work necessarily. It's having a framework that says, "Let's be more transparent and more coordinated on these subset of activities that we both do, because we both have a shared stake in it. And let's coordinate that so that we're doing one meeting instead of two, or one task instead of two." And, making sure that all the needs of both groups are being met. So maybe there's some modification to it to make sure that that's a little bit more complete. That sounds like-
Leighann
That's spot on.
Vinnie
Okay, good. So, it doesn't sound like more work. Because one of the things that would concern me is we don't need another part of the project that's going to decrease our velocity, right?
Leighann
Right.
Vinnie
So this sounds like we're actually increasing velocity a bit, because we're doing the same things, we're consolidating some of the activities in a smarter way. Am I getting it?
Leighann
That is spot on. The purpose of this is actually to introduce efficiencies in our delivery. So, going back to that stakeholder interview process, one thing that we're actually working on is a tool, we're calling it a blended stakeholder interview guide. And it basically pools tactics from each team, so that, in the instance, like we talked about before, where change management isn't brought in until the end, you have a CX team on the ground, they can go do those stakeholder interviews and ask the questions that the change management team will need later on so that when that team is brought on, we're not going back to those same stakeholders and asking to duplicate interviews. And essentially, we're reducing cost for our clients then, because you're not charging for the time to facilitate that activity.
Vinnie
Got you. Give me, if you can... Because I think we've covered the material quite well, but I want to wrap up with some good visual things people can take away, if you can, without being too descriptive, is there a client situation, either one we've had or one you've read about that isn't one of our clients, where you can state a before and after effect of implementing something like this?
Leighann
Yes. So, I can speak to a situation in which the change management was brought in very late in the program implementation timeline. And there was no CX team. So, essentially a system was designed without really pulling on what the end user and what stakeholders needed out of that system. So, it was designed essentially based off of leadership's understanding of the needs, but it wasn't really validated with those end users until much later in the process. And, it created some challenges when we were talking about the systems, when we were trying to communicate the wins, because we also had to communicate what wasn't going to be included in the system. And we ended up creating a massive backlog that essentially was promising the organization that we'll get to it. And, I think that created a lot of headache for our implementation team and essentially the product managers later on, because as you know with time, desires and needs around what a system should be doing can change. And I think, when you are tied to those promises, it creates some headache.
But then on the other side, it's a lack of trust from the organization that the system is really going to do what they need it to do.
Vinnie
What's the point of having a high velocity delivery team if you're off target?
Leighann
Right.
Vinnie
So I think, it really is important. So, a couple closing thoughts. So, people are listening to this, they're getting interested, how do they get started within their own organization? I know you've done a lot of work around this, a lot of thinking around this. And, they don't have access to all the stuff you've done. So, what are the good first couple steps that someone can do?
Leighann
It's understanding the basics of each practice. On the change management side, there's industry standards, we've got Pro-CI and other programs like that to help you understand the basics of change management, debunking myths around it just being communications and training and understanding the other strategic pieces to it. And then on the CX side, I think, likewise, it's understanding the basics there, trying to understand some of the tactics that they employ to really understand the end user and create a process or product that is designed to meet those needs. So, there's plenty of blogs on the CX side. I know Nielsen Norman Group has a lot of great information on user-centered research and different activities there. And then, I would also just say, reach out to me on LinkedIn for any questions. I'm happy to connect the dots on how the two connect.
Vinnie
Yeah, you have a really nice slide and a PowerPoint you sent me the other day that really shows all the different... I mean, it's an iChart, as you said, right? So, it's not a great PowerPoint slide. It's a great takeaway, right? It's a great pdf.
Leighann
Right.
Vinnie
But I think that's important, because it's detailed enough that it's usable, it's not just conceptual. But it shows all the activities between the two and where they overlap. And so, if people have questions about that, I think that's a really good thing you could walk somebody through. So, if you're interested, feel free to reach out. Leighann, thank you so much. I've really enjoyed this conversation.
Leighann
Thank you.
Vinnie
It's always good to have engagement project specific things that aren't always super technical, but every bit is valuable to the success of the delivery. So, in order for us to be well-rounded and hit all aspects of it, it's great to have experts like you on the show representing that. So, thank you.
Leighann
Thank you so much for having me.
Vinnie
And thanks for our audience for listening in. Stay tuned. We have a lot more really good podcasts planned coming up very soon.
The entire contents in designing this podcast are the property of CapTech or used by CapTech with permission and are protected under U.S. and International copyright and trademark laws. Users of this podcast may save and use information contained in it only for personal or other non-commercial educational purposes. No other uses of this podcast may be made without CapTech’ s prior written permission. CapTech makes no warranty, guarantee, or representation as to the accuracy or sufficiency of the information featured in this podcast. The information opinions and recommendations presented in it are for general information only. And any reliance on the information provided in it is done at your own risk. CapTech. makes no warranty that this podcast or the server that makes it available is free of viruses, worms, or other elements or codes that manifest contaminating or destructive properties. CapTech expressly disclaims any and all liability or responsibility for any direct, indirect, incidental, or any other damages arising out of any use of, or reference to, reliance on, or inability to use this podcast or the information presented in it.