The ITIL Processes That Drown a Small Team

Tuesday, 14:00, meeting room two. The change advisory board of Meridian Parts is in session. Present: Dana, who proposed this week's three changes, and Marcus, who proposed the other two. Dana reads out her changes and Marcus approves them. Marcus reads out his and Dana approves them. The minutes are taken by Dana, reviewed by Marcus, and filed in a folder nobody has opened since the folder was created. The meeting takes fifty minutes. The company has two IT people, and both of them are in it.

Nobody designed that meeting. It arrived, the way overweight process usually does, and this article is about where it comes from and what to do with it. It is the third in our Pragmatic ITIL series. ITIL, for anyone joining here, is a published framework of good practice for managing IT as a set of services. The first two articles argued that a small desk should take five of its ideas and leave the rest. This one is about the rest: the parts that look like diligence and behave like ballast.

It starts with how overweight process arrives, then the six usual suspects, one section each. Next come a table for recognizing overweight process by its symptoms and the cuts, with numbers from a desk that made them. Then comes a war story from a bank's branch team whose forty-field form made a third of its tickets disappear. It ends with what to keep even when you are small, and a process-diet checklist to copy.

How Overweight Process Arrives

Overweight process is any step the desk performs that costs more than the risk it removes, and it almost never arrives because someone chose it. It arrives by three routes, all well meant.

The first route is a template from a larger organization. A new manager brings the ticket form from their last job, where it had forty fields because a department of sixty routed tickets to nine groups. A parent company sends down its change procedure, written for a data center. The template was right where it came from. Nobody checks whether the shape still fits, because a template looks finished, and finished things are hard to argue with.

The second route is a consultant with a maturity model, a grid that scores each process from "ad hoc" to "optimized". The model is honest about what it measures. The trouble is that every low score reads as a gap, gaps turn into recommendations, and recommendations turn into a change board for a two-person team. A maturity model has no column for "appropriately small". It would be the most popular column.

The third route is an audit finding read too literally. The auditor writes "no formal change approval process observed", which means "write down what you do before you change production". The desk reads it as "convene a board", and the board is born the following Tuesday. The finding was correct; the response was ten times its size. Answering a finding at its own size is the subject of Talking ITIL With Management Without Lying.

The Weekly Change Board for Everything

The change advisory board is the framework's name for the group that reviews changes before they happen. In a large organization, the person changing the firewall does not know what the person changing the database is doing that night. That is why the board exists. On a desk of two or three, everyone knows what everyone is doing, because they can hear it. The board adds a meeting to information the team already has.

The cost is not the fifty minutes, although fifty minutes a week is a working week a year. The cost is latency. A change that could be made on Wednesday waits for Tuesday, so the user waits. The technician who knows the change is safe makes it anyway and records it afterward. That turns the board into a body that ratifies the past. Once that happens nobody respects the board, and nobody says so, because it is in the audit file.

What the board was for still matters. Someone other than the person making a risky change should look at it first, and there should be a record. Both survive the cut, as a three-line note and a peer glance.

The Forty-Field Ticket Form

The forty-field form is the intake form that asks the user for everything the desk might ever need, on the theory that collecting it once saves asking later. It collects asset tag, building, floor, desk number, cost center, manager, impact on a five-point scale, and urgency on another. Then come category, subcategory, affected service, affected component, and so on. The user, who wanted to say "my screen is black", has answered twelve questions about a screen.

The cost is tickets that never get logged. A form that takes six minutes competes with a walk to the IT office that takes two. The walk wins, so the work gets done and the record does not. The count falls, and the staffing case is built on the wrong number. The fields that were collected are wrong anyway, because nobody who filled it in knew what "impact: 3" meant. The form never said. A form is a conversation with a stranger. Forty questions is an interrogation.

What the form was for still matters. The desk needs enough to start: who, what, since when, how many people, how urgent, and a way to reach them. Six fields. The rest can be asked by a person, once, in the few cases where it matters.

The Catalog With Eighty Entries

A service catalog is the written list of what IT offers and how to ask for it. The eighty-entry version happens when the list is written by the people who provide the services rather than for the people who use them. Every server becomes an entry. Every application gets an owner, a cost code, four paragraphs and a service level. The result is a document that is complete, correct, and never opened.

The cost is that the catalog stops doing its job, which was to tell people what they can ask for and where. Nobody reads eighty entries to find out how to get a laptop. They ask in the corridor, which brings back the untracked request the catalog was meant to end. The desk, meanwhile, owns eighty promises it did not mean to make.

