Video: Technology Change Adoption is More Than Going Live

Transcript

Kyle Haines: Welcome to our Change Management webinar series, Change Management in Action. We are really excited that you’re here today. The goal is to share actionable knowledge on how to introduce change into your technology projects.

Many of you may know that Build focuses on change management because we think it’s central to technology change. I can’t help but think about something that Debbie said in the last webinar when she talked about change, and she said you could either pay for it now, or you could pay for it later. I saw a sneak preview of this webinar, and I think you’re going to see this in sharp relief.

Today’s session is the very last of a 3-part series. This series is about going live and getting the most from your technology investment. It’s about how to support users beyond go-live.

I’m so excited to welcome back my fellow partner, Debbie Cameron. She also might be incredibly excited to have hit this milestone where she brings it all together across 3 webinars that range from planning for a change to actually being at the point that you get to see it come to fruition.

My role today is I’ll be here to monitor the QA in the chat. Please add your questions to the QA or to the chat. I’ll keep an eye on that. We’re also going to have time at the end for questions that Debbie has graciously agreed to answer. And with that I’ll hand it over to you, Debbie.

Debbie Cameron: Good afternoon, everyone. For those of you who didn’t attend either of the previous webinars, I’m Debbie Cameron, a partner with Build Consulting. I’ve been in management and IT consulting for over 25 years. I started my career in the big consulting firms like Arthur Anderson and Bearing Point, and about 6 or 7 years in, I wanted more purpose in my work. I moved to a division within Bearing Point that served nonprofits, and

I fell in love. I loved working with clients whose mission I believed in, and it was during this time that I discovered change management, mostly because, like any perfectionist, I wanted to make projects more successful. And I’ve learned through experience and training and research that a good way to do that is change management.

I did work for a nonprofit. I joined the World Wildlife Fund for about 4 years to get that perspective of what it was like to be in the walls of a nonprofit, to lead their Blackbaud CRM implementation, and I found that my consulting experience prior to that helped me advocate for the organization and help them navigate a large technology project. And now, at Build, I get to combine my passion for client advocacy and change management and help our clients navigate large technology projects.

I’m very dedicated to ensuring nonprofits succeed, especially since many tech projects fail due to a lack of change management. And that’s why you all are here today. So let’s get started.

Agenda: Technology Change Adoption is More Than Going Live

Our agenda for this webinar is very simple.

• Let’s ground ourselves in what is change management and why we need it.
• Introduce thoughts on tools that can help us execute change management during and post launch of a new technology.
• Learn how to leverage those tools during the launch and onboarding to a new platform.

For those who attended any of my past webinars, some of what I’m going to kick off with today is going to sound familiar. But since it’s been a little while, and I think it’s always important to re-ground ourselves. What change management is, and why, is important. Especially as we are likely moving through a busy day with lots of competing priorities.

Before we dive into the details on way to execute the change management. Let’s remind ourselves of why we need it and what it is.

What is Change Management? Why Do We Need It?

At Build Consulting, we have two core beliefs that motivate us both to do this work and to approach it in the way we do.

The first is our belief that technology can empower organizations to both work more effectively and to change the world

The second is that technology fails so often because we treat it like a baseball field in Iowa. We think if we build it, people will come, we get the shiny new technology. But we don’t recognize the need for the organization to get shinier, too.

OO + NT = EOO

Old Organization + New Technology = Expensive Old Organization

This is a formula that we’ve used a lot before. And, in fact, if you’ve attended my past webinars, or have even just worked with me, you’ve likely seen it a lot, or heard me refer to a lot.

That’s because I think it really drives home this important point. If you just take a new technology and insert it into an organization, you’re just going to end up with an expensive old organization.  The framing of this point never gets old for folks, because everyone has lived a version of this.

I harken back to the slide that I shared earlier, what we do need is to figure out how we can advance the organization along with the new technology.

And the key is finding the right things. To add to this formula, that where the outcome will be the transformed organization that can utilize this new technology in a way that’s effective and critical to your success.

More than 50% of nonprofit technology projects fail because the tech moves forward, but the organization does not. And maybe some of you have lived through this or are currently living through it.

Which brings me to seeing why folks are here today.

There were two questions that folks answered when they registered for the Webinar. The first being does your organization prioritize change management? And I have to say this is really exciting for me to see. But this is this is a shift I’ve seen throughout my career in that organizations and projects and folks are becoming more attuned to change management. And this is exciting that almost 60% of your organizations prioritize change management, maybe to increase knowledge sharing.

Today, folks can put in the chat what their work has done in the world of change management. That’s had a positive impact on a project, or maybe something they’ve learned from trying to execute change management on a project. And then maybe if we have time at the end, we can highlight a few.

The next question was, When does your next technology project start that needs change management?

And this is great because a lot of you are either in a project or about to start, so I will make a plug for those of you about to start. If you have some time, definitely check out the first webinar I did around layering change management into project planning. I do believe you’ll reap the benefits. And actually, as I look at these numbers with projects in front. I’d encourage you all to check it out if you’ve missed it, although if you have to choose between session one and session two for time, I would recommend session two which talks about change management during the implementation. But the important point here is change. Management can’t be ignored, and wherever you are in your project definitely make sure you’re layering it in.

Change Management Fails and Project Fails

