Hopefully your answer to the above question is a resounding YES. If not then I'm not sure this blog can help you but maybe an episode of "Hoarders" can.

I have worked with many IT support organizations through the years and the quantity of categories in a classification structure is often a hot topic. However, recently I met with one organization that had more than 10,000 categories. And if that's not bad enough the categorization list was growing at a rate of one new category per a day. When I asked how analysts filtered through the list to find the category they wanted to use the response I got was Dilbert-worthy - "whatever category they used last." My favorite follow up question is one that I can guess the right answer to with almost 99% accuracy: "What category do end users choose most frequently in the self-service interface?" (drum roll) "Other" is the most often cited response. Let's step back and think about it. The organization has more than 10,000 categories but only a handful are being used. I'm sure the structure frustrates both IT users and end users and ultimately slows down the incident management process.

Although there is no simple answer to how many Incident categories are right for your organization, there are four simple rules you should always consider:

1. NO, NO, maybe- Make them ask three times - When someone suggests that we should add a new category, no matter how good of a suggestion it is or who it comes from in the organization, always say no. If they come back and ask again say no again. But if they come back a third time then sit down and discuss it. Everyone can have an idea for a new category off the top of their head but the overwhelming majority of the time it's for an odd case and not something that the organization needs long term. By not responding to each random idea you are ensuring that it is a category that is really required before anyone spends any time thinking about how to implement it best.
2. If you aren't reporting on it you don't need it - This is a great way to either avoid creating new categories or clean up the existing list. If the organization isn't demanding a report on that specific category and the key metrics for it (i.e. MTTR), then you don't need it.
3. If you haven't used it in the last six months, you never will - Like my mother always said when we did spring cleaning, "if you haven't worn it in the last year you won't wear it again." From a categorization perspective I would use the rule of six months. Just like spring cleaning there are some exceptions (i.e. ski pants and bad island-themed shirts) that you may keep for emergency situations but otherwise get rid of them. Start by running a simple report on the number of Incidents created (or closed) in each category over the last 12 months. Twelve months is ideal for the first review as to not scare away any IT pack rats. With this report you can quickly see trends and pick out categories that are never used. After initial cleanup schedule a review of your categories every six months and clean away. Trust me it's even more liberating than cleaning out the attic or that old closet at home.
4. Focus on your audience- Many IT organizations forget that categories should be focused on the end user and therefore should be in their language. Additionally end users don't want a massive list of categories to choose from, so focus on a small number of top level categories (10 to 20) and hopefully no more than 100 total exposed to the end user. Of course you can have more complex categories behind the scenes just for IT, but keep the front end simple. There are plenty of fields in the Service Desk that aren't exposed to end users where you can store complexity. For more thoughts about "knowing your audience" see one of my previous blog posts.

Think about your categorization structure (can be problem and change to) and ask yourself which ones are used most by analysts and end users? When was the last time we did a review and clean up? Trust me it's time to get cleaning.