Skip to main content

Defining Categories

I often hear from organizations that they are not reaping the expected benefits from their Incident Management Systems or integrated Service Management suites. One of the biggest reasons is that they are struggling to determine how to categorize incidents, problems, service requests, changes, and so forth. Coming up with the right categories for your organization is easier said than done. If you’ve had to do it multiple times, you’re not alone. Having said that, it is important to persist. Categories drive many process activities such as:
  • Incident matching
  • Second- and third-level escalations
  • Workflow management
  • Self-service decision tree logic
  • Priority definition
  • Knowledge base searches
  • Trend and root cause analysis
  • Metrics production
  • SLA reporting

Miscategorized records cause inefficiencies, ineffective reporting and can even damage the relationships between lines of support. For example, are your second-line support teams regularly asking “why was this record assigned to me?” If so, it may be time to stop blaming the Service Desk and start looking at your categories. You may find that your tool is driving those incorrect escalations.

Most tools provide the ability to capture three or four levels of granularity. While your categories will be unique to your organization, there are a few common steps you can take whether you are just getting started, or need to start over.

  1. Hold a brainstorming session with all process stakeholders and decide on the highest level categories. Start with broad, easy to understand and use categories. A good rule of thumb is to have 10 or fewer categories at the high level, including an “Other” category.
  2. If possible, pilot your high level categories for a short period of time. Use a simple check sheet, a temporary field in your system… whatever works. Run the pilot long enough to log a few hundred records, produce some reports, track the use of “Other,” and collect enough data to conduct a meaningful analysis.
  3. Analyze the results. If a category was never or rarely used, do you really need it? Was “Other” used? If so, why? Is there a category you missed? Do your analysts need training? Refine your high level categories (or your training program) as needed and then begin defining your lower level categories.
  4. When defining lower level categories, reach agreement on the rules you’ll use when determining data values based on the results you want to produce and the workflow you want to drive. Such rules may include:
  • Category: High level – what – noun (e.g., hardware, software, application, network, database, security, etc.)
  • Subcategory/type: More specific – what – noun (e.g., subcategories for the “hardware” category may include printer, laptop and BlackBerry)
  • Item: Most specific – what – noun (e.g., items for a “printer” may include power supply and sheet feeder)
  • Symptom: Action or error – verb – user perspective (e.g., symptoms may include an error message appearing on the printer display such as paper jam or printer ink low

If possible, expand your pilot to include your lower level categories. If that isn’t possible, use a spread sheet to collect data values from all stakeholder groups. View the spread sheet as a “living document” for a pre-defined period of time. Review and refine the data values until you are ready to go live.

Now, about that “Other” category. Some say you should never have an “Other” category. The Professor disagrees. The reality is that if you do not have an “Other” category, people are just going to take a guess or pick the first option on the list. Providing an “Other” category enables you to know when people are unsure what to select. The key is to monitor the use of “Other,” perhaps by having it trigger an email to the Process Manager for review, or by producing a regular report. You can then take appropriate action such as providing training or adding a new category if needed.

Effective categories provide the information needed to monitor, measure and improve your processes and services. They also facilitate streamlined processes and workflow automation. The most effective categories are customer and business focused, easy to understand and use (10 or fewer at the highest level), designed to produce the desired results, and rigorously maintained. Want more info? The ITIL V3 Service Operation publication provides additional guidance and examples.


Anonymous said…
I promote the use of the name of the service as the top level. This allows an easy tie to SLAs and supports problem management from a service perspective. For lower levels I start with the defect, i.e. top category is "Printing," the next level is "can't print." The classification of the cause fills out the picture, i.e. "User access."

Glenn Robinson

Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you. Roles and Responsibilities: Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance. Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables.  An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and th

The ITIL® Maturity Model

Most organizations, especially service management organizations, strive to improve themselves. For those of us leveraging the ITIL® best practices, continual improvement is part of our DNA. We are constantly evaluating our organizations and looking for ways to improve. To aid in our improvement goals and underscore one of the major components of the ITIL Service Value System , Continual Improvement .   AXELOS has updated the ITIL Maturity Model and is offering new ITIL Assessment services. This will enable organizations to conduct evaluations and establish baselines to facilitate a continual improvement program. A while back I wrote an article on the importance of conducting an assessment . I explained the need to understand where you are before you can achieve your improvement goals. Understanding where you are deficient, how significant gaps are from your maturity objectives, and prioritizing which areas to focus on first are key to successfully improving. One method many organi

The Four Ps of Service Design - It’s not all about Technology

People ask me why I think that many designs and projects often fail. The most common answer is from a lack of preparation and management. Many IT organizations just think about the technology (product) implementation and fail to understand the risks of not planning for the effective and efficient use of the four Ps: People, Process, Products (services, technology and tools) and Partners (suppliers, manufacturers and vendors). A holistic approach should be adopted for all Service Design aspects and areas to ensure consistency and integration within all activities and processes across the entire IT environment, providing end to end business-related functionality and quality. (SD 2.4.2) People:   Have to have proper skills and possess the necessary competencies in order to get involved in the provision of IT services. The right skills, the right knowledge, the right level of experience must be kept current and aligned to the business needs. Products:   These are the technology managem