What the catalog was for still matters. One page, ten to fifteen lines. Each says what the service is, who can ask, how, and roughly how long. Add a line about what IT does not do. The Defining What IT Supports pillar covers how to draw those lines. The page should be short enough to read standing up.

The SLA Matrix With Twenty Cells

A service level agreement, or SLA, is a written promise about how quickly the desk will respond and resolve. The twenty-cell matrix happens when five priorities meet four targets each. The targets are first response, resolution, subsequent responses and update interval, for critical, high, medium, low and planning. Each cell holds a number. Each number is a promise. Twenty promises, made by three people, to an organization that will remember exactly one of them, the one that was missed.

The cost is that nobody can hold twenty numbers in their head. So the matrix lives in a document and the desk runs on instinct. The first time the two disagree the document wins, in a meeting. A matrix also invites gaming. Tickets get downgraded to a priority whose cell is achievable, which is accurate on paper and dishonest in practice, and users can tell.

What the matrix was for still matters. Users deserve to know roughly how fast to expect a response, and the desk deserves a target it can measure itself against. Four rows do it: a response and a resolution target for the two priorities the desk actually uses. The SLA Design pillar has the full method, including what never to promise.

The Role Catalog That Gives Three People Eleven Titles

The framework names a role for each of its processes (an owner, a manager, sometimes a coordinator and an analyst). In a department of eighty those roles are held by different people who would otherwise tread on each other. On a team of three the same three names appear in every box. Dana is the incident manager, the problem manager, the change manager and the knowledge manager, and she is also the person who fixes the printers.

The cost is confusion presented as clarity. An org chart with eleven roles and three people implies a structure that does not exist. So a new starter spends the first week learning who the change manager is, and the answer is "whoever is in". The roles also breed documents, because each role owns a process document, and the documents describe meetings the roles would attend if the roles were people.

What the roles were for still matters. Someone should own each of the five artifacts: the type field, the known-error page, the change note habit, the catalog page, the monthly numbers. Three people can own five things without a title each. A tool's permission presets are usually all the role structure a small desk needs. QuerySolv ships four, from Trainee to Senior, and I have never seen a three-person desk need more. Write the five owners on the starter sheet from The Five ITIL Ideas Worth Stealing and stop.

The Review Meeting About the Review Meeting

Every process in the framework can be reviewed, so every adopted process grows a review. There is the weekly incident review, the monthly problem review, the change review, and eventually the quarterly review of whether the reviews are working. On a three-person desk every one of those meetings is attended by the same three people, discussing work they did and already discussed while doing it.

The cost is the hours, multiplied, and a subtler thing: a meeting with a name feels like progress, so the review replaces the improvement. The desk reviews the slow-login problem monthly for six months and never spends the one hour that would have found the cause. Reviewing is easier than fixing, and it produces minutes.

What the reviews were for still matters. Once a month, thirty minutes, three numbers, one decision, written down. That is the whole review calendar for a small desk. Everything else is a meeting about the meeting.

Recognizing Overweight Process

Overweight process is easier to recognize by its symptoms than by its size, because every process looks reasonable from inside. The table below pairs each sign with the question to ask and the cut that usually follows.

The middle column is the important one, because a cut is only safe when the answer is known. "What is the process protecting against?" has a one-sentence answer for every process in the framework. Keep the sentence. Cut the process down to whatever the sentence actually needs.

The Cuts, With Numbers

Each suspect has a cut that keeps what it was for and removes what it costs. Here are the four most common, with figures from Northgate Retail's two-person desk after Priya and Marcus made them over one quarter.

The change board becomes a note plus a peer glance for risky changes. Every production change gets three lines in the ticket (what, when, how to undo). Changes that could take a shared service away from many people get a second person's eyes on those lines first. At Northgate the Tuesday board had cost two people fifty minutes a week. The note takes two minutes per change, the glance about ninety seconds. In a typical month of eleven changes four needed the glance. Time spent fell from about three and a half hours a month to under half an hour. The record improved, because it was written before the change rather than reconstructed after.

Forty fields become six. Northgate's form, inherited from a previous manager's previous employer, took Lena on the shop floor six minutes to fill in. The six-field version (name, what is wrong or wanted, since when, how many people affected, how urgent in your own words, best way to reach you) took ninety seconds. The vanished fields were asked by a person in the eight percent of tickets where they mattered. Logged tickets rose from a hundred and sixty to two hundred and ten a month. That was not more work. It was the same work, counted.

The catalog becomes one page. Northgate's catalog had sixty-three entries. The one-page version had fourteen lines and a fifteenth saying what IT did not do (personal devices, the franchise tills, the coffee machine). The page was read two hundred times in its first month. The sixty-three entries had been read nine times in a year, six of them by the person who wrote them.

