7 Steps to Incident Categorization

In part one of this series, I looked at basic categorization schemes and why categorization is so important for decision-making. In this part, I will walk you through, step-by-step, how to create a new categorization scheme that will work for your organization.

At the core, categorization is like a set of buckets. Each bucket holds a bunch of incidents, and within the bucket, these incidents would then be logically grouped by a subset of characteristics within the bucket. The first decision that needs to be made is, "What is the highest level of the hierarchy?" Here is the seven-step process to help your organization develop a categorization scheme that works:

Step 1: Identify High-Level Categories

Incidents can be categorized by call, by type, by caller, by technology, by incident, or by service. The first decision is which of these is most important to the customer? Typically, organizations that are implementing service management will take the approach of starting with the service. Service-based categorization provides a substantial amount of value to understanding service performance and helps to identify improvements to services.

This upper-level classification will not work with all organizations. External service providers may decide to choose a customer at the highest level. The key is to keep the upper or primary level general but not too broad. Ten to fifteen high-level choices should keep the level of detail at the correct level.

To develop an accurate high-level categorization:

• Pull three months of the most recent incident activity
• Define 10 high-level categories
• In a working group, sort available data into the defined high-level categories
• Any tickets that do not fit? Adjust the high-level categories to incorporate the different tickets
• Use “other” category temporarily to represent other possible choices not yet identified

Goal: Develop 10 to 15, high-level working categories.

Step 2: Verify Categories

How do you get a consensus on the high-level choices? Review the structure after three to six months of use:

• Reassemble project team
• Verify that the identified categories work
• If "other" category used, sort and determine how to categorize the different tickets
• If the structure does not work, modify as needed

Goal: Standardize on 10 to 12 categories.

Step 3: Identify Types in Each Category

Next, you must decide the secondary level. To complete this step, look at the incidents in each high-level category and further determine how to divide those tickets up effectively within the categorization. The second level should be specific but should not dive into the minutiae:

• Once you have a category filled with three to six months of data, the next step is to sort and analyze the common types in the category
• In this step, you are creating collections of common types that are in the category
• In a working session, divide the tickets from each category into the identified types for that category
• Repeat the process for each high-level category

Goal: Develop 10 to 15 types per category from Step 2.

Step 4: Identify Items in Each Type

The third level provides much more granularity into the specifics of what is occurring in the incident. The level of detail here has to be driven by organizational need and the type of incidents that are captured:

• Once you have the types identified, the next step is to analyze what items are in each type
• In a working session, divide the tickets into common items
• Create collections of common items that are in each type

Goal: Develop 10 to 15 items per type identified in Step 3.

Step 5: Pilot the Structure

The next step is to establish a structure that will be used and tested in the live environment. At this point, the structure is in draft form to allow for modification based upon actual calls that are received. Each call that does not fit into the structure should be reviewed to determine if a change is needed. To not slow down the flow and handling of incidents, an “other” category is often used. All analysts are encouraged to put incidents into the “other” category when the structure doesn’t handle the type of incident reported. Analyze the “other” categories on a weekly or bi-weekly basis to determine additional category/type/item (CTI) structures that must be added. Long-term use of the other structure should be avoided.

• Now that you have 10 high-level categories, 10 types per category, and 10 items per type, it is time to try it in the live environment
• Pilot the draft structure
• Use "other" to capture those new items that either do not fit into the identified category/type/item structure or are new

Goal: Gather information on how the draft structure works during the pilot in the live environment.

Step 6: Improve the Structure

After the pilot is complete, it is crucial to now go back and review the “other” categories and determine if the categorization structure works for all incidents identified in the pilot and after. Once you’ve reviewed the "other" category, you should probably remove it from the structure as an option. It is imperative not to change the categorization structure too often after the pilot as the organization will lose the historical perspective of the data.

Goal: Improve as needed to meet the evolving needs of the business.

Step 7: Put the Categorization Structure Under Change Control

Once the team finalizes the categorization structure, place it under change control. Any new categorizations that are identified should only be added after an RFC is submitted and the risk of changing the structure is adequately assessed. However, some circumstances will commonly require adjustments to the categorization: 

• When new services are introduced. The category structure should be updated if the service does not fit into the existing CTI structure.
• When services are retired. The category structure should be updated by archiving the appropriate data and removing the service from the CTI structure.
• When services are changed. Identify if modifications are necessary. Typically modifying services does not require an adjustment of the CTI structure at the higher levels but may require changes at the lower levels of the structure.

Goal: Require the organization to agree on changes to minimize risk.

Pitfalls to Avoid