I mentioned that change management is a big component of why we see technology projects fail. And here’s the connection. Here’s the driver of why that’s the case.

A good deal of the failure rate of technology projects is related to the fact that we simply do not do a good job of anticipating the effect of these projects on the people they’re supposed to help.

When these impacts of the change hit them, we lose them, those are who we were trying to serve. As a result, we don’t get the return on the investment we hoped for, and we might not get that ROI on the technology that we invested in.

In a lot of cases for our clients, the organizations have already introduced a large change, without an appropriate level of change management. So, they have eroded trust with their stakeholders, and they come to us looking to change that.

What is Change Management?

We like the definition by Prosci, which is a leading research and consulting company in the field of change management. I think they were the groundbreaking organization in change management.

Their definition is Change Management is to prepare, equip, and support individuals to successfully adopt change.

You will notice, it does not say guides how we make everybody on a project happy. It’s a frequent mistake about change management. It is not about making everybody happy or selling the change to folks with a lot of positivity wrapped around it. It’s about making everybody ready for the change.

When we start working with a lot of our clients, we find the culture supports the following statement – if you have emailed it, you think you have changed it.

If that doesn’t work, what should change management look like at an organization? At Build we believe it’s a concurrent work stream to any project, and it can be done by internal resources or by a consultant. But what it cannot be is the side job of someone who’s managing the technical side of the chain change.

Oftentimes there’s a technical project manager focused on executing every aspect with a project, and it’s a lot to ask of one role to do both.

Do I need Change Management?

If your technology change requires people to adjust their behavior, that’s the test. If you’re asking people to do something differently, you need change management.

When Do I Need Change Management?

The next question that follows here is, typically, when do I need it? How much of it do I need? Can I do it myself? How much does it cost? When do I start?

As we talked about during the first webinar in this webinar series, ideally, change management should be integrated during the planning and design phases even before the technology is selected or implemented. But if you’re past that stage, don’t worry. It’s never too late to start integrating change management into your work.

During the second webinar in this series, we focused on having change management integrated throughout the implementation. And today we’re focused on the importance of continuing change management through system launch.

You might be asking, why do I need change management at go-live and beyond? We’ve launched the system, we’ve gone live. We’ve reached the end of the project, and we should be celebrating.

Why do I need to keep focusing on change management and continue this investment at go-live and beyond? It’s because go-live isn’t the finish line. It’s just the beginning of how people actually use the system in their day-to-day work.

Change management helps ensure that adoption, sticks, behaviors evolve, and we continue to see the return on investment we had planned for.

Before I dive into the six reasons on this slide of why we need change management after go-live, I want to just mention two reasons that are not on this slide, because we had previously communicated them in this webinar series, but I feel it needs mentioning in case we have any new folks who missed the other two.

• One, it helps us connect the technology to organizational goals. Technology Strategy is organizational strategy. One cannot fully succeed without the other.
• The second is, change management supports your leadership by providing them with tools and resources. They need to lead through the change and support their teams in the transition.

Both are worth mentioning because they were really important to why you need change management for every phase of the project, but more closely tied to the go-live, are outlined on this slide.

Change can be tough, and resistance is natural. By addressing concerns early, we can smooth the transition and help everyone get on board with the new system.

It helps with user adoption. We want everyone to feel confident, using the new system through training and support. We’ll make sure people know how to make the most of it right from the start

We don’t just want users to log in. We want them to use the system well, when people are trained and feel supported and know where to go with questions and issues, they’re more likely to explore and adopt the full range of features, not just the basics. That’s how we start to see the real value of the investment.

Additionally, keeping everyone in the loop is key to success. Regular updates and clear communication will make sure everyone knows what’s happening and why continuous improvement is really important.

The go-live isn’t the end. It’s just the beginning. Ongoing feedback and adjustments will help us refine the system and keep improving as we go. If you work with me on a project you will hear me say over and over again, go-live is just the beginning of our journey with the technology.

So many people look at it like it’s the end. But it’s just not true. All the pressure we put on ourselves to get everything just right. Yes, of course, we want to design it well, because we know redesign costs more money. We don’t want to revisit everything.

So yes, we want to get it as right as we can, but sometimes you have to live in a house for a bit before you truly know where it makes sense to put things in the kitchen in those kitchen cabinets, and you may need to adjust. And that’s okay.

You want to create the room and space for that because folks are going to learn as they begin to use the system, the organization is going to learn as they begin to use the system. You want that continuous feedback.

And finally, it’s critical to long-term success that change management doesn’t stop. Once we’re live, we’ll continue supporting the system to make sure it becomes a regular part of everyone’s work and continues to add value over time. And you just can’t argue with all the research out there that underscores change management is necessary to achieve long-term success.

Outcomes of Investing in Change Management

What are some outcomes of investing in change management?

• Higher adoption rates by having a solid change management plan in place. Users are more likely to fully adopt the system. It helps when they understand the benefits, and when they see efforts being made to ensure, they are comfortable and supported. It increases their confidence in using the technology.
• It improves user engagement. When users feel supported and have a clear understanding of how the system works, they’re more likely to stay engaged by providing regular feedback loops and support.
• It keeps them invested in making the system a part of their daily routine.

