Thoughts on single piece flow in IT support

My first IT job was a one day per week internship with a pharmaceutical company while I attended my last year of high school. It was the first time I was exposed to the constant stream of support and service calls that makes up a large part of the day to day life of a support technician. I remember having a distinct impression that the IT department was constantly over-worked, always having too many things to deal with.

The same was true as I gained paid employment, first as an apprentice, and later as a permanent employee. Although the service management tool is important, regardless of the tool used, it has almost always been a fact of life that most tier one and two support technicians have a large number of tickets in their queue.

Dr. Goldratts Theory of Constraints introduced the ideal of single piece flow in manufacturing. While many have claimed that reduction of batch sizes in an effort to move towards single piece flow is not possible in information work, because it is so cerebral, that has repeatedly been shown to be a fallacy. There are many examples of this out there, my favorite example is the work done by the HP LaserJet Firmware team.

As my field is IT support, the gains made by the development side of the business, while nice, tend to be largely* irrelevant to my daily work. Yet, as a believer in DevOps, I have felt a need to try to identify ways to apply the principles to my own context. I do this, not only for myself, but also because I believe that someone has to stand up and help lead the work. If I’m already motivated and interested, why not put up my hand?

Starting out with service requests, it is important to ensure that tickets containing more than one request are split into multiple tickets. I consider the ability to do so a core feature of any service management tool worth considering. This splitting of requests should be done only to the degree where it makes sense, meaning that e.g. a ticket containing requests to add a number of active directory group memberships to a user should be kept as one ticket.

Likewise, incident tickets often contain multiple, unrelated, issues. Where this is the case, and unless the resolution of the issues is one and the same, these, too, should be split into multiple tickets. Conversely, for outages affecting multiple users, we often see large numbers of tickets submitted by different users. Because these are all one and the same, we should assign one ticket as the master ticket, attach the remaining tickets to this ticket, and subordinate their resolution to the master ticket.

While the latter of these two features may not be commonplace, most service management tools I’ve worked with has had the former. Where the latter is not available, other methods should be sought; one such method is to close all the sub-tickets, with a message to the end user about where updates can be found.

Having split incoming tickets to achieve single-piece flow, we get tickets that can be more easily (and rapidly) resolved. From my own experience I know that the result is that, not only does each individual task take less time, but so does the entire initial ticket as a whole. There are a few reasons for this. By batching the job out, we:

• Spend less time searching for the information we need in the ticket.
• Can assign the different tasks to technicians with spare capacity
• Can escalate tasks requiring escalation, without the need to wait for other tasks to be completed

The end goal is to reduce WIP. Despite the initial increase in open tickets, increasing the rate of ticket closure should lead to reduced numbers of open tickets. This, in turn, allows each technician to provide better, more responsive, service, resolving remaining tickets that much more quickly.

*This is, of course, a huge overstatement. Depending on what applications are developed, their gains may be key to my performing my duties, as they were when I worked for FotoWare.