The SLA matrix becomes four rows. Twenty cells became two priorities, urgent (many people, or a deadline) and normal (everything else), with a response and a resolution target each. Urgent: respond within one hour, resolve within one business day. Normal: respond within four business hours, resolve within five business days. Priya could recite it, and so could the store managers, which had never been true of the matrix. Breaches fell from nineteen a month to four, partly because the targets were realistic and partly because tickets stopped being downgraded into achievable cells.

A Short War Story: The Forty-Field Form at Bluewater Bank

Bluewater Bank's branch IT team, three people covering eleven branches, inherited a ticket form from head office with forty fields. Each made sense for a group of sixty supporting a trading floor. Within a month of the form going live, logged tickets fell by a third, from about two hundred and forty to a hundred and sixty. For a week the team lead, Sam, took that as good news. Then he noticed that his technicians were as busy as ever and that branch staff had started catching them in the parking lot. The work had not fallen; the logging had, because a six-minute form lost every time to a two-minute conversation. Sam cut the form to six fields and kept the rest as optional questions a technician could ask when they mattered. The count climbed back past two hundred and thirty within the following month. Head office, when asked, had never needed more than the six from a branch. The form had been sent whole because that was easier than deciding which fields to send.

I inherited a form like that once, and I defended it for a month because it had come from somewhere bigger, and bigger felt like better. The tickets I was not seeing were the ones that taught me otherwise.

What to Keep Even When Small

Cutting process is not the same as having none. Three things survive every diet, because each removes a real risk at a cost of minutes. They are the note before a change, the incident/request split and the known-error list. A desk that drops them to save time will spend the time on Monday instead.

Keep the note before a change. Three lines, written before the work: what, when, how to undo. It is the cheapest insurance in IT, the thing the auditor most wants to see, and what the change board was always for. A tool that records every ticket action with a snapshot of the ticket's state, as QuerySolv does, gives you the history of what was done. The note is the only record of what was intended, which is the half that history cannot reconstruct.

Keep the incident/request split. One required field at intake, broken or wanted, costs nothing and sorts the fire from the shopping list before anyone reads the queue. Without it the urgent waits behind the routine, and the month-end numbers cannot say where the time went.

Keep the known-error list. One agents-only page, one line per problem you cannot fix yet, read at triage before anything is diagnosed. It turns a forty-minute ticket into a four-minute one and costs ten minutes a week to maintain. Drop it and the desk re-solves its own history, with great skill, forever.

Everything else has to earn its place by answering the question in the table's middle column, and most of it will not. That is fine. The framework was written for a building, and you have a desk.

The Process Diet Checklist

The checklist below is the diet on one page. Work through it once, cut what fails, and keep the page, because the next template from somewhere larger will arrive within the year.

THE PROCESS DIET
Desk: ____________________   Reviewed by: ____________   Date: ________

FOR EVERY PROCEDURE, MEETING, FORM OR DOCUMENT THE DESK RUNS
   Name: _______________________________________________
   What risk does it protect against? (one sentence)
   ____________________________________________________
   Minutes it costs per week, all people:  ______
   Would anyone notice if it stopped?  [ ] yes  [ ] no
   [ ] keep   [ ] cut to smallest version   [ ] drop

THE SIX SUSPECTS
   Change board meets for every change     -> note + glance for risky ones   [ ] done
   Intake form has more than six required  -> six fields; ask the rest       [ ] done
   Catalog longer than one page            -> one page + "not ours" line     [ ] done
   SLA targets nobody can quote            -> four rows, two priorities      [ ] done
   Role titles outnumber people            -> one owner per artifact         [ ] done
   Reviews that have produced no decision  -> monthly 3 numbers, 1 decision  [ ] done

NEVER CUT
   [ ] Three-line note before every production change (what, when, undo)
   [ ] Incident / request field at intake
   [ ] Known-error page, read at triage
   [ ] Thirty minutes a month: three numbers, one written decision

Procedures dropped this quarter: ______________________________________
Minutes a week returned to the queue: ______

Run the page once a quarter regardless. Process grows back quietly, one reasonable addition at a time, and no meeting ever proposes its own cancellation. The page has to do that for you. The plan for building the small version from nothing, rather than cutting down to it, is in A Lightweight ITIL Implementation in Thirty Days.

At Meridian Parts the Tuesday meeting still exists, in a sense. Dana writes three lines before a change. Marcus reads them when the change is risky, which takes ninety seconds and happens at his desk. The folder is still there, with better contents. Meeting room two is free on Tuesdays, and nobody has missed it.

Frequently Asked Questions