Activities around go-live are focused on addressing concerns early, helping to ease the transition by involving stakeholders in the process. We reduce the fear and uncertainty that can come with the change, making it a smoother process, for everyone involved.

You want to have clear visibility into performance. With KPIs and feedback loops in place, leaders can easily see how the system is performing. This visibility helps us pinpoint areas that need improvement and ensures we’re optimizing the system effectively.

And as I keep mentioning and probably will continue to reinforce throughout this webinar, change management isn’t just about the go-live moment. It’s about keeping the momentum going.

Ongoing support and adjustments help the system remain relevant, delivering lasting value and continuous improvements to the organization. And that’s where you’re going to get that long-term success.

Change Management During Go-Live and Beyond

What does change management look like during go-live, and beyond? There are so many great and innovative tools to use at this big project milestone, where we’re executing the change. We’re actually in there doing it, specifically thinking about go-live, and immediately following.

By “immediately following,” I’m thinking, it can be a month, it can be as long as 3 months, or 6 weeks.

I’ve listed my six favorites on this slide.

1. An adoption plan. That’s all about setting people up for success. It paints the picture of what success looks like, how we can achieve it, and how we’ll measure progress along the way it ensures. People have the tools and support they need to get comfortable with the new system, and it helps us track how well they’re adjusting.
2. Cut-over planning is the roadmap for this big transition. It ensures we have all the steps lined up to move from the old system to the new one, and it’s focused on minimizing any disruption. It also fosters transparency, and that builds trust. If folks know what are going to happen and can anticipate things and understand that things are covered. They’ll build trust in the process, and it helps everyone feel comfortable, more confident about the switch.
3. Project reflection and post launch surveys. Once the system is live, it’s critical to get feedback from the users. Project reflections and surveys help us identify what’s working well, where we can improve and what we can learn for next time.
4. Super users are our on-the-ground change champions. They help other users share tips, surface feedback and training needs, and make sure everyone feels confident using the new system.
5. Support frameworks provide the safety net for users whether it’s help desk, guides, job aids or online resources, or maybe a SharePoint form or an email address. They give everyone a place to go when they need help, and that’s going to help. Things run smoothly.
6. And finally, it’s important to celebrate wins along the way. A recognition program helps us acknowledge people’s efforts, keep morale high and motivate everyone to continue to embrace the change. Research consistently shows that leadership recognition of post launch adoption has a clear line to successful adoption.

Kyle Haines: This is the perfect. You gave me the perfect segue into a question from Thomas. It’s a big question. So, you get to take a drink of coffee or water.

Thomas shared that they find a lot of project teams on the client side struggle with the language, and that becomes a barrier to buy in.

And they’ve seen implementation failures from a combination of one, not understanding iteratively what’s been happening along the way with respect to technical work. And second, and I think this is where this links up with what you were just sharing, an over reliance on quote “the training” which it’s thought of as a one and done thing. Part of what he said, and I’ll give you a compliment in this, and you can have lots of water.

Part of what Thomas loves about this series is that you’re positing that change management is the scope of work, and it contains other concepts like training and iterating.

Q: How Do You Convey to Clients that this is an Iterative Process?

So the question in all of this is, if you have any tips on the organizational development and the psychological challenges of clients who don’t understand that this is an iterative process.

Debbie Cameron: That’s a great question. And before I attempt to answer the really great question, I just want to pause on that so many times change management is just linked to training, and they think if they have training, and if they send some emails, then change management is handled.

Kyle, I like the way you presented that is, that training does tend to be treated as a one and done, and it’s done before folks are in the system.

Training shouldn’t just start at go-live. Training really should start during design, because that language barrier that often prevents successful adoption is redefining the taxonomy of the organization and starting to connect the new taxonomy to the old taxonomy. And that takes time, and that takes people learning a new language and new words for things in terms of introducing change management as more of a long work stream and helping them get comfortable.

With that I might have a slide that speaks to that a little bit later on.

All you can do is talk them through the research and their history, because I guarantee, whoever you’re dealing with has been through these projects before.

Responding to Push Back on the Need for Change Management

What I like to do when I get push back from a client about them not thinking change management is important – it’s not about me trying to sell my change management work. It’s about me making sure that they have some focus on change management is really to ask questions, and they’re leading questions.

There are questions really focused on having them determine what those points of struggle are going to be for their folks. That happens by me just asking that leading question.

I think the most helpful way to do that is to extend it beyond the project team that’s planned to be part of the implementation. Talk about that it’s going to be more than the project team that’s using this tool. It’s going to be more than the project team that’s adopting, not just this technology, but new processes, new language, likely new roles.

They might be giving up some workarounds. There’s going to be some gaps in functionality where we’re going to have a new process that involves a small workaround, and be in tune with all of those things. Otherwise, it’s just not going to be successful.

That’s the most frequent thing that I’ve said to clients where they’ve later come back and said that really landed for them.

Besides, my favorite formula is that if you don’t deal with change management as a separate work stream, and if you don’t put the investment in time as part of the implementation, there’s going to be a long tail that’s going to come and hit you after go-live.

The length of that tail that’s going to come and hit you is not only going to drive costs, resources, distractions, user frustration, but depending on how much you ignore the change management, the length after go-live, and the fight that you’re going to have to do after go-live is just going to be increased.

