Talking ITIL With Management Without Lying

The slide says "ITIL-aligned". It is the fourth slide of the quarterly IT update. It has a green check mark beside it, and nobody made it on purpose. The phrase was in the previous deck, and the deck was copied. The new finance director ran a service desk for six years before she moved into finance. She looks up from her notes and asks the administrator presenting, pleasantly, "Aligned how?" The room turns. There are about eleven seconds in which to find out whether the answer is a description or a claim.

ITIL is a published framework of good practice for managing IT services: a vocabulary and a set of ideas about running IT as services people rely on. It is not software, not a law, and not something an organization passes, which is why "aligned" is doing so much work on that slide. The honest answer is almost always available, and better than the slide. Take a small team that logs tickets for everything, keeps a known-error page, and writes a note before a change. It has a one-page catalog and reads three numbers a month. That team is doing the core of the framework in miniature. The job is to say so in the framework's words without claiming a single thing the evidence cannot show. This article, part of our Pragmatic ITIL series, is about that translation.

It covers why the question comes up and the rule that keeps you honest. Next comes a translation table from what you do to the framework's phrase and the evidence. Then come the easy and the careful translations, what never to claim, and how to say "we do the small version" with a straight back. Last come the five-document pack, a war story about a questionnaire, and a one-page statement to copy.

Why the Question Comes Up

The question arrives from outside IT, and it arrives more often as the organization grows. An audit is an outside check that you do what you say you do. An ISO-style audit, the kind run against a published management standard, asks for evidence rather than assurances. A cyber-insurance renewal brings a questionnaire with a row that reads "IT service management framework in use". A customer's security review has the same row with a bigger font. A new executive who has worked somewhere large asks in the first month. A board member reads an article.

None of these people wants the framework for its own sake. The auditor wants evidence that work is recorded and changes are controlled. The insurer wants to know that an outage will be noticed and handled. The customer wants to know their data is managed by a process rather than a mood. The executive wants to know whether the desk is run on purpose. The framework's vocabulary is the common language they have been taught to ask in. It is not the thing they are asking about.

Translate, Do Not Inflate

The one rule is that every framework phrase you use must point at something that exists. If you say "incident management", there is a queue and an export. If you say "problem management", there is a page. If you say "change enablement", there are notes with dates on them. A phrase with nothing behind it is an inflation, and an inflation is a lie with better vocabulary. The listener who knows the framework will ask to see the thing. The listener who does not will repeat your phrase to someone who does.

The test is simple to run on yourself: for each phrase, what would you open if asked to show it? If the answer is a page, a report, a folder of notes or an export, the phrase is a translation. If the answer is "well, we sort of do that", the phrase comes off the slide. Run the test before the meeting, on the slide, with a pen. Most "ITIL-aligned" slides lose half their ticks and gain all their credibility.

Describe practice, never maturity. A maturity model is a consultant's scale, usually one to five, that rates how formal, repeatable and measured a process is. It is useful in a large organization that has paid for an assessment, and a fiction anywhere else. "We do the small version of change enablement, every change, with a note and a glance for risky ones" is a description of practice. "We are at level three" is a number somebody made up in the car. Say the first. The vocabulary itself is laid out in plain words in ITIL in Plain Words. This article assumes you know the words and need the sentences.

The Translation Table

The table below is the whole method on one screen: what you actually do, the framework's phrase for it, and the evidence you can hand over. Read the right-hand column first. If you cannot produce the evidence, do not say the phrase, and consider running the thirty-day plan, which produces every item in that column in a month.

Six rows is all a small team needs to translate, and more than most slides can back. The evidence column is made of pages, exports and notes, all cheap, and all existing only if the practice exists. Evidence is the honest part of the framework. The vocabulary is the part that gets copied between decks.

The Easy Translations: Tickets and the Catalog

Tickets for everything is incident and request management, and it is the easiest sentence in the table to say with a straight face. Incident management is the practice of restoring service when something breaks; request management is the practice of providing things people ask for. If every fault and every request becomes a ticket, is marked as one or the other, is triaged at known times and is closed with a note, you do both. Say it that way: "Every incident and request goes through one queue; here is last quarter's export."

The queue export is the evidence, and it is the strongest evidence you have, because it is hard to fake and easy to check. Any ticket tool can produce it. QuerySolv's reports, for example, cover 7, 30 or 90 days with CSV export. In QuerySolv, every ticket action is recorded with a state snapshot, and nobody can delete a ticket. An auditor who hears that tends to stop asking about the queue. Whatever your tool, bring the export and the count, and let the numbers carry the sentence.

