Stop Shooting from The Hip: A Cautionary Tale of Service Support Gone Wrong

Okay, something’s gone wrong with one of your IT services. You and your coworkers are trying to resolve it by shooting from the hip. You personally think this event is something that needs to be dealt with immediately, but your colleagues disagree. Ideas are tossed around and discarded and nonproductive arguments occur about whether this is a high- or low-priority incident. No one agrees on anything; mean time to repair is getting longer and longer and the cost of the stoppage rises as human capital is squandered trying to resolve the issue. At the same time, there is ever-growing pressure; your organization is competing in a global economy and has to meet customer needs better, faster, and cheaper.

Your IT department has to step up to the plate and do the same. But the service management tool that your organization paid $500,000+ to support alerting and escalations—in the hope of delivering a quality service at a greater speed for less money—was turned off a few months ago. This was because no agreement or consensus was reached about how to use it within your organization’s complex and political environment.

Different groups of colleagues are implementing Lean and Agile, but they’re going in different directions using different classification structures or even using the same ones in different ways. Classification structures and the so-called shared priority model is not being used efficiently and effectively so the end result is you’re killing velocity and thereby not meeting the needs of the business.

Troy takes a deep dive into classification, prioritization, alerting, and reporting at HDI Conference & Expo.
Learn more!

The recommended solution is to go back to the fundamentals and address foundational issues so that people, groups, and systems can effectively function in the multiple domains and dimensions with all participants working collaboratively. A critical principle to adhere to is that it’s only when a complex adaptive system shares constancy of purpose, beliefs, practices, and priorities, that collective velocity—speed with direction—can be achieved.

Crucial actions include giving context to disparate data and creating an integrated process framework. IT workflows need a well-thought-out and a commonly accepted and practiced categorization structure across the various processes that enables the delivery and support of IT services. To be effective, the processes of incident, problem, change, and release management as well as other major aspects of service management require a consistent approach to classification. The ability to accurately classify process records unfailingly must be attained prior to automation, integration, and the production of qualified and trusted management reports.

The most common mistake that IT organizations make when they design a categorization structure is that they approach it from a purely technical or single-process perspective. Organizations need to think from a more integrated perspective, otherwise it will be impossible to successfully create and implement an ITIL automation process. The primary policies for keeping these processes glued together are practices of classification, prioritization, and escalation. A complex system of processes requires shared classification structures because they act like a spinal cord or backbone linking the ITSM processes together and are just as critical to service management as the spine is to a healthy body.

The most common mistake that IT organizations make when they design a categorization structure is that they approach it from a purely technical or single-process perspective.

Classification

Each process record requires a combination of four basic and common classification structures:

• Service. What IT service is being restored, changed, or requested
• Organization. What customer is being impacted or which IT function has been assigned the process record
• Priority. How quickly and in what order must the IT service provider address this issue at hand
• Technology. What type of technology is being restored, requested, or moved

As noted, each process record relating to IT service management requires access to these four classification structures; however, some processes might require additional structures that are unique to that individual process.

The classification structure has a number of rules of thumb:

• It generically describes an environment and/or a specific service
• It’s not departmental or role based
• It needs to support multiple process requirements
• It’s critical to get a sense of repeat issues or trends
• It has to drive automation, especially around workflow management and queue assignment
• This organic structure is ever-changing because the environment is ever-changing—make sure you don’t add categories that aren’t managed

This classification structure is so critical it can’t be subjected to ungoverned control where anyone can add to the structure. It must be supported by solid policy. Examples of automation driven by the usage and creative combination of these classification structures include:

• Record assignment
• Identification of change approvers
• Filtering of CIs in support of CMDB association
• Escalation and notification rules
• Impact/urgency/and priority population
• Rapid record population
• Incident matching to problems
• Knowledge management information and support scripts, etc.

Prioritization

Some work, by nature, takes precedence over other work. The last thing you want during a time of stress is for people to have to guess where the priority is because it’s variable and all too often it falls back to the ”squeaky wheel getting the grease.” This isn’t a good way to establish priorities. A proper priority model will provide the basis for determining how fast IT moves and how priorities will be shared across multiple processes and dimensions.

Priorities should be defined and based on:

• Customer or business need
• Financial impact
• Service criticality
• Business risk
• Component failure impact analysis
• Legal requirements, etc.

The ITIL^® prioritization definition is:

priority = impact + urgency

Impact is the degree to which the provision of services is disrupted within the organization and the effect the interruption has on other areas of the infrastructure. Urgency is the speed with which the incident must be resolved. A third factor is the expected effort—the anticipated amount of energy, time, and cost required to be able to begin restoring the services after the occurrence of an incident.

When preparing a priority model, these dynamics must be weighed; for commercially focused organizations it’s often best to use profit as the basis of the discussion. There are certain individuals, roles, or personas in the profit scenario that have a direct correlation to revenue.

For example, if you’re involved in online investments and banking, then an online investment-type role is critical to support because that individual could lose millions of dollars in a matter of minutes as opposed to an individual in the back office. Some services are also direct-to-revenue, so if there is an application or service that is about making trades, then that will be mission-critical. Once again, it is crucial to use a multi-dimensional perspective and a shared constancy of purpose to gain agreement.

In a four-level priority model, these are the factors most often used:

• Critical. It's going to directly impact revenue
• High. It indirectly supports critical business services
• Medium. It’s an intercompany transfer, collaboration, or operational efficiencies issue
• Low. It’s a productivity tool for one person

Think about your organization’s applications and services and pre-classify them relative to this urgency factor. Do this ahead of time so when something has failed with respect to technology and/or services, the urgency should have been auto-populated based on a pre-defined model. Determining the degree of failure requires human consideration. Sometimes you can automate that by monitoring, or in the end, it should be able to be overridden.

Escalation and Alerting

Now that there’s a shared classification structure and a shared priority model across multiple processes and both are being used consistently, you can begin to automate escalation, alerting, and notification. But this is dependent upon the first two factors being in place.

When done properly, your IT organization’s processes can continue in a virtuous cycle, breaking down less often, and when they do, there is a planned course of action…one that does not involve shooting from the hip.