That’s something I’ve shared that later clients have come back and said it really resonated with them.

When Should Training Start on New Technology?

Kyle Haines: Debbie, there’s another question that we have. It’s my question. I definitely get to interrupt with my question.

The training oftentimes is done at go-live, and that there’s an opportunity to do it much earlier. Can you talk a little bit about when people are doing big projects like a CRM platform project or an ERP project.

What does training look like at the beginning that helps with adoption later?

Debbie Cameron: There is a movement that has occurred in the past several years which I really like, and that’s training the project team on the tool prior to design.

The issue with that is folks can’t become experts on something, especially if they’re not using it, and especially if they’re trying to translate their work today to this new functionality that they were just shown.

That’s tough, but I still like it, and I still think folks should advocate to get some training before design.

What is been successful is during design to notice, the a-ha moments for the project team, in terms of for example that new taxonomy we were just talking about, or a new connection to a process. For example, Oh, I’m going to be doing that this way to actually put it somewhere.

In this more remote world that we are in now I like using tools like Lucidspark or Lucidchart. Zoom has whiteboarding. I haven’t played with it a ton, but Teams has whiteboarding too, and having whiteboards as part of your design session where you’re writing taxonomy is very helpful. For example, this word is now this word, or this process is now this process, and having that visually, especially for our visual learners, really helps start to train, and it really helps folks start to talk about it in a new way.

If internal folks are talking it in a new way instead of it just being the consultants, that’s going to go a long way towards a successful go-live.

Any other questions, Kyle, or are we good?

Kyle Haines: You’re good. Thanks for answering my question, and Thomas’s question.

Debbie Cameron: Great.

We’re going to dive into two of these tools today. One is the adoption plan. The other is support frameworks.

Attendee Poll 1: Have you used an adoption plan in previous project?

I’m curious. This is one of two polls we’re going to ask you to participate in today. We’re going to poll all of you and ask, have you used an adoption plan in previous projects? I’ll give folks a minute to answer.

And while folks are answering, if any of you have answered yes, just an idea to increase some knowledge sharing among all of us. Perhaps some folks that have used an adoption plan can put in the chat what was included the adoption plan that was helpful, and also maybe something that wasn’t helpful, so folks can learn.

Kyle Haines: Giving people just a couple more seconds. There’re some stragglers. All right. I’m going to present the results.

Debbie Cameron: Okay, great. Looks like about 32% say yes. Again, if anyone wants to do any sharing in the chat, that would be amazing.

Kyle Haines: Thomas shared. Thomas gets an A for participation by the way.

He shared that one of the things they did around adoption was, they added a steering committee, and they named some technology champions.

Debbie Cameron: Oh, I love both of those things.

According to Harvard Business Review, 12% of major change programs produce lasting results. And so I put this up here just to highlight what a significant challenge it is for organizations when they’re trying to attempt any transformation. And that’s inclusive of technology.

I wonder if what the statistic would be if we just focused on technology. But it does require a sustained effort and a commitment across all levels.

And I really think it’s important for our leadership to be aware of these challenges and know that, Yes, we have to invest in implementing and the technology, and that involves designing it and building it and make testing it and making sure that we are able to turn it on at go-live.

But when we think of what strategies that can be leveraged to improve the odds and ensure that our change initiatives are not only initiated but also successfully maintained over time, I think, let’s take a look at that.

It’s important to distinguish implementing it versus change management.

Historically, projects have always had project management, and that’s been a discipline that started a long time ago, and that there’s been a lot of investment and growth in. What’s been really exciting for me is watching the growth in the change management discipline in recent years. I think it’s important that we just spend a second differentiating the two again.

This is the slide I was talking about earlier that I thought might help because project management is focused on the goal of completing a project  – that was the goal line. That was a success point.

When in reality, that’s the success point of the project turning on. The system is not what we set out to achieve when we take on these projects, it’s successful use of the system.

And we should note, this will often not be a goal of your implementation partner. And that’s not a knock on your implementation partner. You hire your implementation partner to focus on implementing and getting to go-live. And

your implementation partner is going to be focused on go-live, too, because that is likely the last milestone in their work for you, and they want to get there, and they want to achieve that.

But that is why the final activity, if you look in the project manager tracker, the final activity there is deliver.

But when you look at the final activity on the change management discipline, it’s adopt.

Success for change management is not go-live. It’s successful use of the system. It’s that adoption. It’s the processes being executed well around the system. It’s the data being entered and collected and tracked in a way that’s consistent and reportable, and for that reason it’s important to differentiate the change management from project management.

Don’t get me wrong. Go-live is a significant milestone. It’s a mountain you climb, and it should be recognized and celebrated. But it’s not the endpoint, and I just implore you to not let the project management journey distract you from the change management journey, because change management cannot stop at go-live, and an important tool that I believe helps keep the focus on change management beyond go-live is the adoption plan.

What is an Adoption Plan?

When I say, adoption plan, what is what exactly does that mean?

An adoption plan outlines strategies to ensure users, embrace the new system, providing them with the necessary resources, training, and support throughout the transition.

On this slide, I’ve listed the sections of Build’s typical adoption plan outline.

• Overview
• Timeline
• Branding the system and its culture.
• Behavioral expectations.
• Long-term change objectives.
• Short-term change objectives.
• Leadership alignment.
• Adoption risk log.

