Speaker 1: Hi everyone, Chris Ward here, your project management and IT service management edutainer from ITProTV. So glad you're joining us today as we learn about change management as a process. As a project manager in the past and an operations manager as well, there was one word that I used to dread, and no, it wasn't endoplasmic reticulum. The word was change. And I can see you all shuddering as well out there in ITProTV land. Change meant risk. Risk meant threats to the success of my project, or at a minimum, missing my deadline, shooting past my budget numbers. But in reality, change is going to happen. You can grit your teeth and bear it, or you can embrace it and use it to make your IT services or projects that much better. And as we look at today's IT projects and IT services, we see a much more agile approach to things. And in this video, we're not going to dive into change in the world of agile with spikes, scrum, etc. Instead, we're going to look at the change management process in a more traditional mode. Now, this doesn't mean that it isn't useful in your environment. In fact, the principle and theory behind change management or change enablement, as ITIL 4 calls it, is sound even in the agile world. So let's break this down. Change means risk. I've already said that. So one of the first things you'll really want to have in place to have a successful change management process in project management and IT service management is, drum roll please, risk management. Now, that is a whole other topic. But if you don't have risk management of some kind, look to see if you can't get that in place quickly. Now, when it comes to all the different standards and frameworks, you're going to notice that all of them follow a pretty simple pattern, as you see here. All change should start with a RFC or request for change. In that RFC should be several pieces of information that will be added to your change log documentation. Things like the who is asking for the change. That's really important. Is it the customer? Is it the CEO? Or perhaps it's the network operations guy. But no matter what, all RFCs should be documented and all stakeholders should be able to submit a change request. So we need to know what areas are affected as well. So we need to put down, is it hardware? Is it software? Is it workforce? Et cetera, et cetera. Now, some people will also want to categorize their changes like standard changes versus emergency changes. Setting good criteria and clarifying how and when they should be submitted, that could be a big help here. It's at this step that we also prioritize our RFCs if we have a whole bunch of them. Now, in ITIL 4, we break them up by impact and urgency. And then next, what we're going to do is have some impact analysis. And here's where you see professional change management people shine. It's not rocket science. Well, unless you work for Elon Musk and SpaceX, so then it might be about rocket science. But if you understand the competing constraints of cost, time, quality, risk, and scope, it's not that difficult. So let's take an RFC. Let's say that you are working on an infrastructure project where they're installing a new system. Now, the original spec said that the hardware needs to be hardwired to the network. However, you find out that there might be some historical buildings that you are putting some of this equipment into. And you know what? Using wireless might be less expensive and a better option. So we have a change. We need to do that impact analysis based on the competing constraints. Will it be more or less expensive to go wireless? Will it shorten the schedule since we don't have to run cabling in those buildings or maybe make it longer? What will the quality be like now that we aren't hardwired? Is it more secure to do wireless or less? See what I'm doing here? By using the constraints, we can do the risk analysis as well as understand the complete impact of implementing the change. Now, once you've analyzed the situation, you need to decide, is it approved or is it denied? Now, if it's denied, it's really important to document the whys of the denial. This is going to help in the long-term projects or delivery of IT services, as there might be someone later on that thinks of the same idea for change. By having all of that information at your fingertips in the documentation, you can decide whether to maybe analyze it again, maybe some time has gone by, might be wanting to look at that a little bit, or simply point to the original denied decision. But let's say that wireless change looks good from a budget, schedule, and quality focus. You will approve the change and then hand it off to the appropriate team to implement the change. Now, implementation can be a simple flick of a switch or it might require more in-depth planning. Regardless, this is where the rubber meets the road of that decision that you've made and can also introduce some more risks that weren't identified before. So keep your eyes open and listen to those people that are doing the implementation. There might need to be some slight modifications to that original RFC. If they go out of tolerance, you might actually need to stop that change, resubmit the RFC for further analysis based on the data that you've picked up in that initial implementation. Now, finally, there is the review and reporting stage. Now, this is where you look back and you see how successful that change was as well as maybe doing a retrospective or lessons learned. Never just implement the change and then just keep on going. The more you learn from successful and failed implementations, the smoother and less disruptive the future changes will be. Then it's time to start all over with, you got it, more changes. Listen, I understand how disruptive change can be to your operational routines and just day-to-day keeping things running. But the beauty of technology and why most of us chose this industry is that there is always something new. Plus, if you can get a good change management or enablement process in place, it won't be as disruptive as it was before. Your projects will be more successful, your IT services will be delivered with value. Hey, that's awesome. So thanks for taking the time to watch this and check out ITProTV's huge lineup of project management and IT service management courses at www.itpro.tv. I'm Chris Ward and now you have a better understanding when it comes to change management. you