The catalog page is the service catalog, period. A service catalog is a list of what IT offers, to whom, and how to ask for it. A one-page version with ten lines is a catalog in every sense the framework intends. Do not apologize for its length. The eighty-entry catalog nobody reads is the one that needs apologizing for, and it is usually in a binder.

The Careful Translations: Known Errors and Change Notes

The known-error page is problem management, and here the word "lightly" must travel with the phrase. Problem management, in the framework, is the practice of finding the underlying causes of incidents and removing them or recording a workaround. A known error is a cause you understand and have not yet removed. A page of known errors with workarounds is the recording half of the practice. It is not the investigating half, and a listener who hears "problem management" will picture the whole thing. So say the whole truth: "We keep a known-error list with workarounds, which is the lightweight form of problem management. We fix the top entry when the numbers say to."

The change note is change enablement, and this is the translation most likely to be heard as more than it is. Change enablement is the framework's name for making sure changes are assessed and authorized in proportion to their risk. The large version has a board, a calendar and a form. The small version has a four-line note and a colleague's glance for risky changes. Both are the practice. The difference is scale, and you must say the scale out loud: "every change gets a note before it happens, and risky ones get a second person's look. We do not run a change board, because there are three of us."

Here is why the care matters. An auditor or a customer who hears the full phrase and later finds the small version will feel misled, even if the small version was the right choice. The one who hears "the small version, on purpose, for a team our size" and then sees exactly that will write down that you know what you are doing. The reasons the small version is the right one for three people are set out in the article on processes that drown small teams. One of them, in a sentence, is the right answer to "why no board?"

The Numbers Are Continual Improvement

The monthly numbers are continual improvement, provided a decision sits under them. Continual improvement is the framework's name for changing how you work on purpose, from evidence, in small steps that never stop. Three numbers read on the last working day of the month, with one change decided, an owner and a date, is the practice entire. Three numbers read and filed, with nothing decided, is a report. The difference is the sentence under the figures.

The evidence is the dated pages and the record of whether the decisions happened. Bring three months of them to any conversation that uses the word "improvement", and point at the decision line each time. A listener who has sat through maturity assessments will recognize this as the thing the assessments were trying to find. They will be mildly surprised to find it on an index card. Keep the surprise. It is doing your work for you.

What Not to Claim

Do not claim a maturity level you have not measured. The number sounds precise and is not, and the first follow-up question, "measured by whom, against what", has no good answer. If someone needs a level, say that you have not been assessed and describe the practice instead. Describing practice is what the assessment would have done anyway, at a cost.

Do not claim processes that exist only as documents. A change policy on the wiki that nobody follows is not change enablement. It is a document. An auditor finds the gap in one question by asking for the last three changes and the notes that preceded them. The same applies to a catalog nobody updated and a known-error page with no dates. If the document and the practice disagree, the practice is the truth and the document is the finding.

Do not claim a board that never meets, a role nobody holds, or a certification an organization cannot hold. "ITIL certified" is true of a person who passed an exam and never true of a company. "Fully implemented" is never true of anyone, because the framework is not the kind of thing that gets fully implemented. It gets adopted in parts. "Compliant" implies a standard to comply with, and there is none. The phrase that is always safe is "we have adopted the core practices at the scale that fits us, and here is the evidence". It is less impressive on a slide. It survives questions.

Saying "We Do the Small Version" With Confidence

The small version, said plainly, is more convincing than the large version claimed. Here is how it went at Kestrel Payroll, where Priya runs a three-person desk. The new operations director, Tomas, asked on a Thursday at 14:00 what "ITIL" on the IT page of the onboarding pack meant in practice. Priya had rehearsed the answer once, in the car, which is the right amount.

She said four sentences. "Every fault and request comes through one queue, marked broken or wanted, and last month that was 212 tickets, 140 requests and 72 incidents. We keep a known-error list with workarounds, which is the lightweight form of problem management; 19 of those 72 incidents were answered from it. Every change gets a four-line note before it happens, and risky ones get a second person's look; there were six notes last month, two of them glanced, and we do not run a change board because there are three of us. On the last working day of the month we read three numbers and decide one change, and the oldest open ticket right now is seventeen days, which is a laptop order." Then she stopped, which is the part people forget.

