Use only the original RFC and good project mgt and communications with users

46%

[ 6 ]

Open a single and review a single RFC AND then a "planned maintenance ticket" to track the service outages

23%

[ 3 ]

Total Votes : 13

Author

Message

ITILKHNewbie

Joined: Oct 10, 2007Posts: 9

Posted: Wed Oct 10, 2007 2:16 pm Post subject: Question: tickets for each site as part of a release?

Hi all. 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.

Please help me by letting me know what you believe in and why? I'm unsure of what is best

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? I couldn't find that level of detail in the V2 or V3 books, which implies to me that good management of the deployment within the encompassing RFC may be sufficient from an ITIL defintition.

I can imagine it depends on company and the tool(s) used which of the possibilities you describe.
The best working way I have seen so far for comparable situations is that there is one Change record which describes and covers the whole deployment, but with different tasks for each different intervention.
The deployment's change record would typically cover the whole period, but each task would only describe the impact of that specific intervention.

if your tool doesn't allow you to work on two levels (let's call it rfc and sub-rfc) you would always need very good communication in order to refer to the higher or lower level planning ...

I've used the single RFC with multiple releases controlled via Project Management but prefer the ability to manage via parent/child RFCs.

I don't know how familiar you are with this, but the idea being that you have a single RFC that is the parent with sub-RFCs as the children that equate to the various deployment dates. The parent RFC is what gets reviewed and approved by the CAB, the children, representing the deployment dates are what get approved prior to implementation by the Change Manager based upon the current circumstances.

In this manner, all are listed on the Forward Schedule of Change for planning and communication purposes. You maintain control as well, specially if you don't have a well defined Release Management process in place.

I'm not sure which tools support the parent/child RFCs at this point. We were working with Peregrine ServiceCenter prior to the HP takeover. I changed jobs shortly afterwards and haven't kept up. But I'm sure someone has it...

I agree with OhioScott. Parent RFC to approve the overall change and individual ones for each site to get the activity on the FSC and aid n the comunications thatare required for each service disruption. If your tool cant relate changes to changes you can at least reference the parent ID in the child records in a text field and use a view or DB query to see the "relations".

"From my perspective the business case should be the same for each site, whereas the implementation may well vary"

Business Case needs to have approval to approve the overall release programme cango ahead and can have the resources and money and time etc. It is also to approve the overall risk and perhaps overall downtime etc.

Implementation needs to have specific change request which will in effect provide for approved "change windows" to implement the release in different "pieces". Regardless of tool based or paper based capabilities you needs to have approved change windows to implement changes.

A change window is an approved time period to carry out an approved change to the detail of that change request. The change window should reflect the time and duration of when the change will take place. it is also to be realistic, i.e. if the change takes 4 hours you specificy your 4 hour window. You dont specify that the change will take place for 4 hours between monday and wednesday some time.

The reason is that the FSC shows the change windoes which in effect shows the implementation plans of all changes for the business. In you case the child changes are in effect changes that need to have a change window approved. Where you can do multiple changes at the same time and in the same window you can add these to one change as long as you identfy in this case the locations of each piece of work.

The important thing is about getting the correct and accurate information about what is changing, when it is happening, who is affected and what is the impact. I don't think release doc's will cover this as good as change requests._________________Mark O'Loughlin
ITSM / ITIL Consultant

A change window is an approved time period to carry out an approved change to the detail of that change request. The change window should reflect the time and duration of when the change will take place. it is also to be realistic, i.e. if the change takes 4 hours you specificy your 4 hour window. You dont specify that the change will take place for 4 hours between monday and wednesday some time.

--------------------

The important thing is about getting the correct and accurate information about what is changing, when it is happening, who is affected and what is the impact. I don't think release doc's will cover this as good as change requests.

Mark

I see what you are saying, but this is only true if you do not specify a timetable! We expect a four hour change at each site implemented by the same technician to follow a timetable. i.e site a on Monday at 19:00, site b on tuesday at 19:00 and site c on Wednesday at 19:00. This gives the control, and detail that we need, without the need for child RFCs and the additional sign off needed for them. Why would I want the account Manager to sign 3 times for what is effectivly the same change?

From the perspective of reporting on your change activity back to the business you can only report the one change i.e. the main change request becuase you don't have the others logged s individual changes. So even though you are doing "lots of changes" it appears as one overall change. I know, i know you can manually add to the figures but should you have to?

If the change at site A goes ok, site b goes bad and site c goes ok. You can onoy relate the problem record to the over all change even though it was only a part of that change that was the casue. This is not as transparent unless you have individual changes.

"Why would I want the account Manager to sign 3 times for what is effectivly the same change? " - Are there different account managers for the sites or different facilities managers etc. that need to know. Are any of the sites considered critical and must have no downtime like sites supporting production plants etc. that need to be treated differently. An on it goes ......

You are not wrong as you are recording at least the overall parent change. I do like to see the next level of activity also logged for many different reasons som eof which have been discussed here.
Anyway, best of luck._________________Mark O'Loughlin
ITSM / ITIL Consultant