Where are the Monday Morning Quarterbacks in IT?

With the conclusion of the 2015 NFL season upon us, water coolers and break rooms are about to be inundated with that perennial beast, the Monday Morning Quarterback.

With the gift of hindsight in hand, these creatures suddenly produce all the answers, a winning strategy, and play-by-play metrics of success. A few days prior, their commentary was uninventive and bland, but now if only we had listened to them, victory would have been at hand!

The same “rear-view analysis” takes place in business as well, but unfortunately it doesn’t take place nearly as often within the Service Desks of IT organizations. More often than not, it’s the Service Desks that focus too much on responding to the play at hand, and are grossly deficient in “reviewing the tape."

Allow me to explain and highlight some key points on why this happens and how champions avoid it.

Let’s focus on the practice of Incident Management first; the break/fix -- the receiving line -- of the Service Desk.

When an incident is received by the service desk, the first thing an agent generally does is attempt to classify it. A lot of organizations wax poetic over the details of how they classify those incidents. They build CTI – Category, Type, Item – trees and generate topic charts for distribution on which drop-down menu to select on the form. They hold meetings with all stakeholders to define their categories. They submit their stone tablets to the CIO for approval and hold seasonal reviews to determine new categories to add to the sacred list.

During the planning phase of an ITSM solution implementation, categorization seems to occupy an inordinate amount of time. The thing is, categorizing your incidents only does two things:

1. It helps with triage and priority – “What should we address first?” and
2. It helps with specialty assignment – “Who can fix this the fastest?”

The problem is that very often initial categorization is wrong and it never gets updated. No one goes back to review the tape.

Imagine the following: A user will call in to report a “browser” issue when she can’t access SAP. (Because she’s using Internet Explorer to access SAP and it’s giving her a 404 Error, obviously.) The agent categorizes that incident as Application Software -> Browser -> IE. We then go through our standard processes to restore service.

But what we learn during that process is that it’s really a downed Oracle server in the datacenter that is the root cause of the error. The user’s browser is working just fine, but six months from now we’ll never remember that from reviewing our report on incident categories. Because the initial categorization was never updated to SAP from IE.

Fortunately, the ITIL playbook already has a framework solution and that’s the diligent usage of the Resolution Code*.

Think of the Resolution Code as the “category after the fact”. It’s the type of fix we actually used to resolve the incident. It gives our historical reports real insight, and it tells the future what we fixed and how we did it.

And it’s really that feedback loop that separates the IT “Busch leagues” from the pros. That’s true Continual Service Improvement.

Before we huddle on how to get there, let’s understand some key reasons why this seems to happen:

1. Incident management is a break-fix discipline and we think about “putting out fires.” We incentivize our incident technicians to “restore service” quickly, but not usually accurately.

2. We rate our agents on Response Time and Resolution Time more so than metrics such as Initial Categorization Accuracy, Number of Solutions Accepted, or Resolutions Promoted to Knowledge Articles.

3. We’re too quick to “push off” Incidents to specialists. Our agents key in on certain words – or names of apps or solutions – and automatically want to re-route the incident to a special group, the app owner, or the back-end engineers. It’s the “not my problem” mindset and it’s again exacerbated by metrics such as Response Time.

4. No one ever goes back to review the categories. How much time do Incident Managers spend re-categorizing incidents? Do we give the Incident Managers enough information in the record to even accurately re-categorize?

5. Organizations tend to use the default, out-of-the-box Closure Codes from their ITSM software vendor and are left with values such as “Closed with Action” or “User Error”, which provide zero value towards analysis.

Here are the results of our coaches poll on how to improve:

1. Define Resolution Codes and use them. Resolution Codes should be as granular as the history reporting you’d like to be able to review. Similar to categories, they will be different for each type of organization, and it’s really up to key IT stakeholders to identify, define, and structure these.

2. In lieu of your Incident by Category reports, take a harder look at your Resolved Incidents by Resolution Code report. The former shows you how Incident were initially categorized without insight into that accuracy. The former will show you what what was fixed.

3. Don’t spend so much time worrying about categorization of Incidents. There are only so many minutes on the clock and using more to address Resolution Codes is a winning strategy.

Analyzing past actions in order to improve future operations is an important practice and one that takes discipline, but can be used to foster championships. This week, when you’re getting an ear-full on what should have happened on the gridiron this season, start thinking of the next season at your Service Deck and the new Resolution Code strategy and plays that you’ll be refining in the off-season.

By the time the fall comes around, if you’ve implemented these practices, you’ll have real historic data from the past six months on what you can expect to encounter on the field and have a clear game plan going forward.

Best of luck as you kick-off this project!