A Lightweight ITIL Implementation in Thirty Days

"I'd like us to be doing ITIL by the end of the month." Lena says it kindly, at 09:10 on the first Monday, and she means it as a compliment. The desk is good, and she would like to say so in a language the board recognizes. The IT team at Northgate Retail is Priya, Marcus and Sam. They have a ticket tool, a wiki with eleven pages, forty-two open tickets, and now a deadline. Nobody has read the framework. Everyone has heard of it.

The request is reasonable and achievable, once you understand what is being asked. ITIL is a published framework of good practice for managing IT services. It is a vocabulary and a set of ideas about running IT as services people rely on, rather than as a pile of machines. It is not software, not a law, and not something a company passes. Nobody can install it. A three-person team can adopt its five most useful ideas in a month, on the tool it already has. In that month, the team can produce the written things that prove it. This article is part of our Pragmatic ITIL series, and it is the practical one.

It covers the principle that makes the month possible, the four weeks with one idea each, and the plan on a page. Next come the five documents and three numbers you own at the end, and what to say to Lena on day thirty. It also covers a war story from a team that did it with a shared mailbox. There is a plan to steal at the end.

The Principle: Adopt Ideas, Not Processes

The month works because you adopt the framework's ideas and leave its processes on the shelf. An idea is a short sentence you can act on tomorrow: separate broken things from wanted things. A process is the procedure a large organization wraps around that idea, with roles, approval steps, forms and a diagram with swim lanes. The ideas are the valuable part. The processes are what the ideas look like after a committee.

The second half of the principle is that you use the tool you have. Any ticket tool can carry the four weeks, and so can a shared mailbox plus a spreadsheet. Every artifact in this plan is a field, a page, or a habit. If your tool makes a step cheaper, take the discount. The temptation on day one is to start comparing ITSM platforms. Close the tab. A new tool arrives with its own month attached.

Each week introduces one idea, produces one artifact, and changes one habit. An artifact is a thing that exists after the week is over: a field, a page, a template, a number on a dated page. If Friday arrives and nothing exists that did not exist on Monday, the week did not happen, however many meetings it contained. It is a short test, and the one I failed the first time. The ideas themselves are laid out in The Five ITIL Ideas Worth Stealing, and what you are leaving behind is in the article on processes that drown small teams.

Week One: Separate the Work

Week one separates incidents from requests, the distinction the rest of the framework stands on. An incident is something broken or degraded: the printer is down, the login fails, the export errors. A request is something someone wants that is not broken: a new account, a laptop for Monday's starter, access to a folder. They arrive looking identical and are not the same work: incidents are about restoring, requests about providing. Mixed together, your resolution time averages a password reset with a three-day server rebuild, and the number describes nothing.

Set it up as one required field, or as two forms. A required Type field with two values, Incident and Request, is the smallest version; the technician sets it at triage when the requester has guessed wrong. Two forms, "Something is broken" and "I need something", push the choice to the requester in words they already use. Do not add a third value yet. "Question" and "Other" will arrive on their own, like houseguests.

The second artifact of week one is the catalog page. It is one wiki page listing the ten services IT provides, in the words the business uses. A service catalog is a list of what IT offers, to whom, and how to ask for it. A service is whatever a person would name if you asked what IT does for them. That could be e-mail, the file shares, the point-of-sale system, the payroll portal, or laptops and phones. It could be the wireless network, printing, new-starter setup, the warehouse scanners, or the finance system. Ten lines, written by Friday. Deciding properly what IT supports is the catalog pillar's job; this month, ten honest lines will do.

At Northgate Retail, Priya added the Type field on Monday at 09:40, required at triage rather than on the form. By Friday the week's sixty-one tickets were sorted: thirty-eight requests and twenty-three incidents. Marcus wrote the catalog page on Thursday in fifty minutes; the hardest line was the warehouse scanners, because nobody had written down who owned them. It turned out to be IT. It had been IT for four years, which nobody had mentioned.

Week Two: The Known-Error List and the Resolution Note

Week two writes down the problems you cannot fix yet. A problem, in the framework's words, is the underlying cause of one or more incidents. A known error is a problem you have diagnosed, cannot or will not fix right now, and have a workaround for. The known-error list is a page with one entry per known error. Each entry has the symptom, the cause as far as you know it, the workaround, and the date you last checked it. Small desks are full of known errors that live in people's heads. The payroll portal is slow on the first login of the day. Everyone knows. Nobody has written it down, so every new technician diagnoses it from scratch.

Build it on Monday from memory and on Tuesday from the queue. Sit the team down for thirty minutes and ask: what do we fix the same way every time? That gives you four or five entries. Then search ninety days of resolved tickets for phrases that repeat, and add two or three more. A wiki page works; an agents-only knowledge article works better, because it is one search away from the ticket. In QuerySolv the knowledge base has three visibility states, published, agents only and draft. The known-error list belongs in agents only, where "we have not fixed this yet" stays in the family.

