Question: tickets for each site as part of a release?

[ITILKH]

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.


Thanks.

- Kevin

[AlphagamerTyson]

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

[Ed]

Hi Kevin

we use the single RFC / Multiple Release approach.

At RFC time the business case is laid out, for the Change to be approved in principle.

At Release point each outage is approved separately so that the business knows when the outage will occur and for how long.

Each release is entered into the Forward Schedule of Change as an individual entry, again giving maximim visibility.

I believe that in this way we have the flexibility the business needs to understand and concur with each phase of the Change.

Equally Change Management has the control that we need. We understand exactly what is happening, and when!

We also have a detailed audit trail of all the work done.

ITIL states that you can have multiple releases to a single RFC - hence our approach.

I hope this helps

Regards

Ed

[OhioScott]

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

[Mark-OLoughlin]

Hi,

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".

[Ed]

OhioScott / Mark-Oloughlin

I don't see the need for the child RFC in this case.

From my perspective the business case should be the same for each site, whereas the implementation may well vary, giving the need for a separate release doc for each site.

I populate the FSC with each release in the same way as I would with a multiple release single site Change. For me there is no difference between the way I would handle either type of change.

Am I missing something, or is it simply a different approach?

P.S. I amnot constrained by a tool as my system is on paper, is this perhaps the difference?

Regards

Ed

[Mark-OLoughlin]

Hi,

an update:

"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

[Ed]

[Mark-OLoughlin]

Hi Ed,

I do see your point which is valid.

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

[Ed]

Mark

I have re-read my posts and realised that there are some details that I did not make clear, which may clarify my thinking

1st we are a Service Provider with 30+ external Customers, so 1 Account Manager per Customer

2nd Our system is paper based and does not feed into any tool.

Apologies for the omissions - It's just me getting old!

I can see what you are saying about transparency and reporting - I will have to give this some serious thought.

Regards

Ed