Page 1 of 1
How is a change window determined for an event?
Posted: Wed Nov 19, 2014 4:02 pm
We are in the process of putting together a procedural definition of event 'change windows' in order to narrow down the windows scheduled for our changes.
Typically, are windows determined by the length of time needed for just the change itself and service verification/backout period? Or is there usually an additional monitoring period included as well?
Posted: Sun May 03, 2015 7:43 pm
The 'testing' phase of a change implementation could include an activity of monitoring also.
It depends on what the change policy views as monitoring?
If the monitoring period extends over a matter of days, weeks etc...then that's a bit of a stretch to include in the window.
Perhaps the monitoring phase is performed under operational activities for a set period?
ie: the change windows is 5 hours. Once the change window is complete and the change is in operations, then the 'monitoring' is just performed as an operational task and any events that are triggered are managed accordingly.
Posted: Sun May 17, 2015 7:26 am
Think it through
the change window should be the total time for the implementation and roll back of the change. Nothing more. Nothing less.
If the change requires a week of burn in, then, to be honest, you will have two change windows - one for doing the work and one for undoing the work
Of course, this depends - as estaclaut states - on your change mgmt. policy and operational restrictions
Posted: Wed Mar 09, 2016 7:24 am
First We should need to process of putting together a procedural definition of event change windows in order to narrow down the windows scheduled for our changes.
Posted: Tue Sep 06, 2016 2:22 pm
I like UKVIKING view point.
rule of thumb for our change activity is all changes have a warranty period. If a change went in but for some reason functioned for an entire 3 weeks before an issue was found we still would go back and mark it as creating an incident or introducing a bug.
If the monitoring period needs to be captured it should be called out in the change order, if for anything it would be auditing purposes (if you are subject to auditing).
If you go to the level of creating tasks under the change order or release record the tasks time frame should reflect the ACTUAL implementation or activity (not the entire window plus monitoring) and if you really wanted, create an additional task for awareness around the monitoring period.
lots of ways to do this based on your companies level of detail you choose to capture.