The habit for week two is the resolution note: three lines written when a ticket closes. They say what was wrong, what was done, and whether this belongs on the known-error list. The third line is the moment one fix becomes a reusable answer instead of a memory. Make it a template in the ticket tool, or a card taped to the monitor. Thirty seconds a ticket. A desk that skips it spends those thirty seconds again next month, with interest.

Sam built the Northgate list on Tuesday with six entries, the slow first login among them. On Thursday a repeat of the slow login was answered from the list in four minutes instead of the usual forty. That is the whole return on week two, and it showed up in week two.

Week Three: The Change Note and the Risky-Change Glance

Week three introduces the smallest version of change management that deserves the name. A change is a deliberate alteration to something in production: a patch, a configuration edit, a firewall rule, a new server. The framework's idea is that changes are thought about before they are made. The large-organization version of that thought is a weekly board approving a form. The three-person version is a change note: four lines, written before you touch anything. They say what you are changing, when, how you will know it worked, and how you will undo it. The last line is the one people skip, and the only one you will need at 17:50 on a Friday.

Decide in advance which changes get a second pair of eyes. A risky change touches something on the catalog page during business hours, cannot be undone in ten minutes, or affects more than one department. For those, the note goes to a colleague for a glance before it happens: not an approval, not a meeting, a glance. Thirty seconds of someone else reading "how will you undo it" catches a surprising number of blanks. Everything else gets a note and no glance.

Keep the notes somewhere searchable, because their second life is as evidence; a wiki page called Change Log with one entry per note is enough. A plain help desk tool can also carry the note as a ticket in a department set up for the purpose. QuerySolv, for example, is a help desk and not an ITSM platform, with no change module. The note lives in a ticket or on the wiki and is none the worse for it. The habit is what makes change management work, not the module.

Northgate's first change note was Marcus's, on Tuesday at 15:30, for a firmware update on the warehouse access point AP-WH-02. The update was set for 06:30 on Wednesday, before the first shift. The undo line read "previous firmware on files.example.com, flash back, fifteen minutes". The change counted as risky because the warehouse is on the catalog page. Priya glanced at it and asked whether the previous firmware had been downloaded yet. It had not. The question took eleven seconds.

Week Four: The Numbers and the First Decision

Week four counts, then decides one thing. Continual improvement is the framework's name for changing how you work on purpose, based on evidence, in small steps that never stop. The three-person version is three numbers read once a month and one change decided because of them. The numbers are tickets opened by type, the age of the oldest open ticket, and the number of incidents that matched a known error. Each answers a question a manager will ask: how much work arrives and what kind, what is stuck, and whether the known-error list is earning its keep.

Pull the numbers on the last working day and write them on a page with the date, the three figures, and one sentence each. Any ticket tool gives you the first two from a filtered view; the third needs the tag or checkbox the week-two habit created. The page is the artifact. The dashboard is not.

Then decide one thing. One. Look at the numbers and the known-error list and choose a single change for next month. That could be a form field that would stop the most common misfiled request or a known error worth fixing properly. Or it could be a service to add to the catalog because the tickets say it exists. Write the decision under the numbers with a name and a date; next month you check whether it happened and whether the number moved. That is the entire improvement process. It fits on an index card, which is more than many organizations with the full binder manage.

Northgate's first numbers page read: 243 tickets, 151 requests and 92 incidents. The oldest open ticket was twenty-six days (a laptop order waiting on a supplier). And 31 incidents matched a known error, about one in three. The decision was to fix the slow first login properly, since it accounted for 14 of those 31. Sam owned it, with a date two weeks out. Lena had the page the same afternoon.

The Four Weeks on One Page

Here is the month in one picture: four blocks, one idea each, and the artifact each leaves behind. Draw it on a whiteboard on day one and point at it on day thirty.

The time column is small on purpose and honest. The month costs a three-person team roughly a working day and a half between them, spread thin. If your plan costs more than that, a process has got in, and the table will show which column it came through.

What You Own on Day Thirty: Five Pages and Three Numbers

At day thirty you own five documents, each on a single page. The first four are the catalog page, the known-error list, the change note template with its log, and the numbers page with its decision. A how-we-work page ties the other four together. Write the fifth in week four, after the others exist, so that it describes something true. A how-we-work page says, in plain words, how a request becomes a ticket and how it is sorted. It says what is written down when it is fixed, how changes are noted, and what is counted monthly.

