Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: IPhilipp
New Today: 7
New Yesterday: 82
Overall: 143836

People Online:
Visitors: 61
Members: 4
Total: 65 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - Question: tickets for each site as part of a release?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

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

 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  

For multi-site deployments which interrupt service
Open and approve a change ticket for every site?
30%
 30%  [ 4 ]
Use only the original RFC and good project mgt and communications with users
46%
 46%  [ 6 ]
Open a single and review a single RFC AND then a "planned maintenance ticket" to track the service outages
23%
 23%  [ 3 ]
Total Votes : 13

Author Message
ITILKH
Newbie
Newbie


Joined: Oct 10, 2007
Posts: 9

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

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
Back to top
View user's profile
AlphagamerTyson
Newbie
Newbie


Joined: Dec 13, 2006
Posts: 14
Location: Belgium

PostPosted: Wed Oct 10, 2007 5:04 pm    Post subject: Reply with quote

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 ...
Back to top
View user's profile
Ed
Senior Itiler


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Wed Oct 10, 2007 5:17 pm    Post subject: Reply with quote

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
Back to top
View user's profile
OhioScott
Itiler


Joined: Oct 29, 2007
Posts: 26

PostPosted: Tue Oct 30, 2007 3:19 am    Post subject: Weighing in... Reply with quote

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...
Back to top
View user's profile
Mark-OLoughlin
Senior Itiler


Joined: Oct 12, 2007
Posts: 306
Location: Ireland

PostPosted: Wed Oct 31, 2007 8:28 am    Post subject: Reply with quote

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".
Back to top
View user's profile
Ed
Senior Itiler


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Tue Nov 20, 2007 12:45 am    Post subject: Reply with quote

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
Back to top
View user's profile
Mark-OLoughlin
Senior Itiler


Joined: Oct 12, 2007
Posts: 306
Location: Ireland

PostPosted: Tue Nov 20, 2007 2:29 am    Post subject: Reply with quote

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
Back to top
View user's profile
Ed
Senior Itiler


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Tue Nov 20, 2007 5:50 pm    Post subject: Reply with quote

Mark-OLoughlin wrote:
Hi,

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?

Regards

Ed
Back to top
View user's profile
Mark-OLoughlin
Senior Itiler


Joined: Oct 12, 2007
Posts: 306
Location: Ireland

PostPosted: Sat Dec 01, 2007 12:11 am    Post subject: Reply with quote

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
Back to top
View user's profile
Ed
Senior Itiler


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Sat Dec 01, 2007 1:05 am    Post subject: Reply with quote

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
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.