The Five ITIL Ideas Worth Stealing

Picture the framework as a department store. It is large, well lit, and everything in it is for sale. That runs from the incident process on the ground floor to the maturity model somewhere near the roof. Most advice about ITIL assumes you are there to buy the store. You are not. You are there to walk in, pick up five things, and walk out. Because the goods are ideas, nobody minds. It is the only kind of shoplifting with a good reputation.

This is the second article in our Pragmatic ITIL series. The first, ITIL in Plain Words, defined ITIL as a published framework of good practice for managing IT as a set of services. It also gave you the vocabulary. This one picks the five ideas that pay for themselves on a desk of one to five people and leaves the rest on the shelf.

Each idea gets the same treatment: the idea in a sentence, why it helps a small desk, and the smallest version that works. Then come what it looks like in a ticket tool and the failure mode when you overdo it. A table of the five with the minimum artifact for each follows. Then comes a short war story from a payroll company that stopped re-diagnosing the same slow login, and a one-page starter sheet to copy.

Why Steal Rather Than Adopt

Adopting a framework means taking its processes as written and fitting your desk to them. Stealing from it means taking its ideas and fitting them to your desk. For a large department the first can make sense, because the processes were written for its shape. For a small desk the second is the only approach that survives contact with Monday. Every process adopted has to be run by one of the same three people who are also running the queue.

The five ideas below were chosen by one test. Does the idea still work when the "process" is a habit, a page and a field in a ticket tool? Incident versus request passes. The known-error list passes. So do a note before changes, a one-page catalog and one improvement a month. The change advisory board, the configuration database and the service lifecycle do not. And they are covered, with sympathy, in The ITIL Processes That Drown a Small Team.

Idea One: Incidents and Requests Are Two Kinds of Work

The idea in a sentence: an incident is something that worked and now does not; a service request is someone asking for something that is not broken, and the two should be told apart the moment they arrive. "The till is down" and "can I have a second monitor" both land in the queue as e-mails. One is a fire. The other is a shopping list.

It helps a small desk because the two need different handling at different speeds. An incident needs a fast acknowledgment, a diagnosis and a fix, in that order. A request needs the right information collected once and a fulfillment path, with no diagnosis at all. When they share one list, the monitor waits behind the outage, which is fine, or the outage waits behind the monitor, which is not. Which one happens depends on who opened the queue first.

The smallest version that works is a single required field at intake: is this broken, or is this wanted? Two forms are better, because a request form can ask the questions a request needs (who, by when, which system). An incident form can ask what an incident needs (what, since when, how many people). Either way, triage sorts by kind before it sorts by urgency. The numbers at month end can say how much of the desk's time went on each.

In a ticket tool this looks like two web forms feeding one queue, or one form with a type field that cannot be left blank. There is also a saved filter so incidents can be viewed on their own. A tool that lets a department define its own form and fields makes the split cheap. A tool that does not still allows the field. The split is a rule, not a feature.

The failure mode when overdone is a taxonomy. Someone adds a third kind, then a fourth, then subtypes, and triage becomes a classification exercise that takes longer than the fix. Two kinds is the idea. Everything past two is a hobby.

Idea Two: Write Down the Problems You Cannot Fix Yet

The idea in a sentence: a problem is the cause behind repeated incidents; a known error is a problem you have identified but cannot remove yet, and a known error with its workaround written down is worth more than the same fact in one technician's memory. The framework calls the surrounding practice problem management. The small version is a list.

It helps a small desk because repeats are where the hours go. The slow login that gets diagnosed from scratch by a different person each time costs forty minutes a ticket. The same symptom with a one-line workaround on an agents-only page costs four. A small desk cannot always fix the cause, because the cause is a vendor, a budget, or a server that is three years from replacement. It can always write down what it knows.

The smallest version that works is a page with one line per known error. The line gives the symptom as the user describes it, the cause if known, and the workaround. It also gives the date someone last checked whether a fix had arrived. Four entries is a good first list. Twenty is a sign that the desk has been living with too much for too long, which is also useful to know.

In a ticket tool this looks like a knowledge base page visible only to agents, searched at triage before anything else. The habit that feeds it is the resolution note. When a technician solves something that took more than twenty minutes, or has seen it twice, the lesson goes on the page the same day. The page is read far more often than it is written, which is the correct ratio for a page.

The failure mode when overdone is a problem process with its own queue, its own form, root-cause templates and a review board. It is run by the same three people who are fixing the incidents the problems cause. The list is the idea. The ceremony around it can be added later, by someone with more people.

Idea Three: Change With a Brain

