Moving Change tickets to Implementation in Progress when doing the work.

Discuss and debate ITIL Change Management issues
Post Reply
Posts: 5
Joined: Mon Nov 19, 2018 12:50 pm

Thu May 12, 2022 4:24 pm

I am looking for a different perspective or data points I haven't thought of already. As part of our Change maturity efforts, I have started tracking Change status compliance. Basically I am looking that changes start at their defined start times, they are closed after the work is complete, no changes are left in an awaiting implementation state after the scheduled start date. This new report has exposed that a lot of teams are not setting their changes to an implementation in progress state on time and are not closing down change tickets in a timely fashion, most times they are left an awaiting validation step.

I have reviewed the data and I set my SLA up to identify anything moved to an implementation in progress state after 15 mins of the start window would be considered on time. I do this to ensure that Incident teams have the data they need to ensure that if there is a reported issue they can cross reference the changes to see if there is a change inflight that is causing the issue.

My manager, after looking at the data, wants to change that metric to basically say that a change would be considered starting on time if they started the change anytime within their specified change window. I have a couple of issues with that being:
-Change windows now expand to give teams the freedom to do their changes
-Impacts to other changes/CI's that may now cause issues because teams are starting change way later than they should.
-Team now lose insight into what changes are in flight or may have caused issues
-Teams now have to review the entire change list for the evening making their jobs more cumbersome to try and identify changes causing impact.
-There is no sense of urgency to start changes now
-Changes will now show the same start and end time skewing the information of how long a change actually takes place.
-Reporting on change compliance becomes mute and now we will need to start reporting on the length of time a change actually takes and pushing back on teams with their initial.

Are there any other issues that I am missing here or am I off base and being too strict?

Post Reply