Is a ticketing system just for the software domain?
So, you’re thinking, this guy comes from a software background and they have their own problems managing issues and have devised any number of ways with dealing with those. Whatever he is saying won’t be relevant to my business area! Well, although much of that is true, it is my experience that once people see how issues can be properly managed they start to see the parallels with their own areas of work and on more than one occasion I have seen people co-opting solutions we use in the software industry to deal with issues in other domains. Not only that, but using such solutions is invariably successful and the results are positive. So, I would contend that although what I will discuss in this article may stem from my experience in the software world it has general applicability over many domains and the tools used have similar pertinence.
In software the ticketing system is usually used to collect issues which mount up against a particular software product or set of products. The resolution of these issues is then planned into future releases of the software. Those issues can come from inside or outside the business. They can relate to errors or problems found with the software, or they can relate to product plans or suggested enhancements. Our ticketing systems can be combinations of help desks, work management systems and planning systems and in general provide the following types of functions:
- The ability to record issues as they arise.
- The ability to identify the issue as belonging to various categories of problem and report on those categories.
- The ability to assign some form or workflow to resolve the ticket and to assign the tickets to team members
- The ability to have gateways in that workflow which only permit the ticket to progress if it has been suitably checked.
- The ability to prioritise ticket handling and workflow.
- The ability to record progress and closure of the ticket.
These same fundamental steps normally apply, whichever domain you are in. For example, managing equipment within an estate or managing issues with an international standard.
How many issues do I need before it becomes a problem?
When you only have two or three issues it is almost certainly just as easy to manage this in any of the conventional ways which we will review in a while, however with ten or more you are getting to a point where the actions and methods of recording progress are getting a little too precarious.
Another aspect of the number of issues you have is the speed at which they are growing. If you are creating new ones faster than you are closing old ones, it will not take too long before the number of issues gets out of control.
So keep an eye on how many issues you have and how fast the number is changing and move to implement something to help you manage them well before it becomes a problem. If you don’t do this, you will start to face problems akin to those listed below:
- Forgetting an issue completely, with all the problems that could entail.
- Not prioritising your issues appropriately and ending up doing the things that are easy or you enjoy, rather than the things which must be done.
- Not planning resolution of issues, once an issue has been raised you should ensure a correct workflow is selected to drive the ticket forward and also select a “release of the product” in which that issue and others may be resolved. Without this plan and the correct workflow the ticket will languish in the backwaters of your ticketing system, never getting any attention.
- Not allocating tickets to control workload. You’re not the only one who needs to help to investigate or fix these issues so make sure you share the load and that others know what their responsibilities are.
- Not recording resolutions. Once it is complete you don’t want that issue still on the list and more importantly, if a similar issue is raised again, you need to stick to the decisions you originally made rather than keep changing. So unless there is a good reason to change your previously implemented solution you can just close the new version of the issue citing the previous resolution.
Methods of corralling your issues
Apart from not dealing with issues in any way or just trying to use your memory to remember them, there are many methods people use for managing their issue load, in order of increasing sophistication, some examples are:
- A collection of emails
- Minutes of meetings
- A lists of tasks
- A spreadsheet
- A formal tool such as a work management system or ticketing system
Let’s consider a few reasons why you would not want to use any of the simpler options, often based on my own experience.
Emails are great when you have a simple chain which quickly leads to a resolution, however as issues fragment and multiple people get involved you soon end up devoting much of your effort to searching and managing email, eventually getting to the point where you feel you need to start listing out the issues in another form.
Minutes of meetings can end up as a similar task of tracking back through minutes to record actions you have taken and progress you have made on an issue, or leaving your minutes as a slowly growing tome of what has happened, obscuring the real actions from meetings. As issues are resolved they drop out of the minutes and you lose track of what you have resolved and sometime how you did it.
A list of tasks in the task tool of your choice is a better option than those discussed above. You are able to record matters relating to the issue in the task and items such as the resolution of the issue, and you are often even able to put target dates against tasks which guide when you will have to perform work and help you prioritise that work. However, it is difficult to share those tasks out in a meaningful way with a team of people and expect them to know what their actions and next steps are. It is also difficult to report on the various different types of issues you have and their states.
One step better again might be a spreadsheet, where you can use the features within the spreadsheet to sort and report on the tickets and information can be formatted to have specific meaning within the columns of the sheet. The difficulty here is often that multiple people are working on the sheet at the same time, making access to issues difficult to control. Also, other than historical versions of the spreadsheet, historical information is lost as it is overwritten. In effect we are treating the spreadsheet as if it were a database, which it is not; for that we need a real database backed by some ticketing or issue management system.
All the failings of the systems above are normally addressed in good issue tracking or ticketing systems. So what are the downsides of such a system?
I guess we have to start with the fact that it is another system to learn and if you are unfamiliar with such systems then it will take some effort to get up to speed. Having said that the functions offered are normally straightforward and fit with the tasks you are trying to accomplish.
The system will cost! However, for most business sizes the functions and convenience afforded by the system more than make up for that cost.
Attention must be paid to the proper maintenance of the system, ensuring adequate security protection, ensuring good backups are maintained etc. The easiest way I have found to do this is to acquire the services on a cloud basis. This removes the necessity to purchase, install and maintain equipment and software to run the system in house. Cloud-based systems are usually very quick to deploy and cheap to get started with.
Where you wish to apply specific workflows or methods of working with the issues, this may require more in-depth learning of detailed functions and configuration options within the package. However, a combination of good on line support, support from the providers and active internet forums will likely get you answers and training on these quickly and efficiently.
My experience
I have tried a number of the methods above to manage issues in a number of different situations. Within certain roles I would be running a number of these different systems concurrently, managing various products. Having had the opportunity to research a number of ticketing systems and then implement one within a business, it would not take me long now to start recommending that the issues are moved to a formal ticketing system.
The ticketing system I have had most success with is JIRA from Atlassian. This system has a large number of built-in features, a very competitive introductory price for a small number of users, and a large number of extension modules and configuration options which allow you to turn it to almost any task. Of course it is not the only system out there. Enjoy searching and curating your current issues into your chosen ticketing system.
Mark Davison is a director at Terzo Digital and has been tracking issues on projects for over 20 years.