In this video, Instructor Mark Thomas presents how he visually creates a graph to help manage projected Service Outages in order to effectively communicate with the Change Advisory Board (CAB).
The process called change management is a tough one to get down. One of the things we talk about in the ITIL Foundation class is the whole idea of what the process is, why it exists, and some core activities as a part of the process.
Projected Service Outage / Change Schedule
Two things that the change management process produces are, one is called the Projected Service Outage, and the other is called the Change Schedule.
I had some challenges with the change schedule in an organization I was in. For us, changes were like the Wild West. People were dropping modifications into my production environment at all times of the day.
We had to get some control over how we applied modifications to my targeted environment, so we created a formal Change Schedule with change windows, or these apertures of time, at which we could approve and schedule modification into the production environment.
To give you a snapshot of what we did, basically what happened in our organization, we ran our our Change Advisory Board (CAB) on Tuesdays.
What you see here is a running calendar, Monday through Friday, Saturday/Sunday, Monday through Friday, Saturday/Sunday, and so on.
This was a running calendar that we kept track of all the current and future plan changes.
We did our CAB. What we were talking about is upcoming changes. When we scheduled those changes, they went into one of two Change Windows, or Release Windows, that we scheduled on a weekly basis.
The first one we did was on Wednesday night. It was a very small window.
This was more of a maintenance‑type of window, Wednesday night where small changes went in. These normally were not very highly complex, but they were changes that had to go in, and we could schedule those into this aperture or this change window.
We also had another window scheduled over the weekend. Notice this one’s a little bit bigger.
This is where we did larger changes, more complex, and sometimes medium‑size releases would go into each one of these windows.
As we would evaluate our Change Advisory Board (CAB), when we were looking at when we needed to deploy certain changes that were being requested, we could now figure out, based on our forward schedule, where we could actually place these changes in and build ourselves that change schedule that we were going into.
That doesn’t mean we can’t violate these windows. Sometimes, changes are required that can’t fit into one of these windows. Therefore, with the proper approvals and the right business case behind it, we could create an additional change window for a specific change.
Again, we had to address the risks of those, and so on.
If you come to my CAB on Tuesday right, we could actually schedule you into any one of these future windows that was the most appropriate for not only you, and appropriate for the organization from a Risk Management perspective.
This is one of the things that we talk about in the Foundation class for ITIL. Change Schedule, many of the things that we talk about, that we dive a little bit deeper into it so you can take this information to work tomorrow and use it effectively.