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


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: ArturoHerl
New Today: 17
New Yesterday: 43
Overall: 231632

People Online:
Visitors: 135
Members: 0
Total: 135



Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

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.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - Wait periods after change implementation
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Wait periods after change implementation

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

Joined: Jun 06, 2010
Posts: 10
Location: Canada

PostPosted: Mon Jun 07, 2010 7:20 am    Post subject: Wait periods after change implementation Reply with quote

Hi everyone!

Just want to get some feedback on change closure times from you all who have experience with change management. Currently, in our organisation we have change closure periods; essentially, after implementing the change you report the RFC status to CM (successful, successful with issues, failed) and then the wait period begins (warranty period or stabilization period). The length of the wait period depends on your risk level. The problem we're currently experiencing is that 1st notification after implementation reaches 85-90% of the times. However, 65% of the requesters "forget" or don't have time to report the outcome of the wait period... basically the RFC cannot be closed without the 2nd notification and I have to spend 1-2 hours every month chasing people for their notifications. Do you all have wait periods or do you close the RFC immediately after implementation?

We've been reporting the late notifications on our monthly stats and KPIs and management doesn't seem to do much about it. I've had workshops and training sessions with the end users but this is something they can't seem to follow through on. If it was up to them they would get rid of the wait period. Your comments on this? Is there any value in keeping the wait period?

Thank you!
Back to top
View user's profile
Senior Itiler

Joined: Mar 04, 2008
Posts: 1894
Location: Helensburgh

PostPosted: Mon Jun 07, 2010 6:41 pm    Post subject: Reply with quote

There is no point in having a "wait" period unless there is something to wait for and in many cases there will not be anything to meaningfully wait for beyond verification.

The decision as to what condition satisfies change acceptance (e.g. waiting to see if some event happens , or doesn't happen) beyond verification, has to be made by the change board and put in the change plan. It therefore becomes the responsibility of whoever is responsible for implementing the plan to ensure that all steps are complete. Actions put on users, customers or IT service staff still need to be driven by the plan manager (who may be the change manager, but not necessarily).

If you have thought out a specific reason for "waiting", then it should be fairly easy to devise a method for completing the "wait".
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail
Senior Itiler

Joined: Dec 15, 2007
Posts: 117

PostPosted: Wed Jun 09, 2010 12:54 am    Post subject: Reply with quote

There is a wait period which is normally due to requirement of the change to be verified by the business stake-holders. If its not required by business then it should not be there. Also, as Diarmid said we can't rule out exceptional circumstances like Microsoft asking you to wait for a while to see the patch they recommended actually patched.

"the only statistics you can trust are those you falsified yourself"
Winston Churchill
Back to top
View user's profile Send e-mail

Joined: Jan 28, 2010
Posts: 33

PostPosted: Thu Jul 22, 2010 7:40 pm    Post subject: Wait Period - Long ones are not necessary Reply with quote

Every change implemented into the system needs to be validated for sure... Most time by the stakeholders (business). So generally, the wait period is kept as the tme point in time when the business resumes its services and find all fine... before which .. i.e. immediately after the implementation of the change, the implementer validates the change for its successfulness and determines whether to call this change a success or unsuccessful (which is almost most times the right decision made). Business validating the change is just a secondary confirmation as one should really not rely on just the technical implementer of the change. However, this wait should not be any more than few hours from the time business resumes the service....

Any change should be resolved - by the technical team the moment the change is implemented and validated by the implementer and found successful.

Once the business resumes its service - which is generally few hours from the time of implementation (say the next morning) or max the coming monday (if the change is implemented during weekend), the implementer need to confirm with the business stake holder to ensure that the objective of the change is met and has not trigged any adverse side effects. Once this is confirmed, the implementer can close the change...

Any change not closed within a day of the business resumption should be brought for PIR by the change management team and reviewed for the reasons on resolving the change (means implementing the change) and yet not closing it to understand if there was a business impact - if so - what and why and derive the lessons learnt to be used in future and advise on this change-

Because, if the change is not closed as successful within 24 hours from business resumption - the change is more likely to have traiggered an impact to the business and should be closed as unsuccessful

I hope I have answered
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

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.