Tomas asked to see the known-error list and the numbers page, and she sent both within the hour, with the how-we-work page on top. The conversation took nine minutes. He later described the desk to the board as "small, deliberate and well documented". That is three words better than "ITIL-aligned" and has the advantage of being checkable. Confidence here is not volume. It is knowing which page you would open for each sentence, and having opened it recently.

The Five-Document Pack for the Audit Conversation

Prepare for any audit, questionnaire or executive conversation with the same five documents, kept in one folder, each with a last-reviewed date at the top. They are the catalog page, the known-error list, and the change log with its note template. Also included are the last three months of numbers pages with their decisions, and the how-we-work statement that ties them together. Add a queue export for the last quarter and you have answered every row on every questionnaire a small organization is likely to receive. The pack takes an hour to assemble the first time and ten minutes to refresh each quarter.

The pack works because each document answers a different question the questioner has been taught to ask. The catalog answers "what do you support". The queue export and the Type field answer "how is work recorded". The known-error list answers "how do you learn from repeats". The change log answers "how are changes controlled". The numbers pages answer "how do you improve". The how-we-work statement answers "who decided all this and when". A questioner who gets five short answers with five short documents has nowhere left to go but "adequate", and adequate from an auditor is a compliment.

A Short War Story: Acme's Questionnaire

Acme's IT manager, Sam, received a forty-row security questionnaire from a prospective customer. It had a row for "IT service management framework" and a free-text box that the sales team had suggested filling with "ITIL-aligned, best practice". Sam filled it instead with the small version in plain words, the six rows of the translation table. He added a sentence saying there was no change board because the team was four people. He attached the how-we-work page and the latest numbers page. The customer's auditor wrote "adequate and well understood" in the margin and passed the row. The sales team had expected a problem and got a sentence they could quote. Nobody at Acme changed anything about the desk; they had only described it.

I have filled in that box both ways over the years, and the plain version has never once been challenged. The inflated version was challenged the first time someone on the other side knew the framework. That is the whole argument for honesty here, and it is practical rather than moral. The honest answer is the one that survives the follow-up.

The One-Page "How We Work" Statement

The statement below is the fifth document in the pack and the one to write first, because writing it tells you which of the other four exist. Fill in the blanks, delete any section whose evidence you cannot open, and keep the last section whatever happens. It is the section that earns the trust.

HOW IT WORKS AT ____________________        Last reviewed: ________  By: ______

WHAT WE SUPPORT
One page lists the ___ services IT provides and how to ask for each.
Where: ______________________          (framework term: service catalog)

HOW WORK ARRIVES AND IS SORTED
Every fault and request becomes a ticket in one queue, by e-mail, web form,
chat or walk-up. Each ticket is marked Incident (broken) or Request (wanted)
at triage, which happens at ______ and ______ daily.
Evidence: a queue export for any period.
                       (framework terms: incident and request management)

WHAT WE WRITE DOWN WHEN WE FIX THINGS
Every closed ticket carries a note: what was wrong, what was done, and
whether it belongs on the known-error list. The list has ___ entries and
is reviewed ______.
Where: ______________________   (framework term: problem management, lightweight)

HOW WE CHANGE THINGS
Before any change to production: a four-line note saying what, when, how we
will know it worked, and how to undo it. Risky changes (on the catalog page
in business hours, not undoable in ten minutes, or affecting more than one
department) get a second person's glance first. Notes are kept on the log.
Where: ______________________   (framework term: change enablement, scaled)

HOW WE IMPROVE
On the last working day of each month we record three numbers (tickets by
type, oldest open ticket, incidents matching a known error) and decide one
change, with an owner and a date. The last three months are on file.
Where: ______________________   (framework term: continual improvement)

WHAT WE DO NOT DO
No change advisory board, no configuration database, no assessed maturity
level, no certification held by the organization. We run the small version
of each practice above, on purpose, because we are ___ people.

Put the statement at the front of the pack and on the wiki, and read it aloud once before any meeting where the word might come up. If a sentence in it makes you wince, that sentence is either untrue or unpracticed, and both are fixable before Thursday. The slide, for the record, now says "core practices adopted at our scale; see the one-page statement". The finance director read the statement, asked one question about the risky-change rule, and moved on to the budget. Nine seconds. Two to spare.

Frequently Asked Questions