Tickets predate the well-known ticket tracking software. Long ago, the process of tracking issues by index cards were taken from analog to digital processes However, the usefulness of ticketing has waned in the past decade or so — except in organizations that jealously maintain the culture of quality ticketing.
The capabilities of ticketing systems can be awe inspiring with just one caveat: they need to be used properly. Ticketing systems are just about the absolute last place in information technology where the adage of “Garbage in, garbage out” is still true.
When I first went to work in information technology, I was submerged in the culture of quality ticket tracking. Since leaving that utopia of ticketing where my career in technology was conceived so many years ago now, I’ve had the opportunity to witness how other organizations process tickets. Here are seven ticketing challenges I’ve seen through the years.
Tickets That Track Tickets That Track Other Tickets
Of the several places I’ve been, the engineers appear to have taken the term “ticket tracking” a little too literal. Of course, there are indeed times when a ticket is required to track tickets, but these instances should be the exception, not the rule. I have witnessed several layers of tickets that track other tickets, and this is the number one cause for tickets to become orphans, or zombies (to borrow a term from the sysadmin world). Tickets should only track issues. When you have multiple tickets, you have multiple places where valuable information could be hiding from future readers looking for a solution to a possibly catastrophic issue they are dealing with.
Tracking Live Issues with Closed Tickets
Nobody wants an open ticket in their queue for too long because it ruins their metrics. However, there are legitimate longer-term issues, and the ticket that tracks those issues should remain open. A simple way to prevent an open ticket from ruining the numbers is to create subcategories in which the lifetime of a ticket is not measured for metrics.
Ticket Systems with Unacceptable Archiving
Disk space is no longer a commodity. Many organizations have allocated petabytes of space for log archival, but they only keep closed/inactive tickets for a limited length of time to conserve disk space. Ticketing systems are self-documenting standard operating procedures (SOPs) and methods of operating procedures (MOP) for junior engineers to follow, and companies regularly throw it all away!
Tickets with Zero Information
I cannot count how many times I have seen tickets that were opened and closed with absolutely no information contained in them, or contained very ambiguous language that communicates nothing of value to the reader (e.g., closed notes: “resolved”). I feel like an old curmudgeon when I talk about the good ole days of ticketing where every note and comment of a ticket contained at the very least “who, how, and when” details.
Ticket Systems That Require the Modification of Your Workflow
This is a slippery slope. Modifications to your processes to compensate for ticket system shortcomings are not normally made all at once. Instead, it is usually the case of boiling a live frog: you don’t throw a live frog into a pot of boiling water because he’ll jump out. You place a frog into a pot of lukewarm water and gradually increase the heat until the frog is boiled. Likewise, after several iterations of fine-tuning your process to account for your ticketing system issues, you eventually have a very dysfunctional process, forcing engineers to comply and waste efficiency.
Multiple Ticket Architectures in the Same Enterprise
This issue has always stumped me. I don’t understand why organizations haven’t made more efforts to resolve this problem. You have business units that need to coordinate with other business units, but neither unit has access to the ticketing system that the other uses. The entire reason for ticketing systems is to eliminate exactly this sort of situation, but it still exists. A legacy system (regardless if it’s a ticketing system) shouldn’t be labeled legacy unless it has a roadmap for decommissioning. If there aren’t any plans for getting rid of the legacy system, it’s not legacy in the truest sense.
Ticket Padding for the Sake of Metrics
This isn’t necessarily to be construed as a malicious practice. Many honest, hardworking, competent engineers engage in ticket-handling practices that aren’t exactly industry best practices. If they followed best practices, the metrics wouldn’t be in their favor. This creates an undue number of tickets in the system that have been opened or closed merely for the benefit of metrics, making the task of searching through past issues for a resolution to a current issue that much more difficult, and ultimately encouraging a dysfunctional ticketing culture.
Summary
Companies in regulated industries or under regulatory mandates like PCI, HIPAA, SOX, GLBA, and SSAE16 are constantly under the gun to provide documentation of processes, or documented evidence that processes are followed. With a healthy ticketing culture, these needs can be met.
I don’t have all the answers. However, I do know that the industry for ticketing can be fundamentally improved. The solution is a healthier ticketing culture. Every company should develop a ticketing manifesto that defines the expectations for an acceptable ticket, acceptable level of detail for notes, and clear consequences if these expectations aren’t met.