Diving into a little more detail of those sections.

Overview

The adoption plan overview really focuses on roles and responsibilities in the adoption plan, key definitions that goes back to those. We’re introducing a lot of new terms – let’s acknowledge them. Let’s be aware of them. Let’s make sure that we’re all well versed in them, especially leadership, because when we hear them talking, we want them to be well versed in them.

Timeline

And then, of course, a timeline. This section sets the foundation for the adoption process and ensures everyone knows their roles. What’s expected, and what the timeline looks like in terms of what we’re trying to achieve in this particular adoption plan, so we can all stay aligned and on track.

Branding the system and its culture.

Branding isn’t just about creating a name or logo. I get pushback sometimes when I’m with a client. And I say, let’s talk about whether or not your culture supports branding a system, and they say, we don’t want to give it a name, and things like that.

It’s more than naming it. It’s about making the system feel like it belongs in the organization. This includes creating messages that align with your culture and values. You want your people to see the system as part of their daily work, and being able to talk about how your culture supports the use of the system, which may include an evolution around the expectations of how we work.

Especially leadership need to be prepared to confidently talk in those terms, and it’s great if we can connect it to some sort of logo or branding, but regardless. the branding can just be messaging around the system, or it can be a system name, logo, and a whole big thing. Whatever fits your culture. But it’s an important thing to focus on.

Long-term Change Objectives

These are the big picture goals we want to achieve with the new system. We need to know where we’re trying to get to, and we need to stay aligned on where we’re trying to get to, to make sure that we’re moving in that way. It’s about setting clear expectations for what success looks like in the long run, and what it will take to get there. And you want to make this as clear as possible because you need to know where you’re going, so we can figure out how to get there and how we get there.

Short-term Objectives

Here we focus on the immediate steps we need to take to ensure successful adoption. Now that we’re live with the system, this includes setting clear behavioral expectations, measuring progress, staying aligned with leadership. We also identify and track any risks. I like to think of the short-term objectives as the action of the plan.

Kyle Haines: Debbie, can I ask a quick question on the last slide. When you talk about branding the system and its culture, say we’re working on a CR, we’re doing change management work along a SI that relates to a large CRM implementation. The way we’ve thought about the culture is getting leaders aligned around what the expected behaviors are for team members who are using the system. And maybe you answered my question. I saw you nod. Does that fit under what you’re talking about with the system and establishing the culture for the system?

Debbie Cameron: It does, because folks aren’t going to change their behavior unless there’s really a reason why. Right?

I work for this organization for a reason. I value my job for a reason. There’s a lot of different things that make people work, right? So we want to talk about some things that might drive those behavioral expectations and doing an exercise where you talk about the values of your organization, the culture of your organization, what drives or why do people want to work here? Why do they want to move it forward? That’s a good foundation to figure out how we can connect them to behavioral expectations.

I mentioned part of that culture, because your culture needs to support the use of this system, and that may include an evolution around expectations of how we work. And so that’s those behavioral changes.

They’re going to end up driving what we’re going to talk about on the next slide, which are, what are the new behavioral expectations? You don’t want behavioral expectations that you can’t align to any of the things we just talked about, right? Because it’s going to be a hard sell. Starting with the branding and the culture, and how the system fits into the culture of the organization helps us figure out how we are changing.

What behavioral expectations we can expect, what behavioral expectations we need. And then we can set some KPIs to measure whether or not we’re achieving those behavioral expectations.

Was that a helpful answer?

Kyle Haines: Incredibly helpful. Thank you.

Debbie Cameron: Great.

Short-Term Objectives

Our short-term objectives are our actions.

How do we actually navigate from the previous slide? How do we navigate from the mountain peak of go-live to the peak of adoption?

Of course we’ve leveraged everything that we just talked about on the previous slide. But this is where we get a little bit more granular in our short-term objectives, and those are the actions needed to support the continued momentum and onboarding to the new system.

We have our KPI tracking and evaluation. This is where we define exactly how we’re going to measure success in the short term. This is where we set up a system for tracking key performance indicators.

We’ll outline goals, metrics, and targets and ensure we have milestone dates to check in on them and clear evaluation criteria to measure our success. And by setting the goals, metrics, and milestones, we’ll know what’s working and where we need to adjust.

Using the behavioral expectations example that we were just talking about, we’ll be able to sense that we’re not moving the needle in that way. So maybe we didn’t do a good job in establishing where the system fits in our culture, and how we can drive people towards this, how we expect them to behave today. Let’s get back to the table and let’s figure out a new way.

User satisfaction surveys, qualitative feedback is important. You’ll collect it in a number of ways. You’ll collect it in team meetings. You’ll collect it from change champions, those super users we talked about. You’ll hear people complaining to their leadership.

We still want some structure around the qualitative feedback. We also want some user satisfaction surveys where we are asking exactly for some pointed feedback to see how they’re feeling about the system now that they’re in it. Now that they’re using it, that that will give us real time feedback on their experience and help us to address concerns quickly.

Leadership Alignment

Leadership alignment is always a critical component of every step of the way in change management, and leadership plays a crucial role in supporting the change here.

This section really ensures that everyone in leadership is on the same page and reinforcing the same messages to drive adoption.

Adoption Risk Log

