Should we stop the clock to avoid breaching the SLA

By ITIL from Experience ©

From time to time IT needs additional information from users during the lifecycle of an incident or service request. The information may be required to deliver the service, to confirm the incident’s resolution or to verify that the service delivered met expectations. When waiting for the User, IT can either:

Let the SLA clock run increasing the likelihood of breaching the SLA, or
Stop the SLA clock

The thinking behind letting the clock run is that the SLA should account for this wait time. After all, IT sometimes waits on suppliers and their response and resolution time are accounted for in the SLA. Time required by the Business should be treated the same way and factored in the SLA.

Under this approach some organizations specify response times the Business is expected to meet in an SLAs section titled Responsibilities as proposed by ITIL2. As such, this can be treated as an Operational Level Agreement (OLA) between IT and the Business. Some organizations even provides certain Business power users accounts in the IT Service Management tool and creates a group1 with this OLA to measure their performance against their responsibilities. Therefore, stopping the clock is not required since an SLA breach can be attributed to the group that did not respect its OLA.

This can work well for some organizations. But, depending on the tool’s capabilities Business users may have access to all of IT's performance data! This can be risky if the Business-IT relationship tends to be confrontational as the Business may scrutinize in detail IT’s work since they have access to this information.

The common approach is to stop the SLA clock when IT waits for the Business. After all the thinking is that IT should not be held accountable for an SLA breach if is not responsible or has control over the breach.

Under this approach it is important to understand how the ITSM tool calculates an SLA breach and the effect stopping-restarting the clock has on these calculations. Specifically some tools calculate a breach by:

Counting down the hours and minutes from the SLA’s response and resolutions times. When the clock is restarted it resumes its count down where it left off. Therefore, if the SLA has a resolution time of 4 hours, IT has 4 hours whether it spends it all in one day or spends it over 4 months.

-or-

Subtracting the date/time now and the login date/time. As a result, if the SLA has a resolution time of 4 hours restarting the clock after it was stopped for a week would automatically cause a breach even though the clock may have been stopped 30 minutes after it was logged by IT.

Regardless of the ITSM tool’s particularities or if the clock runs or is stopped, what is most important is the ability to report on IT’s performance against the SLA and the ability to illustrate the Business impact on this performance.

Plugin disabled

Plugin footnotearea cannot be executed.

Disclaimer

<HR>