ITIL in Plain Words

"Do you follow ITIL?" The auditor asks it kindly, pen already moving. The honest answer forms in your head a second before the polite one does. The honest answer is "We follow Dana." Dana has run the desk for six years. Dana knows which tickets are urgent, which three servers are never touched on a Friday, and where the one page of notes lives. That is a process. It is just not a published one, and it exists in a single copy.

This article is the first in our Pragmatic ITIL series. It is written for the administrator who has heard "we should be doing ITIL" from a manager, an auditor or a job advertisement. That administrator wants a plain answer before anyone buys a binder. ITIL is a published framework of good practice for managing IT as a set of services. That sentence is most of what you need. The rest of this article unpacks it.

It covers what ITIL is and what it is not. Next come the ten terms worth learning, defined in plain words in a table you can keep. The five ideas underneath the vocabulary follow, and they matter more than the words. Then come the parts a three-person team can ignore without guilt and one ordinary Tuesday on a small desk translated into framework language. Finally, it covers how to answer the auditor without lying or sweating.

What ITIL Is

ITIL is a published framework of good practice for running IT as a set of services. A service, in this sense, is something IT provides that other people rely on to do their work. Examples are e-mail, the file share, the payroll portal, a laptop that works. The framework collects what has worked in many organizations and gives it names. That lets two people in different buildings talk about the same thing and mean the same thing.

It is a vocabulary first. Incident, problem, change, known error, service level: these are words with agreed meanings. The meanings are useful because they separate things that look alike but need different handling. A printer that is down and a request for a new printer both arrive as "printer" e-mails. They are not the same work, and the vocabulary gives you a word for each.

It is a set of ideas second. Underneath the words are perhaps five ideas that a small desk can use. Those five get a section later in this article and a full treatment in The Five ITIL Ideas Worth Stealing. The ideas are older than the framework and will outlive it. The framework's contribution was to write them down in one place and give them a shared index.

It is large. The full framework describes dozens of practices and a lifecycle for services from idea to retirement. It describes a set of roles, a set of measurements, and a way of grading how mature an organization is at each practice. Most of that was written with a big IT department in mind, the kind with a floor plan. Reading all of it is a project. Using all of it is a career.

What ITIL Is Not

ITIL is not mandatory. No law, regulator or standard requires it by name. An auditor who asks "Do you follow ITIL?" is usually asking a shorter question. Do you have a repeatable way of handling incidents, requests and changes, and can you show it? Several frameworks and standards describe such a way. ITIL is the one whose vocabulary most people have heard, which is why its name gets used as shorthand for "having process at all".

ITIL is not software. You cannot install it, and no ticket tool is "ITIL" on its own, although many will sell you the adjective. A tool can make the framework's ideas cheaper to practice. It can give you two forms instead of one or a place to keep a list of known errors. The ideas themselves live in habits and documents. QuerySolv, to take the example nearest to hand, is a help desk and not an ITSM platform. An ITSM platform is the kind of suite that bundles ticketing with asset, change and problem records. QuerySolv has no asset inventory, no configuration database and no change module, and every idea in this series still runs on it. The tool decides how much typing a habit costs and not whether the habit exists.

ITIL is not a certification of your company. People get certified; organizations do not, at least not under that name. A colleague with the entry-level certificate has learned the vocabulary and the ideas in a few days of study, which is useful. It does not make the desk they sit on ITIL-shaped. The certificate goes on the wall. The queue stays on the screen.

ITIL is not a checklist you pass, and it is not the same thing as having process. Dana's desk has process. It triages at nine, writes the fix in the ticket, and never patches the payroll server during a pay run. None of that came from a framework, and all of it is the kind of thing the framework describes. The gap between "we follow Dana" and "we follow ITIL" is mostly a gap of vocabulary, documentation, and a second copy of Dana.

The Vocabulary Worth Learning

Ten terms carry most of the conversations you will have about ITIL, and each can be defined in a sentence. Learn these and you can read a job advertisement, answer an auditor and hold your own with a consultant. The rest of the framework's vocabulary is worth looking up when someone uses it at you, and not before.