And then an adoption risk log. Every project faces challenges and the adoption risk logs helps us stay proactive. It helps us sense what’s coming, and develop mitigation strategies and contingency plans should those risks be realized. It allows us to track any potential roadblocks and address them before they become a bigger issue. This is my big tip in the short-term objectives.

Leadership Involvement in Setting KPIs Around Adoption Goals

When you are developing your short-term objectives, I think a critical step is the adoption plan. But specifically, if you had to pick two things that leadership are involved in, it should be the culture and branding portion, and it should be the KPI.

When leadership is engaged in KPI definition they help set a clear vision for success. It ensures that everyone understands the goals we’re working towards and how success will be measured.

If we align where leadership really where their inputs really come in. Here is where they can align KPIs with outcomes and they can have their voice in. It ensures that those KPIs are not just numbers. They represent meaningful outcomes when they align with objectives. KPIs help everyone focus. And it’s not just about getting our work done today, but more a bigger picture.

When leadership is involved, it increases buy-in and it reinforces the importance of whatever those metrics that we’re measuring are. We won’t talk about them in terms of metrics, but it just the fact that we’re measuring them. We’re trying to drive that behavior. Leadership definining KPIs reinforces the importance of those metrics to the rest of the team. It boosts buy in across the organization, and it shows the teams that leadership is committed to this change and that they see a benefit in it, because they’re putting their time and energy into it.

Q: How to Update the Risk Log Over Time?

Kyle Haines: Sorry to interrupt. Anthony had a question about the mechanism for keeping the adoption risk log updated over time, and I don’t know if there’s a good time to talk to answer that question. His wonder was whether it’s just through user surveys, or if there’s other ways that you can identify risks to adoption before they manifest on a project.

Debbie Cameron: Definitely through user surveys. It’s through your change networks. If you’re using your project team as your change agents, have them surfacing the concerns and risks.

Oftentimes, project leadership can see them coming just because they’re hearing things or they’re being brought things but over time, once the system is live and operating ideally, the risk log will have some form of business owner. A business owner and an IT owner could own it together, or it could be as big as a governance committee that that kind of oversees the system depending on the size of the organization and the system.

A lot of times the risk log gets transitioned to those two bodies depending on which one and it keeps it going long term.

Leadership Accountability in KPIs

I will say that another big reason for having a leadership engaged in the KPI is building accountability, because when leaders are involved, it models accountability and commitment to the change process. Their active participation sets the tone for the rest of the organization.

If you’re thinking about “how do I get leadership involved in KPI definitions?” I like what Thomas said about the adoption plan. He had a steering committee. Maybe it’s not a steering committee that meets all the time. But get a group of leadership hopefully is a steering committee and can have a facilitated working session on KPI development and think about things like adoption metrics and qualitative feedback.

You can establish a metrics team or user performance or overall project performance team that looks at what ROIs are we looking at, or what process efficiencies like lead conversion rates? Is that what we’re looking to improve? Readiness assessments such as like support requests, leadership, engagement things, running their meetings out of out of the Alpha dashboard in the new system. Things like that.

Outcomes of Using an Adoption Plan

Five outcomes that I think are the big ones.

Increased user engagement. An adoption plan ensures users are engaged, as they’ve been communicated with what success looks like, behavioral expectations. We all like to know what’s expected of us, right? And we’re going to be more engaged if we understand that. And if it’s been a conversation. If we understand how all of this fits within our culture, it helps foster a sense of ownership and motivation, and it helps us feel more connected as these users. It helps people feel more connected to the system’s success.

Smooth transition, and reduced resistance. Coupled with clear expectations and proper training, an adoption plan really helps minimize resistance leading to that smoother transition. It empowers users by addressing their concerns, because there’s a place that they can submit them. If there’s a place they can go if they need help. It provides them with confidence to engage with the system more. They feel like, okay, they want me to be successful in this new environment.

A well executed adoption plan monitors how well users are equipped to use this system to its full potential maximizing that effectiveness and value to the organization, and by addressing the any gaps in knowledge that are that are shown through support tickets and providing continuous support. Your system really becomes part of the work of the organization.

Faster time to value. If you focus on behavior, change and measurement, an adoption plan will accelerate the time it takes for the system to deliver tangible results and benefits. That’s another selling point for your clients.

Quicker adoption leads to earlier optimization and cost savings. And that’s really what you’re going to get by putting time and resources into an adoption plan.

And of course I’m going to sell it again, because all the research says, and we can’t argue with it, you need all of this change management for sustained long term success.

If people don’t use the system, there’s no point in going through the implementation and getting this shiny new technology.

Lessons Learned: Adoption Plan

Just to share some lessons learned, let’s talk about a real-life example that highlights the importance of having that solid adoption plan.

Adoption Plan Challenges

A nonprofit organization we worked with spent nearly two years working on a new CRM system. They put all their focus on making sure that technical side of the project was perfect and that go-live went smoothly.

They partnered with us on change management, but only for the implementation. They wanted us to transition to them, and they would handle go-live and beyond internally. We set up the mechanisms to do the handoff, and gave them some tools and tips and tricks, a lot of what we’re learning today. But when it came down to it, they lacked the capacity to be able to spend time on it.

