How many categories do we need

By ITIL® from Experience ©

It is common to see ITSM tools with hundreds and hundreds of categories1 . As a result, several categories end up having a similar meaning (e.g. fault, error, major error). Moreover, too many categories confuse people thus, they select one based on their best guess or randomly pick one out of frustration. On the opposite end, not enough categories can affect the organization’s ability to produce meaningful management reports.

ITIL® version 22 briefly mentions categories to log events as part of the overall classification3 of tickets. However, it falls short on providing examples or guidance in the number of categories one should have. ITIL® v3 on the other has no such guidance.

Based on our experience, the short answer is:
Just enough categories to: 1) enable the process and, 2) to enable the tool to function properly

To enable the process, the category informs the IT Specialist of the work to perform. It is also used to generate management reports to enable continuous service improvement (CSI) (see Why asking what you want to report on is the wrong way to implement a tool).

To enable the ITSM tool to function the category, in general since each tool is different, can:

Select the type of record that will be logged (i.e. incident, service request, problem or RFC)
Determine the group the event will be is assigned to
Trigger an alert or special notification
Apply a model/process flow or workflow4 to the event
Assign the Service Level Agreement (SLA) to apply
Select an offering In the Service Catalogue

That being said the ideal number of categories should be:

Enough to select the right process flow;
No more than the tool can display without having to go to a search box/window;

Realistically, a well-designed taxonomy5 should provide approximately 10 or less categories to log an event (i.e. incident, service request, problem or RFC). Keep in mind that many categories can be replaced by information captured on the login form or by taking a decisions while executing the business process (e.g. is this a standard workstations).

Fortunately, many tools6 can be configured to display a subset of appropriate categories. Some filter based on the nature of the event (i.e. incident, service request, problem or Changes) while others only display categories applicable to the Service or Configuration Item the event is logged against. Additionally, some tools force users to classify when closing the ticket in order to identify its cause or reason (e.g. User Error) thus, further reducing the number of categories available for logging. It is therefore reasonable for a tool to have a hundred or so categories even though the user is only presented with 10 or less categories to select from.

To avoid the proliferation and duplication of similar categories first, look at the existing categories to see if one can be re-used by implementing a new tool filter. Second, identify if an appropriate synonym already exist (e.g. error vs fault). Finally, implement governance to approve each request for a new category. It should review every request for a new category to ensure that it does not replicate a tool’s functionality, like an “Urgent loan” when the priority should be used instead (e.g. device for travel).

To close, it is easier to add categories than to reduce its number after the tool goes live. Therefore, start with less and expand as each process matures.

Last updated on: 2017-01-03

When you have too many categories users can choose from, you might as well only have one called “Other” or “Miscellaneous” because the data cannot be trusted.

More Quotes

Related: