Posted: Mon Jun 07, 2010 7:20 am Post subject: Wait periods after change implementation
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?
Joined: Mar 04, 2008 Posts: 1890 Location: Helensburgh
Posted: Mon Jun 07, 2010 6:41 pm Post subject:
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
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. _________________ regards,
"the only statistics you can trust are those you falsified yourself"
Posted: Thu Jul 22, 2010 7:40 pm Post subject: Wait Period - Long ones are not necessary
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
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