How is a change window determined for an event?

Discuss and debate ITIL Change Management issues
Post Reply
User avatar
Posts: 1
Joined: Tue Nov 18, 2014 7:00 pm

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?

User avatar
Posts: 11
Joined: Sun Apr 12, 2015 8:00 pm

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.
User avatar
ITIL Expert
ITIL Expert
Posts: 3639
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

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
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
Posts: 6
Joined: Wed Mar 02, 2016 7:00 pm

Wed Mar 09, 2016 7:24 am

I think,

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.
User avatar
Posts: 12
Joined: Mon Sep 05, 2016 8:00 pm
Location: Minnesota

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