Protection Periods at Kingfisher
Today, we’ll be discussing Protection Periods. There’s an issue around our perceptions of what a Protection period entails, and what it means to us at Kingfisher. Fixing this issue does not need a full root cause analysis, this blog explains what protection periods mean here at Kingfisher.
The wider IT community is by no means united on these definitions, with terms such as Control period, Change freeze, or Blackout floating around, all with slightly differing meanings.
We at Kingfisher use the term Protection Period. We define this as
“a period of time during which certain systems are exempt from non-agreed normal change”
During a review process enhanced scrutiny and approval measures may be applied. These can be invoked as part of a commercial event, or during critical upgrades to sensitive systems.
During a Protection Period, Change Management will scrutinise changes that meet the protection criteria. If change does not call concern to itself during the extra scrutiny, it will be perfectly able to go ahead as normal.
A recent successful example of this practice can be found over our Easter Protection Period, which ran for 11 days during April. During this time, incident causing changes landed at ~1.1% of changes implemented. Over this time, total changes implemented went down by 35%, when compared with a similar period in July of last year. Incident causing changes during our comparison period also showed an increase compared to the Easter protection period, where changes that caused incident account for ~1.4% of changes.
To show the efficiency of this practice, we compared two periods of eleven days, one of which was a full protection period during April this year, and the other, July last year. During both periods we noticed two differences. A 35% decrease in total change activity, and 0.3% fewer changes causing incidents. Changes causing incidents accounted for no more than 1.5% of changes.
We can draw 2 observations from these numbers. Our first option is that there is a relationship. Our second is that the scale of difference between our two metrics is great enough that change volume should remain unaffected by an incident hasn’t yet happened, but will probably happen to other changes.
Instead of uninhibited change volumes at critical points of the year, leading to a theoretical increase in incidents, or simply freezing all change during these periods, theoretically leading to an utterly ridiculous backlog, project delays, and wasted work, we offer, the protection period.
“A period of time during which certain systems are exempt from non-agreed normal change”
We believe the current perception around Protection Periods, change freezes, soft freezes, (and any number of naming conventions and definitions) may contribute to a decrease in the number of changes that don’t fall under protection, thus increasing workloads either side of these periods. This is undesirable. So, how do we change this perception?
Well, this article is a start. We’ll be releasing separate comms around this, with the updated definition included, as well as a link to our protection period calendar, these can be found on Viva Engage.
To reiterate our definition, we define a Protection Period as “a period of time during which certain systems are exempt from non-agreed normal change”, we hope this clarifies what is meant by this term, and the thought process that helped us to arrive at this conclusion. Going forward, we hope to see this term, and its definition, make solid headway into the Kingfisher vocabulary.
If you are interested in joining us, please do check out our careers page.