When we went live we celebrated. We had a big lunch. We had a big party. It was great. People spoke, and everybody thought, okay, we’re live. Everything’s going to take off immediately.

But after that initial excitement wore off and the lunch was over, no one was using the system, and when they asked folks why, there wasn’t a really clear answer.

Some themes were users who attended training were not clear around the expectations of use in their particular daily work, and when they went to work the next day, they didn’t have anything. They didn’t understand how they were supposed to change. How often do they have to do some of these things they learned in training? Did they really have to do them, and who was using them?

Leadership was unprepared to deal with folks not using the system because they didn’t have anything tangible to point to, to demonstrate what wasn’t going well. There were no super users or change agents post go-live. Everyone thought they were done with their duties, and there was a lack of roles and responsibilities. No one was clear that they were supposed to carry a lot of this forward.

It would have been great for this organization to have an adoption plan to guide them through this change, and when they were left unprepared, people disengaged. Leadership was very frustrated.

To make matters worse, leaders themselves didn’t know what they should do to model the behaviors they wanted from the team. They had the desire to be change agents. They wanted to model, but they didn’t. They hadn’t aligned on it. They didn’t have the language. They didn’t know what to do to drive adoption. And so, this organization’s investment didn’t pay off for a really long time, because the change ended up taking almost another year to really get folks in and using this system.

Adoption Plan Successes

Another organization. This organization had a new CRM system. And they knew that launching the system wouldn’t be enough. So, they were all in on carrying change management twelve weeks past go-live.

All the same, things were in play. All those ingredients were in play, just like the client I just spoke of. But this time, when the next day came, the adoption plan played a crucial role that those short-term objectives and the behaviors that folks were brought into and were aware that they existed. Leadership knew how to model the behavior.

One of my favorite things that folks can do to adopt any system is in a meeting, bring up the system, find some way in a meeting to incorporate the system, and being in the system to run the meeting. This organization did that.

Additionally, the KPIs provided valuable visibility into where users were struggling and highlighted change champions who could offer guidance and support. Leadership was aligned in the messaging around the system.

The result was just a smoother, more successful transition, higher system usage, and a clear path towards achieving the desired outcomes. It was really one of those projects you walked away from thinking yes, we did it. It was a really great feeling.

Attendee Poll 2: Have You Created Workarounds in New Systems?

So, my second poll, have you ever been working in a new system post launch and run into an issue where you brought it to a team member, or maybe you just solved it yourself? You developed a workaround to solve the wall you had hit in this new system?

Kyle Haines: Maybe hopefully, you don’t care that I reworded it to keep it to under 50 words.

Debbie Cameron: Not at all.

Kyle Haines: Alright, just because of time. I’m going to end this poll and share the results.

Debbie Cameron: In fact, my good colleague, Kyle Haynes, has called me out on doing this. Because we rolled out something internally at Build. I ran into a snafu with it. Rather than take time, well, I am, to be honest, I didn’t know who to go to with the question. And so, I just did it a different way and developed a workaround, and later, you know, got into got some feedback that I was creating some data issues when I did that. That’s the problem.

Because organizations that invest in change management as part of the work. They really are so much more successful to achieve their project objectives, and when it’s not there, when that support and that change management is not there, when the users are actually using the system, what happens is, users often resort to workarounds.

That leads to inefficiencies, because all those workarounds and those crazy processes we were trying to solve by replacing this old system with this new system. We do not want to repeat that.

And data. That’s a big thing that can get impacted is if we don’t follow the new process, or if we’re not aware of how to work in this new system, we’re going to get bad data. And that’s the place we never want to return to. Right? We just did all this effort to migrate this data and clean it. We want to stay there. And so, it’s just not a habit we want to continue to foster.

Support Framework Post Go-Live

But we all want to just get our work done. We all just want to move on to the next thing. And so what helps that? And what will prevent us from creating that band-aid situation we just tried to get away from, is setting up a support framework.

If I had had a support framework and knew who to go to, or who to ask when I had run into that challenge. I likely would have done that, and revisited the task at the end of my day.

We want our folks to feel supported, informed, empowered.

We want them to feel like they can navigate this transition, but when I run into my first roadblock, what do I do?

A support framework refers to a structured approach and tools implemented to assist individual users and teams during the adoption of the new technology, the new processes and the new roles.

It could look like a help desk for a large organization. It could look like an email address or a SharePoint form. It could be videos or job aids or a tips and tricks communication that comes out once a week based on that feedback we’re getting in our adoption plan.

Its goal is to ensure users receive the necessary support to navigate this new system, to navigate the change.

And why is it important? Well, research and experience show it helps with smooth transitions. It helps with user adoption. It minimizes disruption in the work. And most importantly, because we’re dealing with the people side, it builds users confidence if they know what to do when they run into an issue, or if they can go look up something themselves, they’re going to do it because they want to be successful in their job.

What can a support framework look like at your organization?

You know your resources and your culture should drive what components of a support framework you leverage. It’s just critical that you employ some combination. And that it’s well-communicated, so it becomes well-known.

A lot of times we spin our wheels, and we do a lot of work developing this support framework, and then we don’t communicate it, and it does not become well known.

The components listed here on this slide are ones I have leveraged in the past from my clients. Depending on the size of the organization and the resources that can support it, these are scalable. They play a crucial role in ensuring that your team has access to the information and assistance they need, and self-service options are really great if you don’t have a lot of capacity.

