Release mgt vs. RFC vs. outage tickets

[ITILKH]

I am wondering what the general opinion and practice is for something that I have seen done different ways with strong beliefs in each direction.

scenario: an RFC covers a deployment that will happen across multiples sites/machines over a period of time, causing an interruption of service each time (e.g. major server upgrading). How do you actually handle the tickets in your service management suite and what is the most consistent with ITIL?

One company that adopted ITIL has a policy for planned vs. unplanned activities and their rule is that anytime you plan to take CIs out of service, you still open a "planned maintenance" ticket for the action. Hence even though the initial RFC may have a deployment schedule, the implementers still have to open up new change tickets every night they do work (one ticket refers to multiple CIs), but only the work that can be done in the maintenance window. They were working on creating a parent/child relationship between the original RFC that came from the CAB and the child tickets covering the work in each maintenance window, but I don't know if they made that happen. You get lots of tickets this way that are all part of the same logical change management decision and release implementation.

In contrast, another company I know says that ITIL only requires that you get an approved RFC to cover the entire deployment. Hence, the RFC includes the deployment schedule. In their case, when the deployment team gets to the site at the scheduled time, they take down the affected infrastructure and implement the change and keep moving. There is no separate ticketing for each site and no separate ticket tracking the induced outage. The project manager for the release keeps track of the progress and supposedly documents it all when they close out the RFC. You don't have much visibility in their situation into the actual activity affecting a CI at a given time. The RFC will just show the time period of the overall change activity for all of the affected CIs.

How do others out there handle this type of situation?

Thanks.

- Kevin

[ITIL-Kahuna]

Here is a good example of ITIL telling is WHAT is important and WE have to figure out the HOW, and many HOWs are paths we can follow.
As to Change Mgt, what is important is to keep the objective in mind. Basically this comes down to 'Implementing as many changes as needed with minimized impact to the business and acceptable risk (by using a standard approach)'.

This being said, we also need to understand the difference between RFC, a Change, and a ticket in a tool. RFC of course is the REQUEST for a change. For example 'Relocation of employee from site A to site B'. You can see that this request may imply multiple changes, Desktop, User attributes, phone, etc. You can enter this into the tool as 1 change TICKET (or Service Request ticket) with multiple work orders (changes) attached. You then can decide that you can approve this change as a whole (in this simple example that makes sense) or you can decide to group some changes to a release and track (and authorize the implementation) as a release (group of approved changes).

In the end, the decision HOW you implement the WHAT (ITIL) we need to do is organization specific. By the way, bare in mind that how you want to measure your process (Key Performance Indicators) also determine how you track things in your tools. For example 1 change that includes 100 different servers to be updated versus 100 changes each for a server update. In case 15 updates go wrong, what will the KPI metric show in the first example versus the second one. (0 succesful out of 1 change = 0% versus 85 succesful out of 100 = 85%).

Let me know if this helped or want to discuss more.

[ITILKH]

Great points. Thanks so much. They make a lot of sense.