Jack: Welcome, this is Jack Mansfield with another episode of Transformative IT Service Management. Joining me today, actually I have two guests today, again joining me is Brenda Lichtenberg Senior Vice President of Strategy and Portfolio and also joining me today is Matt Selmans. Matt Selmans is a Senior Service Management Process Architect here at Bell Techlogix.
Today we’re going to dive into the topic of change management. Previously we talked a little bit about incidents and then recurring incidents that become problems but ultimately when you have a problem you need to do something about that and I guess that brings us to change management. So Matt just kind of at a high level what is change and what is change management?
Matt: A change is any addition, modification, removal of anything that could affect an IT service. So when I think about a change as opposed to an incident, it’s that broader scoping impacting at the business or system level as opposed to where an incident is generally more of a single user type of an occurrence. Just couple of examples an update to a version of an application would be generally considered a change.
Matt: When you’re looking at those, you’re looking at; Is there going to be downtime associated? Do we need to communicate transition training plans for functionality changes?
Jack: Well, that communication can be a really big key especially when you talking about changes. And I think a lot of the times what business users have as a challenge with change management is that communication. Do you think that’s true?
Matt: Absolutely. And I think it’s a critical component of the development of your chain of process to ensure that communication is a part of that. That during the build and testing phases you’re also building and testing your communications plan, to ensure that you have all the right tools that you’re providing your business unit, to ensure a complete and successful change.
Brenda: And that really includes some of that back office groups. For instance, making sure you involve the technical manager, you involve the business manager, and then also of course, the people actually making the change, and then all of the different components thereof. For example, some of the fallback plan. What happens if the change does not go successfully? Then we’ve tested our fallback plan and everyone knows what that is so we can execute it accordingly.
Jack: That communication plan sounds like it involves a lot of people, not just IT. Is this connected to organizational change management?
Brenda: It is, yeah. For organizational change management it’s very important that you know when a change is coming, how it’s going to affect your end users, and they know what to do when that change occurs. If your end users are not informed and don’t understand what that change is they will be very slow to adopt the change or if they recognize that something is working differently, they may think it’s broken and they’ll call the help desk to get it corrected. So organizational change management is very key.
Jack: That’s a really good point. We’re talking a lot about the business users side of change management, right? The business users are gonna get the effect of the change and obviously the people who are doing the change are the IT departments and one of the things that when you just think about what is a change and how does it go through; so somebody’s requesting the change and somebody’s approving it. Matt, can you tell me a little about that change approval process?
Matt: Sure. So in a formal change management process, you’ll generally have a change manager and also a CAV or change advisory board. So within that change advisory board, that would include your change manager who’s going to actually be kind of the one that they create the agenda and they’re running the meeting, in general. Included in that CAV, you’ll also have your business unit leaders so that they can bring in some of the knowledge of the business. How this change is going to impact our business as opposed to just the IT components of the change.
Jack: So the business users are even involved in the process before it’s even approved
Matt: Correct. Because we need to make sure that we know what we’re impacting. As the IT organization as well as ensuring that they’re involved early enough in the process so that we can get it communicated appropriately, training, and again transitioning, especially when there’s functionality types of changes.
Brenda: And really that, kind of, lends itself also to other changes; change complex, right? So if we notify everyone ahead of time then we also realize that, hey, there could be other changes in the pipe. The change control board or the pre-approval board that looks at all of the changes coming in; so if you’re a technical leader you may know that you have three changes going on on Saturday night that you want to make sure that they don’t conflict. Or if in fact, you need them to all happen at the same time for consistency reasons or technical reasons then you schedule that accordingly.
Jack: Or even business reasons, right? If you have that business leader as a part of your change approval board they may know that, you know, there’s a big, month-end reporting thing that’s coming in that would mean down time on a specific database might cause a business conflict and may prevent them from being able to get the business side actually done.
Brenda: Right. Many of the business sides have many requirements that say, you know what? We cannot take an outage during prime time hours. And purposely will schedule your after hours activities, releases, upgrades, patches, that type of thing on a weeknight or during slow volume times.
Jack: That’s a really good idea. Now, Matt, once the board approves the change and we get it sort of scheduled on the change calendar. Then we’ve got to actually have our developers or our engineers execute the change. Is it easy to get those engineers to buy into the process, the documentation? Sometimes is it viewed as too much red tape?
Matt: It always initially, especially when you’re just implementing a change process, there’s a hurdle there. To get people to adapt and understand the reason for the red tape, right? But as long as you’re consistent, and it’s a top down, sort of, a buy-in to the process that’s probably the most critical component. We need to make sure that you’re not doing some of the process for some people and some of the process for other people. It has to be consistent. We have to ensure that as we are developing the process that we are thinking about those enforcement points and what we’re going to require of all of our change owners, our change implementers, and clearly communicate the expectations to them about what those requirements are.
Jack: Now, is there a way within the change process for change implementers to, sort of, get changes fast-tracked where they don’t have to go through the big normal rigamarole of approval. I’m thinking of things like routine server patching-
Matt: Right, exactly-
Jack: … and things like that.
Matt: So in change management, you’ll have different types of change. Generally you’ll have what are considered normal changes, that’s the full on process of documentation approval, all of the normal steps, right? But then there’s also what’s considered standard change. Standard changes are ones that, an implementer can come to the change manager and say “Hey, we’ve got this repeatable process that we do every month.” Applying patches is a good example, where I can document step by step exactly how we do this every single time. Those then can be presented to your change advisory board, review all of those steps, ask the questions you need to, but then they become pre-approved. So that the next time that that implementer wants to implement that change, they’re going to still add that to your change calendar so we can ensure that there’s no conflicts with other changes that are occurring at the same time, but it’s pre-approved. It doesn’t have to go back through the change manager or the CAV before that change can be implemented.
Jack: You mentioned a word there that I think is a really good point, and that’s conflicts. You know, when you don’t have a mature change process, it’s possible that you would have implementers or engineers putting in patches or changes to not necessarily the same system, but two separate, connected systems that might have an unintended impact. If you’re not having that communication, if you’re not scheduling it out, if you don’t have a good test environment where you can see how these things will interplay, then you might have a problem. And that leads us to where we might be going in a couple weeks, which is major incident management. If you’re doing a change on a big system and something goes haywire, that can have a real major impact into the business.
Brenda: There’s also another component of change management, and that would be the emergency change. Matt talked about having a standard change, the emergency change also does allow for some of those urgent situations that crop up unexpectedly. You may be having an outage window right now and all of a sudden one of those unexpected situations happen and you need to make an emergency change. In that case, sometimes the change needs to be made now. You get the proper authority to make the change and you may fill out the emergency change after, actually, you make the change. As much as possible, though, we try to make the change at the same time as you’re putting it in so we make sure we have all of our “I’s” dotted and “T’s” crossed.
Matt: Just like we were talking about the CAV previously, the change advisory board, most times an organization will also identify an emergency CAV. A select group of people to be notified when we are having that down-time, system outage, during business hours, we still want to have, if possible that little bit of thought before we move and make that change. So that E. CAV will extract some of that additional detail. A little bit more thought into the change before going ahead and implementing.
Brenda: So it’s very important that that is thought of ahead of time and that you have the process well solidified and E CAV people designated so very important part of change management.
Matt: It is still a critical component, even if it’s after the change has been completed we always have to make sure we’re documenting. In emergency situations and latent changes are as critical to document as a normal or a standard change.
Jack: Well, and if you don’t have that documentation then you have another type of change, which is the worst kind of change and that’s an unplanned or an unidentified change, and that could lead to a host of problems down the road. I guess, you know that documentation is a really good point. I’ve seen a statistic that says upwards of 70% of all change initiatives can fail. Do you think this is related to poor documentation, poor change management?
Matt: Absolutely. I think of that as being more in organizations that are thinking more in terms of change control as opposed to the formal change management process. In change control, it’s an informal, you know there might be a meeting, but we’re just discussing what’s happening, not why is it happening? Who’s impacted? What is our risk? That’s an important component of having a formalized change management process. And a part of that, as well, the documentation, documenting pre-implementation and post-implementation. Do we have a fully vetted build plan? Test and validation, and implementation plan as well as, and possibly most critically, do we know how we’re going to back out or remediate if there’s an issue? And then post-implementation getting your end users to validate that the expected results occurred from your change. And that you’re documenting from your implementers exactly the steps that they took. Especially so that in the event that something down the road happens, another incident occurs, we can go back to that change, identify what happened and maybe identify why we’re now in the current situation, the current incident that we’re trying to work.
Jack: So Brenda, I know we’ve talked in the last couple podcasts about some different types of analytics and we’ve talked a little bit right now about how changes can fail. How do you measure and see the successes on change?
Brenda: It is kind of related to the analytics. You’re going to run your analytics to say that you’ve been seeing these problems, and you potentially are making a change because you’ve been seeing these problems. Therefore, after the change again you will run analytics and you’ll see if that problem is still occurring, maybe your change was not successful. Matt was kind of quoting the importance of after you have put a change into production you need to test that in production and make sure that it works. But there is sometimes conditional type items that cause that to fail. Your analytics will then be a great viewpoint to be able to pull that out and say you know what, there is still something not working right. We’re still trending high in this area, we need to really look at why that change was or was not successful. If it is successful then great, then you should see an immediate drop-off from what that problem was causing previously.
Jack: That’s a great point.
Well, thanks for tuning in to this episode of Transformative IT Service Management. I want to thank Matt and Brenda for joining me for this discussion on change management. Tune in next time, when on our next podcast we’re going to dive into the topic of service request management. How users can more effectively get the new hardware, software, or maybe even new access that they need.