The idea in a sentence: a change is any alteration to something in production that could affect a service, and before making one you write down what you are changing, when, and how you will undo it. The framework surrounds this with assessment, authorization and scheduling. The small version is three lines and a glance.

It helps a small desk because most self-inflicted outages are changes nobody thought about for thirty seconds first. Examples are the firewall rule added at 17:25 on a Friday and the patch applied during the payroll run. Another is the switch rebooted while the backup was writing. Each would have been caught by the question "how do I undo this?", asked before rather than after. Writing the three lines forces the question. It also leaves a record, so that when something breaks at 08:10 on Monday, the first place to look is Friday's change note.

The smallest version that works is a note in the ticket, or on a shared page, with three fields: what, when, how to undo. For a change that could take a service away from many people at once, a colleague reads the note before the change happens. The colleague then says "fine" or "wait". That peer glance is the entire approval process. It takes ninety seconds, and it is what catches the firmware update scheduled for ten minutes before the shop opens.

In a ticket tool this looks like a note template, kept as a predefined reply or an internal note. It is pasted into the ticket that prompted the change, with the undo step written before the work starts. Here is one from Meridian Parts, where Tomas replaced the certificate on the customer portal. What: replace the expiring certificate on portal.example.com. When: Tuesday 18:30, after the last order batch at 18:00. Undo: previous certificate kept in the certificates folder; re-bind and restart the service, about four minutes. Affected: the portal is unreachable for roughly one minute during the restart. Dana read it at 16:10, asked whether the order batch could overrun, and Tomas moved the start to 18:45. That question is the whole value of the glance.

The failure mode when overdone is the weekly change advisory board, a standing meeting. Every change, including the printer driver, waits for approval from the same two people who proposed it. Changes queue up for the meeting. The meeting runs long, and the urgent ones get done anyway and recorded afterward, which means the board approves history. A note, and a glance for risky changes, is the idea. The board is a large organization's way of getting the same note read.

Idea Four: One Page of What IT Offers

The idea in a sentence: a service catalog is the written list of what IT offers, to whom, and how to ask for it, and a small desk's catalog fits on one page. The framework imagines a catalog with owners, costs, dependencies and service levels for every entry. The small version is ten to fifteen lines on the intranet.

It helps a small desk because most arguments about scope are arguments about an unwritten list. "Is the warehouse scanner ours?" "Do we support personal phones?" Each is a ticket's worth of discussion until the page exists, and a glance at the page afterward. The catalog also tells new staff where to ask, and it tells the desk what it has promised, which stops the promises multiplying quietly.

The smallest version that works is a page with one line per service. Each line gives the name, who can ask, how to ask, and roughly how long it takes. The services include e-mail and accounts, laptops and desktops, printers, the file share, and the payroll portal. They include the shop-floor tills, the warehouse scanners, remote access, the meeting-room screens, new-starter setup, and leaver processing. Then comes a line at the bottom for what IT does not do, which will be the most-read line on the page.

In a ticket tool this looks like the catalog page linked from the request form, with a request category per service where the volume justifies one. The page and the form reinforce each other: the form offers what the page lists, and the page says which form to use. The detail of drawing scope lines belongs to the Defining What IT Supports pillar. The idea here is only that the page exists and is short.

The failure mode when overdone is the catalog with eighty entries, each with an owner, a cost center and four paragraphs of description. The catalog is maintained by nobody and read by fewer. Users go back to asking in the corridor, because the corridor is shorter than the catalog. One page is the idea. The second page is the beginning of the end.

Idea Five: One Improvement a Month, Decided From the Numbers

The idea in a sentence: continual improvement means changing how the desk works on purpose, a little at a time, based on evidence, and the small version is one change a month decided from three numbers. The framework describes registers, cycles and models for this. The small version is a calendar appointment and a short list.

It helps a small desk because without it the desk only changes when something breaks loudly. Without that improvement, the quiet costs run forever: the password resets, the printer that generates a ticket a week, the request that always bounces between two people. Three numbers read monthly make the quiet costs visible: ticket volume by category, the age of the oldest open ticket, and the reopen rate. One decision a month, written down, turns the numbers into change.

The smallest version that works is thirty minutes on the first working day of each month. Pull the three numbers, look at the top three categories, and choose one change. Write one sentence saying what was decided and why. Then reread last month's sentence to see whether it worked. Twelve sentences a year. That is a record of a desk improving itself on purpose, which is what the auditor and the framework both mean by the phrase.

Here is what that looks like with numbers. At Northgate Retail, Marcus pulled the figures on the first of the month: two hundred and twelve tickets, forty-one of them password resets. The oldest open ticket was fourteen days (a vendor warranty claim), and the reopen rate was five percent. Decision: switch on self-service password reset and add a line about it to the catalog page. The following month: two hundred and three tickets, twelve resets. Twenty-nine tickets fewer, at roughly fifteen minutes each, is about seven hours a month returned to a two-person desk by one decision and one sentence.