Two pairs cause most of the confusion: incident and problem, and incident and request. An incident is the outage; the problem is the reason for the outage, which is worth finding only when the outage keeps coming back. An incident is broken; a request is wanted. Keeping those two pairs straight is most of what the vocabulary is for.

Service level is the term most likely to arrive with a document attached. A service level agreement, or SLA, is the written promise about those targets. Designing one a small desk can keep has its own pillar, SLA Design. The framework word is harmless. The twenty-cell matrix some people build around it is less so.

The Ideas Underneath the Vocabulary

The vocabulary exists to carry five ideas, and the ideas are the part worth keeping. Each gets a paragraph here and a full section in the next article. If you remember nothing else about the framework, remember these.

Separate the kinds of work. Broken things and wanted things need different handling: one needs speed and a diagnosis, the other needs a form and a fulfillment path. A desk that mixes them has the new-laptop request waiting behind the outage, or the outage waiting behind the new laptop. It depends on who read the queue. Two forms, or one required field, is the whole implementation.

Write down what you offer. A one-page list of services tells the organization what it can ask for and tells the desk what it is expected to support. It gives both sides something to point at when the question is "is this ours?" Drawing that line is the subject of the Defining What IT Supports pillar. The idea itself is a page.

Learn from repeats. The third ticket with the same symptom is a message. Someone spends an hour looking for the cause while the rest of the desk keeps fixing symptoms. If the cause cannot be removed yet, the workaround is written where every technician can find it. That is problem management and the known-error list, and both fit on a wiki page.

Change with a brain. Before touching anything in production, write three lines: what you are changing, when, and how you would undo it. If the change is risky, have a colleague read the three lines. That is the entire change process a small desk needs, and it has saved more Friday evenings than any board.

Improve on purpose. Once a month, read three numbers (volume, the age of the oldest open ticket, the reopen rate), decide one change, and make it. The framework calls this continual improvement. Everyone else calls it noticing. The difference is that it is on the calendar.

What a Three-Person Team Can Safely Ignore

Most of the framework was written for organizations large enough to have people whose whole job is one of its processes. A three-person desk can ignore those parts without guilt, and should. Every process you adopt has to be run by one of the three of you, and the queue does not shrink to make room.

Ignore the full service lifecycle. The framework describes services being planned, designed, built, moved into operation, run and retired, with practices at each stage. On a small desk a new service arrives as a purchase order and leaves when nobody has logged into it for a year. You will not run a lifecycle. You will run a desk and keep a list.

Ignore the role catalog. The framework names owners, managers, coordinators and analysts for its processes, and a large organization fills each with a different person. A three-person team fills all of them with the same three people, which means the roles add nothing except titles. Three people with eleven titles is an org chart, not a process. What happens when a small team adopts the titles anyway is the subject of The ITIL Processes That Drown a Small Team.

Ignore the maturity model. Consultants grade organizations on a scale from "ad hoc" to "optimized" for each process. The grade is a reasonable way for a large department to find its weakest area. For a small desk the scale measures your distance from a shape you are not trying to reach. You do not need to know your change management maturity. You need a note before each change.

Ignore most of the process list. Of the dozens of practices, a small desk uses five ideas. The rest describe work you either do not have (a supplier portfolio, a capacity plan) or already do without ceremony (backups, access). The temptation is to feel behind. You are not behind. You are small, which is a different thing, and the framework was not written to make you feel it.

One Tuesday at Northgate Retail, in Framework Words

To make the vocabulary concrete, here is an ordinary Tuesday at Northgate Retail, translated into framework language as it happens. The company has a hundred and forty staff, two IT people (Priya and Marcus) and a ticket tool. Nothing about the day changes. Only the words do.

At 08:52 Lena on the shop floor e-mails the desk: the label printer at till three is dead. That is an incident, something that worked and has stopped. Priya acknowledges at 08:58, swaps in the spare printer at 09:20, and resolves the ticket at 09:25. Restoring the service came first. Finding out why the printer died can wait, and may never be worth the hour.

