ISO 20K Can Be a Starting Point, Not a Destination

Since it's adoption, there has been a slow, but steady growth in the number of organizations that are seeking, or have achieved, ISO/IEC 20000 (ISO 20K) certification. For the most part, interest in the standard is being driven by RFP requirements or perceived competitive advantage. The certificate is seen as an "award" that an organization receives for achieving best practice ITSM. While ITIL is being actively adopted, many organizations are overlooking ISO 20K because they do not perceive any value in the certification.

I recently realized that we are looking at ISO/IEC 20000 in the wrong way. The standard has so much more to offer than just a certificate. It actually provides a starting place for an ITSM journey, not only the
destination.

ISO/IEC 20000 defines the "minimum critical activities" required to deliver high quality, aligned services. Once these activities are understood, an organization can assess which activities they already execute well and which may need implementation or improvement.

Here are some other benefits of ISO/IEC 20000:

• It is succinct and easy to understand ("you shall record all incidents")


• It applies to every internal or external IT organization regardless of size or industry


• It distinguishes critical ITSM activities (in Part 1) from recommended activities (in Part 2)


• It logically groups processes (Resolution, Service Delivery, Control, Relationship, Release) so you can build related processes together


• It includes a Quality Management System with requirements for Management Responsibility, Training/Awareness/Competency, Documentation and Plan-Do-Check-Act


• It is founded on continual improvement


• It is objective and measurable and can help diffuse political or cultural challenges

There is no requirement that you adopt ITIL in order to implement ITSM according to ISO 20K. ITIL does offer a wealth of good knowledge that conforms to the standard. However, you can also cherry-pick guidance from other frameworks such as MOF or Cobit. Microsoft recently released a free Using MOF for ISO/IEC 20000 whitepaper. You can also meet the standard's requirements through successful, conformant, internal practices.

Whether you are at the beginning, underway or mature in IT Service Management, I would highly recommend learning more about the standard. It is available as a formal standard, digested ISO/IEC 20000 pocket guide or in several ISO/IEC 20000 books.

EXIN has also created a qualification scheme for ISO/IEC 20000 training and certification. You can explore the scheme at www.takeanotherlook.it. At the very least, I would recommend the ISO/IEC 20000 Foundation course for key staff involved in your ITSM implementation.

Striving for ISO/IEC 20000 certification is a management decision; using the standard as a tool for successful ITSM is just good management.

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.