Why organisations declare Change blackout windows

[SimonMorris]

My last couple of blog posts have been about Change Management and the idea of checking for conflicting RFCs. ( Part 1, Part 2 ).

It's a great feature in ServiceNow that is available now and is enhanced in the October 2011 release, according to the latest release notes.

The fact that Blackout and Maintenance schedules now have condition fields leads to some interesting usage examples. It's obviously a handy thing to have in larger organisations where, for example, the London Infrastructure team will have a different maintenance schedule to their New York colleagues.

I wondered how organisations might use this new functionality and so asked around, firstly on my ServiceNow blog and also on Linkedin.

With the exception of one snarky commentator (just joking!), I got a really informative response - certainly enough to help with the testing.

I thought I'd collate the results into a blog post.

Why do organisations Blackout Windows (or Change Freezes)

• In the Education sector during the first week of school/college and during final exam week.
• In local Government during city wide training exercises, changes in working practice
• In local Government during elections
• In national Government around political events (Independance Day, State of the Union)
• In national Government around sporting events (London Olympics)
• Common use cases:
  
  • Financial cycles (year and quarter end)
  • Executive conferences
  • During holiday season when technical resource is light
  • During deployment of a new product where changes need to be isolated
  • During an activity of high change
  
  

My favourite example is the last one - During an activity of high change.

During a period where you have a high volume of Change, or perhaps a lower volume of change on critical systems a freeze might be necessary. Maybe to isolate non-critical changes that might muddy the Problem Management process if you have implementation issues.

I was also interested in the concept of Change Freeze versus "Change Frost" and "Change Thaw". Or in ServiceNow terminology "Blackout" versus.... well, we need to think up some other colours 🙂

More than one large organisation that I know of has the concept of a period of freeze where SOME changes are allowed.

I think that a Utopian Change Management system should take into consideration the risk profile of a Change record, and the state of Blackout windows and give guidance on whether this change is acceptable. The system could also take outstanding Incidents against CIs - don't make Change against components that currently have unrelated faults for example.

Change conflict detection is designed to give guidance on the suitability of a Change, and it's a major step forward - but there's lots more work we can do in this area to make the assessment of Change more predicatable and basically "clever".

Approving a Request For Change record is basically an acceptance of risk - there are a lot of "signals" that can be taken into consideration.

Thanks for the responses that everyone gave - the Linkedin discussion thread is well worth a read.

• My original blog post
• Linkedin discussion
• ServiceNow October 2011 release notes
• Conflict detection on the Wiki
• Change Management conflict checking - Part 1
  
• Change Management conflict checking - Part 2