IT Service Delivery Friction: Defining It, Identifying It, and Eliminating It
When friction develops between processes or IT teams, it can slam on the brakes for speed to value. The sources of friction often stem from mismatched delivery cadences between agile product teams and non-agile shared services teams, leading to moments where the former needs the baton from the latter so they can sprint towards delivery of value.
This phenomenon can be called “Service Delivery Friction.” It can be summarized neatly as this: A limiting factor of speed to value, often caused by resistance between agile product teams and non-agile service delivery, harming IT’s ability to deliver value faster.
Using a rather simple formula, you can measure the volume of Service Delivery Friction for specific IT requests or services. This objective numerical value can then provide context, empowering IT leaders to identify the most common instances of friction and then prioritize those to eliminate.
Our formula: The Service Delivery Friction Index (SDFI)
There are many possible ways to calculate Service Delivery Friction, but we believe in using the most straightforward one.
First, calculate the total volume of a specific type of service request within a specific time window, such as 90 days. Then, multiply that total by the average time, in minutes, it takes to fulfill that request. Since this calculation will almost always result in a large product, we can divide the end figure by 1,000 to make it more palatable. The result is your specific (SDFI) for an isolated type of request or service delivery.
What do you do with this figure? Well, it can’t always tell you much on its own. But when compared to other services as a whole, you can gain immediate context for which types of services or interactions have the most lag.
Once you identify service elements that have a high amount of friction, you can then determine solutions to reduce it. Data analytics and machine learning can assist with the identification of the true sources of friction and highlight opportunities to smooth them over. Automation, adjustments to IT System Management (ITSM) processes, or a creation of a new metric to monitor ongoing friction are all possible examples of how it can be eliminated.
Identifying and eliminating Service Delivery Friction, in action
The important thing to remember about SDFI is that it measures the context of how service delivery is going, both overall and with respect to specific service elements. Comparing the proportion of each suspected problem area’s SDFI to the total, for instance, can paint a picture of where your biggest sources of friction may lie.
The following slide was derived from a webinar we recently held on the subject of Service Delivery Friction. It perfectly illustrates how calculating SDFI can prevent distortions that result from an apples-to-oranges comparison between perceived sources of friction and their actual impact on mean time to value.
In this example, Active Delivery Group Access-related requests would appear on the surface to be an issue given their volume, but the mean time to resolution is actually relatively small. Likewise, the fact that Identity and Access SSO Integrations take an average of six weeks appears to be alarming, but since the level of service requests are low, these requests have a lower impact on service delivery than they might appear.
Instead, the SDFI comparison allows teams to identify which types of requests contribute the most to their overall SDFI baseline. These issues can then be dealt with through automation or other solutions in order to achieve the desired goal of less friction in reality — not just perception.
The preceding image illustrates what happens when the identified problem areas are addressed. The overall SDFI goes down significantly, while at the same time a new priority area is highlighted as a result of its now-larger contribution to the SDFI baseline. Repeating the cycle allows for more incremental gains and a higher rate of speedy service delivery overall.
How NLP-driven topic Clustering can eliminate Service Delivery Friction
If an issue with a high SDFI value has no clear root cause, as is the case in a generic “service not found” category, then to obtain a more granular view of the problem.
Natural language processing (NLP) tools can identify recurring words used in service requests or descriptors in work chat correspondence. E.g., If words like “database update” come up a lot for a specific product team and it’s associated with a high SDFI area, then IT leaders can identify low risk database updates and provide the product team more autonomy to make these changes on their own.
Removing Service Delivery Friction can result in a more successful agile transformation. To figure out where you should start, prioritize the services that product teams are most dependent upon for their delivery. Even minor improvements can have major systematic benefits to organizational speed.
ITSM vs ITIL: Do All ITSM Organizations Need ITIL?
ITIL and ITSM are two information technology (IT) industry terms that are often used in…
How Has ITIL 4 Evolved Change Management? And How Can AI-powered Analytics Propel Its Objectives?
ITIL Change Management best practices have been heavily revised in the ITIL 4 rerelease. Rather…
Understanding the ITIL 4 Change Management Process (And How Automation Can Enhance IT)
Changes are a standard part of daily IT Operations, no matter what category it may…