In a ticket tool this looks like a reports page with volume by category over the last thirty days and the age of the oldest open ticket. It also shows reopens counted rather than filed as new tickets. Most tools give you the first two. The third depends on whether a reply to a closed ticket reopens it or starts a fresh one. If it starts a fresh one, count reopens by hand for a month.

The failure mode when overdone is the improvement register with forty open items and a maturity assessment every quarter. The failure mode also includes a dashboard with so many numbers that no single one means anything. One change a month is the idea. If the change is big, it is next month's change too.

The Five Ideas and Their Minimum Artifacts

Each idea reduces to one artifact that can exist on the tool you already have. And the table below is the list to check against. If the artifact exists and is used, the idea is in place, whatever the process documents say. If it does not, no amount of vocabulary makes up for it.

None of the five requires buying anything, and none requires a meeting. The heaviest is the catalog, which costs an afternoon once. The rest are habits that cost minutes and return hours, and the return starts within the month.

A Short War Story: Four Entries at Kestrel Payroll

Kestrel Payroll's desk was two people, Lena and Sam, supporting a payroll portal that a hundred and ten client companies logged into. For a year the most common ticket was "portal login is slow", and each one was diagnosed from scratch. The technician checked the session store, checked the database, checked the client's browser, and after half an hour found the same thing every time. The first login after a password change was slow and the second was fine. Lena started a known-error page with four entries, the slow login among them. Each had the symptom, the cause, the workaround and the date the vendor had last been asked. Triage began reading the page before touching a ticket. In the following quarter the slow-login tickets took five minutes each instead of thirty. The count fell from fourteen a month to six because the workaround went into the portal's own help text. The vendor fix, when it finally arrived, was tested against a list of four symptoms rather than against anyone's memory. Nobody had done anything wrong before the page; they had been solving the same problem with great skill, repeatedly.

The natural home for such a list is a knowledge base with an agents-only visibility state. That makes the workaround one search away for the desk and invisible to clients until someone decides to publish it. QuerySolv's knowledge base has three states (published, agents only, draft), and the agents-only state is where a known-error list lives on that tool. Most desks have an equivalent, and a wiki page with restricted access does the same job with more clicking.

I keep a known-error list on every desk I have run, and it is the document I would save first in a fire. It is never long. Its value is that it is read before the diagnosis starts, not after.

The Five-Ideas Starter Sheet

The sheet below is the whole plan on one page. Fill in the blanks, pin it where the desk can see it, and review it when anyone joins or leaves. Each line is a yes-or-no question, and a "no" tells you what to build next.

FIVE IDEAS, ONE PAGE
Desk: ____________________   Owner: ____________   Reviewed: ________

1. TWO KINDS OF WORK
   Every ticket is marked incident (broken) or request (wanted)
   at intake, by a required field or separate forms.         [ ] yes  [ ] no
   Where: __________________________________________________

2. KNOWN ERRORS
   An agents-only page lists each problem we cannot fix yet:
   symptom, cause, workaround, date last checked.             [ ] yes  [ ] no
   Triage reads it before diagnosing anything.                [ ] yes  [ ] no
   Where: __________________________________________________

3. CHANGE WITH A BRAIN
   Before any production change, a note records what, when,
   and how to undo.                                            [ ] yes  [ ] no
   Risky changes get a second person's glance first.           [ ] yes  [ ] no
   Where: __________________________________________________

4. ONE PAGE OF WHAT IT OFFERS
   One page lists each service, who can ask, how, and how
   long it takes, plus what IT does not do.                    [ ] yes  [ ] no
   Where: __________________________________________________

5. ONE IMPROVEMENT A MONTH
   On the first working day: volume by category, oldest open
   ticket, reopen rate; one decision written in one sentence.  [ ] yes  [ ] no
   Last month's decision: _________________________________
   Did it work? ____________________________________________

"No" answers, in the order we will fix them: _________________________

Everything on the sheet can be done in a month on the tool you have. The week-by-week order is laid out in A Lightweight ITIL Implementation in Thirty Days. The sheet is the destination. The thirty days are the route.

Walking Out of the Store

Five ideas, five artifacts, no purchases, no meetings. That is what a small desk takes from a framework written for a floor plan. And it is enough to answer the auditor, reassure the manager and shorten the queue, in roughly that order of difficulty. The rest of the store will still be there if you ever grow into it.

Walk out slowly. Nobody is going to stop you. Ideas are the only stock the framework was ever trying to move.

Frequently Asked Questions