Too Many or Too Few. There are many ditches to avoid in categorization. If the categorization has CTI structures with too many tickets or too few, this is an indication that the categorization scheme is not effective. The exact number is hard to determine but is more easily expressed in percentages. If you have a CTI structure that holds 25% of your ticket volume, then the structure may not have enough detail. If a CTI structure contains less than 2%, then it probably is too specific.

Avoid Constant Re-Categorization. Every change to the categorization will modify the way existing data is structured and will impact historical analysis. Changes to the categorization must be carefully planned for the risk that it can introduce. It should not, however, discourage change. Organizations are not stagnant, and neither should the categorization scheme be frozen in time.

Do Not Categorize by Symptoms. It is also essential to focus on capturing information that is factual and not symptom-based. A specific IT incident can have many different symptoms. To categorize by symptoms would very quickly permit multiple categorizations for one type of incident and will immediately produce unreliable data. Symptoms are more appropriate for metadata fields or other available fields in the incident record.

Critical Success Factors 

What Reports Are Needed? Reporting from the incident management system is essential for overall quality improvement of services, processes, technologies, people, and the overall customer experience. All service management processes use this data to support decision-making. It is important to keep this in mind when data is structured, captured, and used in reports that are provided to these processes. All existing processes that are defined and managed will need this data as an input, and their needs must be taken into account. The collected data should drive improvements that are meaningful to the business and IT.

Decide first what data you need out of the incident management system. If you can get agreement on what needs to be in the reports for the incident management process and services, then it will help the organization to further define the requirements in the categorization activity. Additionally, if service level agreements are implemented, review the agreements to help to identify additional required measurements.

Maintain a Customer or Business Focus. The tendency for an IT organization is to focus the CTI structure on the internal view of IT. An internal-only view will serve the purpose of identifying improvements in components but won’t serve the need to drive improvements in services. The data collection must be business-driven, not IT-driven. The external view will provide data collection that will support better decision-making and analysis based upon what is important to the business.

Be Sure to Train. Training is essential to the correct categorization of incidents. Even the best-defined categorization scheme is subject to error. Organizations that are trained on how to categorize within the ITSM system and know how to handle exceptions will have higher quality data. Redundancy of categorization must be avoided through both design of the categorization but also in the operational use of the categorization.

Even the best-defined categorization scheme is subject to error.

Use Closure Categories. Changes to the categorization of an incident throughout the incident management process should be avoided. If a customer calls in and reports an incident and the categorization is selected but later it is determined to be incorrect, the best way to handle this situation is to create a closure categorization. Closure categorization provides the organization with a way to improve the process and improve the training of analysts recording the incidents. Also, some incidents will present symptoms that indicate a particular structure, but it is uncovered through diagnosis that the issue turns out to be something very different. Both categorizations can be helpful to find the solution the next time the issue occurs.

Put Structure Under Change Control. Once the environment has stabilized, the categorization should be under change control to ensure that any changes will keep the underlying data in its highest level of accuracy.

The Benefits of Good Categorization

The benefits of a good categorization scheme are many. The categorization will ease the process of logging incidents, reduce redundancy, and strengthen the organization’s ability to manage knowledge and use it to support decision-making. The underlying data will enable the organization to take a proactive view of service management and identify improvement opportunities. The view will be across functional silos not based upon the technology that is managed. A well-designed categorization will provide a better overall view of the services and how they are meeting customer expectations and service level targets.

Someone once said that nothing in life worth doing is easy, and it is especially true with categorization. Creating a useable and sustainable categorization is a tough exercise that will pay off in the end. The data collected in the incident management process represents every touchpoint, every aspect of the customer experience. If we capture that knowledge in a way that it can be reused to support continual improvement, the organization will improve services, improve customer satisfaction, and improve efficiency and effectiveness of operation. That is definitely something worth doing.

Julie is a dynamic, engaging change agent who brings authenticity, integrity, and passion to practitioners worldwide. Through her books, articles, speaking, consulting, and teaching, her purpose is to spark change in the world with thought-provoking dialog and interaction on topics of authentic leadership, business strategy, knowledge management, organizational culture, and innovation. Julie has a B.S. in computer science from The Ohio State University and an MaED from the University of Phoenix and is currently pursuing her Ph.D. in Management and Organizational Leadership in Information Systems & Technology from the University of Phoenix. She is an ITIL Expert, Certified Help Desk Director, and Certified Governance IT Professional. She is an HDI Business Associate and teaches training and certification classes for service and support professionals. Visit her website, and follow her on Twitter @JulieMohr, YouTube, and LinkedIn.