Regular office hours like a lunch and learn type thing are also great to do. We’ve done them remotely. They’ve been successful. Having standard operating procedures is very important. I know folks don’t have a lot of time to do these, but they are very important in ensuring consistency in the system use. Don’t overlook the importance of the emotional support and coaching.

Change is hard, and you should recognize that. People will feel uncomfortable, depending on their level of comfort with the technology at the go-live. Supporting them can go a huge way. And those lunch and learns, and those super users, they build community which really helps.

Outcomes

Outcomes of implementing this support framework – a lot of this is going to sound repetitive. But this influences those outcomes. Everything you can do to influence these things as part of your project is huge.

We’re minimizing user frustration because a well-defined support framework helps prevent users from encountering bugs or challenges without a proper resolution or knowing what to do.

We’re able to resolve issues faster because we know about them. A lot of times we hear after we’ve left, and folks will call us to let us know how it’s going. Users were struggling and running into these bugs, but they weren’t telling anyone, because they didn’t know where to tell. They didn’t know where they were supposed to put this information.

All of these things will improve user adoption because you’re offering the continuous support and the easy access to help. You’re also offering them the channel for feedback and change requests.

We talked about continuous improvement, and how important that is for the system to for continual adoption. Setting up a place for user feedback and change requests and having a process to manage those change requests so that they don’t just die on the vine is important.

All of this support is going to just help maintain your system integrity so that you don’t go back to that outdated solution, with the workarounds and the bad data, you want to prevent all of that.

And most importantly, it shows you where users are struggling with the system, the questions they’re asking, the support. You can see the training resources that are being accessed. This will all give you visibility into, maybe we need a retraining. Maybe this needs to be the focus of a job aid. Maybe we need a lunch and learn on this topic. And that’s really important.

Support Framework Challenges

Here’s a real life story about a client of ours who implemented a new learning management system. And they just didn’t have the right support setup from the get go. Despite us recommending a solid support framework, they had us construct the recommendation and kind of give them the how to do it. With capacity and time, and they just couldn’t get it executed. Not because of any malicious intention. They just couldn’t get it done.

Without that support framework in place, users started creating their own workarounds almost immediately. It led to inconsistent data, missed processes, making things more complicated than they needed to be. Data issues started to pop up. Training completion wasn’t being tracked correctly in the system, and some users weren’t even marked as having completed required courses.

They ended up bringing us back in to help, and while we could see there were gaps in training, we couldn’t just pinpoint exactly where the needs were, because we didn’t have that feedback loop of an adoption plan. We didn’t have a support structure pointing us to that.

All of this led to more frustration from the users. The lesson here is that even with the best technology in place, if you don’t follow through on setting up that support framework, it can create a lot of unnecessary headaches and ultimately hurt the system’s success.

Support Framework Success

In this case, the client rolled out a new online community platform, and the goal was to improve collaboration and communication among staff partners, affiliates and their members.

Right from the start, we made sure to set up a solid support framework. We didn’t just focus on the platform itself. We set up a ticketing system. We had a form that fed to their project management tool. There was a clear change request process which we communicated and let folks know about. We had job aids. We had lunch and learns.

We offered coaching sessions. The coaching sessions were really for the external stakeholders, and as time went on, we did a thematic analysis to pinpoint where training was needed and reinforce that training. When the platform went live teams, partners, and members had access to the support they needed, and it made the adoption process a lot smoother.

We got a lot of positive feedback from leadership about how supported everyone felt, and in the end this proactive approach led to a really high adoption rate and a positive takeaway feeling from all the stakeholders involved in the project.

I’m not sure if we have time for Q&A, Kyle, or perhaps we could follow up with some answers to Q&A or with a Q&A document, if there is Q&A in the chat.

Kyle Haines: There was only one outstanding question. That’s precisely what I offered to do is just follow up after the webinar, and I don’t see any questions in the QA. And you’ve been great at answering my questions and other folks’ questions along the way.

Debbie Cameron: Awesome. Well, I’m happy to follow up with anyone. You can find me on LinkedIn and feel free to message me with any follow up questions. https://www.linkedin.com/in/debbie-ann-cameron/

Kyle Haines: Debbie, thank you. I know that these webinars take a ton of work. I really appreciate you making all the time and all the engagement today. It’s demonstrative of how important this topic is and how much people are craving more information on this. So thank you so much.

Even though this is our last webinar. I want to be sure, like the other webinars, I left you with something that you might find helpful as you’re thinking about technology projects, a technology roadmap or just thinking about improving the way you work around technology.

It’s our nonprofit technology strategy framework. It’s an eBook. And this is the result of more than a decade of lessons that we’ve learned when working with nonprofits, associations and foundations just like yours.

I’d encourage you to take a look, even if it’s just a prompter for the future, as you think about all of the things that make technology change successful.

Obviously, in addition to the change management considerations that Debbie has gone through, I am going to quickly copy the link for this for those of you who do not have your camera handy. I’m going to send it in the chat and would love for folks to download it, and with that I’m going to wrap up this Webinar series. Debbie, thank you again, and thanks to everyone for joining us today.

Debbie Cameron: It was a lot of fun. Thank you.