One page each is a rule, not a target. A page can be read in the time a manager has, printed for an auditor, and kept current by someone who is also answering tickets. A binder can do none of those things; its natural habitat is a shelf, where it ages gracefully and is consulted by nobody. Keep the five together in a wiki section titled "How IT works", each with a last-reviewed date at the top. What to say when you hand that section over is the subject of Talking ITIL With Management Without Lying.

The three numbers stay three until a change has been made because of them. Volume by type tells you what the desk is for. The oldest open ticket tells you what is stuck and needs explaining. The known-error match rate tells you whether week two is paying for itself. If that rate is below one in five after two months, the list is too short or too hard to find. Response and resolution targets belong to later months and to the SLA design pillar. This month, a target you have not measured is a promise you cannot keep.

What to Tell the Manager on Day Thirty

On day thirty, tell the manager the honest sentence, with the five pages behind it: "We have adopted the five ITIL ideas that fit a team our size, on the tools we already had, and here is the page that describes each one, with the numbers from the first month." It does not say "we are ITIL compliant", because there is nothing to comply with. It does not say "we have implemented ITIL", because nobody implements a framework; they adopt parts of it. It says what you did, and it can be checked.

Bring the numbers page and one example of each artifact. A manager who asked for ITIL usually wanted one of three things: to answer an auditor, to answer the board, or to know that the desk is run on purpose. All three are satisfied by five pages and three numbers with a decision under them.

Lena read the page in four minutes and asked one question: "Is this all of ITIL?" The answer was no: it is the part that fits three people, and the rest can wait until the desk is big enough to need it. She put "adopted the core ITIL practices for a team of our size" on the board slide. Every word of it was true, which is rarer on a slide than it should be.

A Short War Story: Meridian Parts

Meridian Parts ran IT for a hundred and forty staff with two people, Tomas and a colleague. They had a shared mailbox that a free tool had turned into a ticket queue, and a wiki. When the finance director asked for "some ITIL" before the insurance renewal, Tomas collected quotes for three ITSM platforms, filed them, and ran the four weeks instead. Week one was a Type field and a nine-line catalog page. Week two was a known-error list with five entries, three about the same aging print server. Week three was a change note template. Week four was a numbers page showing that print server behind one incident in four. The decision was to replace it, which had been "on the list" for two years and now had a number attached. The insurance questionnaire was answered from the five pages in under an hour. The only thing that needed buying was the print server, and it had needed buying all along.

I have run this month twice, once with a proper ticket tool and once with a mailbox and a spreadsheet. The spreadsheet version cost more typing and produced the same five pages. What varied was not the tool. It was whether anyone protected the hour on Friday.

The Thirty-Day Plan to Steal

The plan below is the whole month on one page. Print it, put the three names on it, and check the boxes on Fridays.

THE THIRTY-DAY PLAN
Team: ____________  ____________  ____________     Manager: ____________

WEEK ONE: SEPARATE THE WORK                                  Owner: ________
[ ] Mon   Required Type field (Incident / Request), or two forms.
[ ] Tue   Every open ticket sorted by Type at triage.
[ ] Thu   Catalog page written: ten services, one line each.
[ ] Fri   Count: ____ incidents, ____ requests this week.

WEEK TWO: KNOWN ERRORS AND THE RESOLUTION NOTE               Owner: ________
[ ] Mon   Thirty minutes with the team: what do we fix the same way every time?
[ ] Wed   Known-error list live: symptom, cause, workaround, last checked.
[ ] Wed   Resolution note template: wrong / done / known error? (yes or no).
[ ] Fri   Entries on the list: ____   Closed tickets with a note: ____ of ____

WEEK THREE: CHANGE WITH A BRAIN                              Owner: ________
[ ] Mon   Change note template: what, when, how we know it worked, how to undo.
[ ] Mon   Risky-change rule written: on the catalog page in business hours,
          not undoable in ten minutes, or more than one department.
[ ] Fri   Notes written this week: ____   Peer glances: ____

WEEK FOUR: COUNT AND DECIDE                                  Owner: ________
[ ] Wed   How-we-work page written: one page, five short paragraphs.
[ ] Fri   Numbers page: by type ____ / ____   oldest open ____ days
          incidents matching a known error ____ of ____
[ ] Fri   One decision: ______________________  Owner: ______  By: ________
[ ] Fri   Manager has the numbers page and the five-page section.

DAY THIRTY CHECK
[ ] Five pages, each with a last-reviewed date.  [ ] Three numbers, one decision.
[ ] Nothing was bought.                              Signed: ______________

Keep the signed page; in six months it is the shortest true answer to how the desk came to work this way. By the end of the month Lena had her ITIL, in the only sense in which that sentence can be true. She asked for a copy of the plan to show another department. That is the other thing that happens when the sentence is honest. People borrow it.

Frequently Asked Questions