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.

Comments

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
Ultra/ProLogic

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 the policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: RenĂ©. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…