At 09:40 the store manager asks for a login for a new starter on Monday. That is a request: nothing is broken, someone wants something. It goes through the new-starter form, which collects the five things Marcus needs (name, start date, department, manager, which systems). He fulfills the request at 14:10 with no urgency and no diagnosis.

At 11:05 the third ticket this month about slow logins on the back-office machines arrives, from a third person. Three incidents with one symptom make a problem, an underlying cause worth an hour of someone's time outside the queue. Marcus books the hour for Thursday. Meanwhile the workaround ("log out and back in; the second login is fast") goes onto the agents-only page as a known error. So the fourth ticket takes four minutes instead of forty.

At 15:30 Priya needs to update the firmware on the main switch, which carries every till in the building. That is a change. She writes three lines in the ticket: what (switch firmware), when (18:15, after close), how to undo (previous image saved on files.example.com, rollback takes six minutes). Marcus reads the three lines and says "fine". That glance is the whole of what the framework calls a change advisory board, the group that reviews changes before they happen. The glance took ninety seconds.

At 16:45 Marcus does the month's numbers: ninety-six tickets, the oldest open ticket eleven days old (a vendor part). There is a reopen rate of four percent, and thirty-one tickets for password resets. He decides one change, a self-service reset page, and writes the decision down. That is continual improvement. The service catalog is the one page on the intranet that told Lena where to e-mail in the first place. And the single point of contact is the address she used.

A Short War Story: The Printed Diagrams at Acme

When Acme hired a new IT manager, Tomas, he arrived with a genuine wish to do things properly. In his first week he printed the framework's process diagrams and pinned them along the wall of the IT office. The desk, which was Dana and one apprentice, kept running on the three habits it had always had. Those were triage at nine, the fix written in the ticket, and no patches to the finance server in the last three days of the month. The desk also had a wiki page that listed what IT supported and the six things that could not be fixed yet. After a month Tomas laid the diagrams and the wiki page side by side. He found that the page already covered most of what the diagrams described, in fewer words. He took the diagrams down and kept two for the audit file. He asked Dana to add a change note before production work, which was the one real gap. The desk did not get more ITIL that month. It got a vocabulary for what it already did and one new habit, which is about the right amount.

I have been Tomas. The diagrams I printed were handsome, and the one thing I actually added that year was a note before each change. The note has earned its keep many times since. The diagrams went in a drawer, where they keep a maturity model company.

How to Answer the Auditor Honestly

The honest answer to "Do you follow ITIL?" is a short description of what you actually do, in the framework's words, followed by what you do not do. The auditor is not looking for the word. They are looking for a repeatable, recorded way of handling the work and evidence that it happens. "We follow Dana" is a true answer that fails on evidence, because the evidence is a person. A person cannot be photocopied for the file.

Say the small version with confidence. "We run a single ticket queue for every request, separate incidents from service requests at intake, keep a known-error list for recurring issues, write a change note before any production change, and review three numbers monthly." That is five framework ideas in one sentence. And every clause of it can be shown: the queue export, the two forms, the page, the notes, the numbers. Then say what you do not do: "We do not run a change advisory board, a configuration database or a formal problem process, because the team is three people." An auditor who hears that usually writes down "proportionate", which is the word you want.

Do not claim a maturity level you have not measured, a process that exists only as a document, or a board that never meets. The first auditor who asks for the minutes will find out. And the conversation after that is longer than the one you were trying to avoid. The full version of this exchange is in Talking ITIL With Management Without Lying. It has a translation table from what you do to what it is called and a one-page "how we work" statement.

What to Do This Week

If you have read this far you know enough ITIL to be useful, and the next step is small. Write Dana down. Use one page to record where tickets come in, how incidents and requests are told apart, and where the known errors live. Add what goes in a change note and which three numbers are read at month end. If a line has no answer, that line is the first thing to build. The rest of this series shows the order to build it in.

Then, when the auditor asks, you can answer with a page instead of a person. Dana will still be the one who knows which servers not to touch on a Friday. The difference is that now the page knows too, and the page does not take leave.

Frequently Asked Questions