January 03, 2024

00:09:24

Changes, What Changes? E72

Changes, What Changes? E72
What Counts?
Changes, What Changes? E72

Jan 03 2024 | 00:09:24

/

Show Notes

Changes, what changes? What do you do after you tested your organization for implementation readiness? Be prepared, remain flexible, and make sure your change management person is ready.
View Full Transcript

Episode Transcript

[00:00:01] Speaker A: You measured your organizational readiness from a people, process and technology perspective. Now what do you do? Hello. Thank you for joining us. This is what counts. A podcast created by Trailblazer Consulting. Here we highlight proven solutions developed through our experience working with companies across various industries. We talk about how you can apply these solutions to your company. We share our experience solving information management challenges like creating and implementing a records retention schedule, creating an asset day hierarchy, or helping with email management. This is Lee, and in this episode, born and I will discuss what to do with what you measured. I like that. [00:00:43] Speaker B: I like that, too. Yeah. Because we can measure all sorts of things. It's one of those consulting truisms. Whatever can be performed can be measured. But is it a meaningful measurement? And what we often find is some things that are easy to measure are meaningless. So let's talk about people first. We did this survey about were people ready? Were people understanding their new job? Were they accepting the change and ready to go? And we found out they kind of wanted the change. They sort of understood what they were supposed to do. They said they were ready. So, okay, having done this a lot of times, we know that that first level of acceptance is not going to last and that we might need to do something about. We might need to do something later. So what do we think about Lee? You mentioned last in one of our earlier episodes, we had a run of discussions about change management. We talked about communication and training. We talked a lot in the early days of our podcast about champions and getting help from across the organization to spread your message and support what you're doing. So revisit all those, bring all those factors to bear all those tools back into your toolbox here to help get people ready, get through the first level of resistance, move forward. Get to the second level, move forward. When it comes to training and a new technology, new process, I think it's also good to give people something tangible. So a quick reference guide or a help sheet, quick tips and tricks sheet or help messaging in the system where they can actually pick stuff up. So I think for the people side, it's classic change management and organizational change help kind of thing. On the process side, we already said that's the most straightforward. Look for a more efficient process. Figure out how to leverage the technology to automate the process and enforce your rules. Getting it ready is easy. Getting people to understand and follow it. That's where your change management comes in. The thing we haven't talked about yet is structure and roles and responsibility. When you're looking at new process change, you might have to think about, okay, is there a role here that didn't exist before and now we need somebody to do something different. We need a whole new thing to happen. Or bringing together a bunch of manual processes and leveraging technology eliminates a role. And it might require a change in organizational structure. That's a big deal, and that's going to be harder for people to accept. And so your champions become really important there so that people in process, organizational change, organizational structure, it ends up that you have to work on those things together because they can't really be separated. The one that can still be handled kind of alone is the technology piece. And there's a couple of techniques that we've seen that are effective pilot or proof of concept. And I think it's worth spending the time to go into the differences between those two and the approaches to them. Feel like that's a different episode. [00:04:08] Speaker A: The only thing I was going to add is you may not know that a change to the people, that's how I'm phrasing it right now, needs to occur at the beginning of the project. Meaning you're implementing a software package that's pretty huge. Maybe it's a contract lifecycle management system or something like that. And as you're going through it, you start to see, hey, we need this whole role to be developed, a new department to be developed. And so that gets created. And not that you didn't know change was coming, but you didn't know that that whole role was going to be necessary. And so you start to change people's mindsets on where this needs to go during the process, using your champions, making sure they understand that this is where it's now headed. And we need this particular department or person to do something specific. [00:05:11] Speaker B: Yeah, I like that point. Because in some ways, we're not going to know all the answers at the beginning of the project. Knowing that process has to change, process has to become more efficient. That's an easy thing to see. But then when you get deeper into how are they doing it today? Who's involved? What are all the manual steps and workarounds that are happening? The need to change roles, really change roles. Like eliminate a role or add a role or change a structure so that you can meet requirements like segregation of duties under Sarbane Zoxley, or you can not overburden one person who turns out has been working 17 hours a day. And actually, you might want to have them only work a normal eight hour day. So things like that are going to come out when you start digging into the details of the current state, and you don't know that at the beginning. And that's an important messaging to get across to people as you're going through the project. Because the first phase of your project is a discovery phase. It's a discovery phrase around the data, the legacy data. It's a discovery phrase around the legacy people side and the processes. If you're smart, you're going to do that discovery, and then you're going to change your plan as needed. And that doesn't mean that your plan was bad. It means that you knew at a high level the things that needed to be done, and you had anticipated some of what you were going to encounter, but you couldn't anticipate everything. So you have to be prepared to really listen to the results of that measurement step and say, okay, we learned something new. What does that mean and how do we go forward from here? And I think that's an important thing for your project team to understand, which is one of the, and I actually should have mentioned this in the readiness step is your project team has to be ready, too. They have to understand what's involved and that you're expecting it to change along the way. And what are the dependencies that you know about and what are dependencies that might come up. And so an experienced project team will handle that change. The SMEs that you've pulled in from the business that are being affected, and they're now part of your core team. They may not be ready for that change, for that constant, that flow of change to the project that's going to keep happening. And so they need a different kind of approach to say, hey, this is not a surprise. And also, just because we're here right now trying to figure this piece out doesn't mean this is how it's going to be at the end, because that's another thing that often comes up during projects when you pull in SMEs, is they think that your first idea is the end game, and can't we just get to the end? And we can't. These projects are complex. They take a long time, and you learn along the way, and the end game is going to be a little different. It's going to be largely what you looked at from the beginning because otherwise, why are you doing this project? But some of the details are going to be different. And getting stuck on, I hate that. I hate that. I hate that. And telling everybody how panicky you are about it is not going to be helpful. So that project team focus of readiness is also important. [00:08:51] Speaker A: I completely agree. I think it's trust in the process. That's what needs to happen. [00:08:57] Speaker B: That's a good place to stop. Trust in the process. [00:09:01] Speaker A: If you have any questions, please send us an email at info at trailblazer us.com or look us up on the web at www. Dot trailblazer us. Thank you for listening and please tune in to our next episode. Also, if you like this episode, please be a champion and share it with people in your social media network. As always, we appreciate you the listeners. Special thanks goes to Jason Blake who created our music.

Other Episodes