Are Your IT Service Level Agreements (SLAs) Setting You Up for Failure?
A while back, a colleague who was new to the organization was asking about IT SLAs (service level agreements). I explained we had established SLAs for incidents, which are defined as things that are broken. To help our staff and our customers understand the difference between an incident and a service request, we often say, it’s an incident if “it used to work before and it doesn’t work now.” I shared with him our SLA metrics (that are posted on our portal where you place an IT ticket) and our dashboard showing our SLA adherence for the rolling past 90 days. Then he asked, so why don’t you have SLAs for service requests? Those are the things I care most about.
It’s challenging and generally unwise to set SLAs for service requests (some organizations call them change requests). Unlike incidents, service requests are almost infinite in the sense that the organization is constantly looking for new features, new capabilities, new workflows, new design, new interfaces, new applications, new data sets, new dashboards…the list goes on. It’s impossible to create a meaningful SLA around these service requests generally or specifically. In addition, details needed to work on a service request often come from many different sources. From providers to informatics, business office to front office, medical assistants to phlebotomists and more. The process for defining, scoping, detailing, building, testing, and delivering new solutions is well-defined, but the timing is the largest variable. So, we don’t assign SLAs to these requests.
In talking with a number of my IT colleagues across the country on the topic of SLAs, there is strong consensus that SLAs are appropriate for incidents but not for service requests. There are a number of reasons for this, but the concept is well-articulated by Dr. Paula Scariati in her latest book, EHR Governance. She says “…experience had proven that TAT (turn around time) was variable and highly correlated with ticket complexity. Using a single, averaged SLA, regardless of ticket complexity and build burden, resulting in dissatisfaction for all. In lieu of an SLA, team members engaged in conversations with end users about why something might take 90 days to operationalize while something else might take 180 days. This was more labor intensive, but over time the end users became more educated consumers of their EHR technology….”
(Scariati, Paula, EHR Governance, New York, Routledge, 2023. p. 23).
In other words, we need to collaborate with our end users to fully understand the nature of the request and then develop a plan to deliver. That means each service request is, in essence, a project. Of course, some requests are small and don't need to be complicated by a project plan, but many service requests should be worked as projects so that scope, timelines, and deliverables are well-defined and managed. The upside to this approach is that it gives IT analysts practice and experience managing smaller projects and if the request is large, it can be managed by a project manager. This is a scalable approach that also ensures service requests are addressed in a timely manner without defined SLAs.
In our organization, we provide all of our executives access to our IT ticket dashboards, which provides the ability to drill down to the ticket level to review details and track progress. Our numerous workgroups (clinical, operational, and IT staff) prioritize service requests and review progress on the prioritized items each time they meet. This ensures the service requests that are most important to the organization are prioritized the highest.
There are many viable ways to manage service requests and every organization using an EHR should have a defined method in place. For more on this topic, do check out Dr. Scariati’s book – it’s a wealth of information on better managing the EHR through sound governance. Also, pick up a copy of my latest book, Renovating Healthcare IT, so you can improve your internal IT processes along with enhancing your EHR governance.
How does your organization manage service level agreements in IT?
