When to Add Process, and How Much of It Your Desk Needs

Wednesday, 08:45, at Harbourview Clinic. Sam has been the desk lead for nine days. On the shelf behind the desk he has found a ring binder titled "IT Service Management Policy", sixty-four pages. It was written by his predecessor two leads ago. It has a change advisory board, a service catalogue of ninety entries and a four-tier priority matrix with a weighting formula. Nobody follows it. He has also found, in the shared mailbox, a request from the pharmacy raised eleven days ago that nobody has opened. The desk has never had a fixed time at which somebody reads the new requests. The clinic has sixty-four pages of process and no triage. Sam puts the binder back on the shelf, which is where it has done its best work.

A process is an agreed way of doing a recurring thing, written down, that the desk follows without being told each time. Triage at nine and two is a process. A priority rule on one page is a process. The binder is also a process, in the sense that a cathedral is also a shelter. The difficulty with process on a growing desk is that it arrives at the wrong time in both directions. It arrives too late, so that tickets are lost and every answer depends on who you ask. It arrives too early, so that a desk of three approves its own reboots in a weekly meeting. This article is part of our Scaling Support Through Growth series. This article is about timing: which process, at which stage, and how much of it. That amount is always less than the framework says and more than the desk has.

It covers what a process is and what it costs. It covers the process that arrives too late and the one that arrives too early, with the signs of each. It explains lightweight first and what that means in practice. The article covers the order to add process in: intake, then prioritisation, then service levels, then change, with the article that owns each. Next come the three tests before adding any process and the one test for retiring it. The article finishes with introducing a process without a memo, a short war story, and the process ladder by stage to copy, in that order.

What a Process Is and What It Costs

Every process costs time to follow and time to keep. It pays for itself only when the thing it governs recurs often enough, is done by enough people, or goes wrong expensively enough to cover the cost. Triage at set times costs twenty minutes twice a day. It saves the lost request, the duplicate, the "any update?" reply and the loudest-first argument. So it pays on a desk of two from the first week. A change advisory board costs an hour a week of three people's time plus the delay to every change that waits for it. It pays when changes are frequent, risky and made by people who do not talk to each other. That describes a desk of twenty and not a desk of three. The question is never whether a process is good. The question is whether, at this desk, at this size, it pays.

The cost of following a process is visible and the cost of keeping it is not, which is why desks acquire process and rarely shed it. A form with twelve fields costs the requester two minutes a time, visibly. It also costs the desk a quarterly argument about field seven and an hour when the categories change. There is the slow loss of requests from people who have learned to phone instead. These costs are invisible. The library's view of this, developed across the small-team ITIL series, is in the article on the ITIL processes that drown small teams. The one-sentence version is that a process the desk does not need is not neutral. It costs hours and it costs trust, and it does both quietly.

The Process That Arrives Too Late

Process arrives too late on most growing desks, because the people on them are busy with tickets and process is a thing you write when you are not. The signs are consistent. Requests are lost, not through carelessness but because there is no moment at which anyone is responsible for reading new ones. Two technicians give different answers to "which first?", and both are reasonable, because nobody wrote the rule. The same requester gets a confirmation of closure from one technician and silence from another. The hard tickets drift to one name. The new technician learns the desk by asking. The answer to any question about how things are done begins "it depends who you ask".

The cost of late process is paid by requesters first and the desk second. The requester whose request sat unread for eleven days has learned something about the desk that a year of good service will not fully unteach. The desk pays later, in the backlog that late triage builds and in the reopened tickets that a missing close rule produces. It also pays in the hiring request that is really a process gap. The series article on adding heads spends a section unpicking that gap. The test for too late is simple: if the sign is in the queue, the process is overdue. Old and unowned tickets mean triage is overdue. Different answers mean the priority rule is overdue. Reopens mean the close rule is overdue. The queue is a list of the processes the desk has not written. (It is a patient list. It will wait as long as you like.)

The Process That Arrives Too Early

Process arrives too early on desks run by someone who has seen a bigger desk, or read about one. The signs are just as consistent. A form that asks for twelve things when the technician will phone and ask three anyway. A change board of two people who approve each other's reboots on a Tuesday and apply the firewall change on a Thursday without it, because it was urgent. A service catalogue of ninety entries, four of which have ever been requested. A priority matrix with a formula, applied by nobody, because the person triaging knows what is urgent and the formula takes longer than the decision. A policy document with a version number and a review date, both of which have passed.

The cost of early process is that it is routed around, and the routing around becomes the real process, unwritten and unmeasured. Developers who find the change board slow stop submitting changes to it and the board, having nothing to review, reviews the reboots. Requesters who find the form long phone a technician, and the technician, being helpful, fixes it without a ticket. The desk then has the worst of both: the paperwork of a large desk and the record-keeping of none. Sam's binder is the pure case. Sixty-four pages of process that nobody followed had not merely failed to help. They had given the clinic the impression that the desk was well governed. Under that impression the pharmacy's request sat for eleven days.

Lightweight First

The rule for a growing desk is lightweight first. Every process begins as the smallest version that fixes the sign in the queue and fits on one page. A new technician must be able to follow it on their second day from the page alone. Triage is "nine and two, read every new ticket, give it an owner by name and a priority from the rule". The priority rule is a short grid with examples in the cells. The close rule is "say what was wrong, what was done, and ask them to confirm". None of these needs a document with a cover sheet. The library's approach to taking the useful ideas from a large framework without the weight is in Lightweight ITIL Implementation. The five ideas worth taking are in The Five ITIL Ideas Worth Stealing. The rest of this article assumes those two and does not repeat them.

Lightweight is not the same as vague. A one-page process has a trigger, an action, an owner and a check, and all four are written. "We triage regularly" is vague. "The lead reads every new ticket at nine and two, and anything still unowned at four is reported in the huddle" is light. The difference is that the second can be found not happening. A process that cannot be found not happening is a hope, and hopes are what the binder was made of.

Grow a process only when its one-page version has been followed for a quarter and the queue shows a sign it does not cover. The priority rule grows a service-level target when requesters start asking how long things take. The change note grows a review when a change breaks something a second person would have caught. Growth by sign keeps the process the size of the desk. Growth by framework makes it the size of the framework, and the framework was written for someone with a change manager.

The Order: Intake, Then Prioritisation, Then Service Levels, Then Change

Process is added in an order, because each one depends on the one before it. Intake comes first: a fixed time at which every new request is read, given an owner by name and a rough priority, and acknowledged. Nothing else works until this does, because every later process acts on tickets. Tickets that nobody has read are not yet in the desk at all. What triage is, in full, with the discipline of the first touch, is owned by What Triage Actually Is. Triage is the process every desk of two needs in its first week.

Prioritisation comes second, because triage needs a rule to apply and the rule needs to be the same whoever is applying it. The rule is a page: impact and urgency in plain words, with the examples that this desk actually sees in the cells. It includes a sentence about who decides when the requester disagrees. The page, and how to write one that two technicians read the same way, is in A Prioritization Policy You Can Write Down. Alongside it, and usually in the same month, comes the close rule. A desk that triages and prioritises well and closes silently has moved its failure to the end of the ticket. The rule for that is in Avoiding the Silent Close.

Service levels come third, and only after the priority rule has been in use for a quarter. A target for each priority needs the priorities to mean something first. A service level is a promise about response and resolution time per priority, on the desk's working hours. And it is the process requesters feel most directly, which is why it is dangerous to write before the desk knows what it can keep. The plain-words version and the rule about what to promise and what never to are in SLA in Plain Words. Most tools, QuerySolv included, hold service-level targets per priority on a business-hours schedule. With those tools, once the targets are written the tool does the watching. The writing is the work, and the writing waits for the quarter.

Change comes last. On a desk below the first-manager threshold it comes as a one-page record and nothing more. The record says what is being changed, when, by whom, how to undo it, and who was told. The review is fifteen minutes with two people for the changes that could take a service down. It arrives when the desk has had a change go wrong that a second pair of eyes would have caught, and not before. The reasoning, and the test for which changes deserve a review, are in What Change Management Is For. Between service levels and change, the ladder also has rungs for the knowledge base, the escalation rule and the weekly problem review. Each fits where the table below puts it. The big four are named here because they are the ones desks get out of order. The commonest wrong order is change first, because change is the one with a board.

How Much Is Enough: Three Tests and a Kill Test

Before adding any process, apply three tests, and add it only if it passes all three. First, the thing recurs: at least weekly, or monthly if the cost of getting it wrong is high. A process for a thing that happens twice a year is a note in the knowledge base, not a process. Second, more than one person does it, or will within six months. A process one person follows is a habit, and a habit needs no page until a second person has to share it. Third, the cost of doing it inconsistently is higher than the cost of following the page. Lost requests, wrong priorities, silent closes and untested changes all pass this test easily. A standard way of naming screenshots does not.

Then size the process to the smallest version that passes, which is usually a page, and often a paragraph. The temptation at this point is to add the fields, steps and approvals that a larger desk would have, on the grounds that the desk will grow into them. It will not. It will route around them, and the growing will happen in the unwritten route. The page should contain the trigger, the action, the owner and the check. It should be shown to the least patient technician on the desk before it is adopted. That person's objections are the parts that will be skipped.

The kill test runs the other way, once a quarter, over every process the desk has: name the last time this process changed a decision. If the triage rhythm caught a priority-one ticket last week, it stays. If the twelve-field form has had field seven filled in by nobody since the spring, field seven goes. If the change board has reviewed nothing but reboots for two quarters, the board goes and the one-page record stays. A process that cannot name a decision is scenery. And a desk with a lot of scenery looks very well run from the corridor and loses the pharmacy's request in the mailbox.

Introducing a Process Without a Memo

A process is introduced by the people who will follow it, in a week, with a trial month and a date to look at it again. Write the page with the technicians, not for them, because the version written at the desk includes the exception the lead did not know about. Run it for a month with the understanding that it will be changed at the end of the month. That lowers the stakes of the first version to the point where nobody argues about it. At the month's end, ask what was skipped and why. Change the page to match what the desk actually did where that was sensible. Where it was not, make the skipped step harder to skip. The first processes a new desk writes, and the way to write them so they are followed, are in First Processes; the method there is the same at any stage.

Do not announce a process to the organisation unless the organisation has to do something differently. Triage times, the priority rule and the close rule are the desk's business and the requester sees only the result. A service level is announced, briefly, because it is a promise. A change record is not announced; a change freeze is. A memo may announce an internal process to three hundred people who do not need to know. That memo gets the desk a reputation for bureaucracy, which it then has to spend the service levels earning back. Processes should be felt, not read about.

Retiring Process

Process accumulates, because adding one is a decision and removing one is an admission. The quarterly kill test is the remedy. And it is worth saying what retirement looks like, because desks that have never done it find it alarming. A form loses a field, and nobody notices. A review step becomes a note. A category list of forty becomes twelve, with every old category mapped to a new one so history survives. A board stops meeting. Its one useful function, the look at risky changes, moves to a fifteen-minute conversation between the two people who make them. The binder goes on the shelf, which is where Sam's went, and the two pages that were worth keeping go on the wall.

Retiring a process is also how a desk earns the right to add the next one. A desk that only ever adds has a process load that grows with time rather than with need. Its technicians have learned that every new page is permanent. A desk that visibly removes what stopped paying is a desk whose technicians will try the next page in good faith, because they know it can be undone. That trust is the cheapest process asset a desk has, and the quarterly prune is how it is bought.

A Short War Story: The Change Board at Caldera Software

Caldera Software, a forty-person firm with a two-person desk, hired an IT lead called Ingrid from a bank. In her first quarter she set up a weekly change advisory board and a change request form with fourteen fields. She added a rule that no change went in without the board's approval. She had seen all of this work at the bank. The developers, who made a dozen small changes a day, submitted none of them, because the form took longer than the change. The board met weekly to approve the desk's own patching, which it did unanimously. In the fourth month a developer changed a firewall rule on a Friday afternoon to let a client's test system through. There was no form because "the board was for big things". The rule exposed an internal database to the client's network for a weekend before the desk noticed on Monday. The review found no record of the change, no undo plan and no one who could say when it had been made. Caldera spent the following fortnight on a disclosure to the client and an audit of every rule on the firewall. Ingrid replaced the board with a one-page change record that took two minutes to fill in. She added a fifteen-minute review for anything touching the firewall or the directory. The developers used the new process, because it was shorter than the change. Process in the wrong place consumes the attention the right place needed.

The Process Ladder by Stage

The ladder below is the template: five stages, matching the thresholds in What Changes Between Fifty and Five Hundred Employees. Under each are the processes that stage needs, as one-page versions, in the order to add them. Tick what the desk already has, honestly, meaning followed rather than written. The first unticked box at or below the desk's stage is the next process to add. Nothing above the desk's stage should be added yet, however much sense it makes. It will make the same sense in a year, and it will pay then. Keep the ladder with the growth stage card and the capacity check, because the three together are the quarterly review of the desk.

PROCESS LADDER BY STAGE — ONE PAGE
Desk: ______________________   Stage now: ______________   Reviewed: ____________

STAGE 1  THE SOLO ADMIN (around fifty staff)
  [ ] one list of what is open, sorted by age, outside the admin's head
  [ ] the backup page: where everything is, who to call, what to restart
  [ ] the close that tells the requester what was done

STAGE 2  THE SECOND PERSON (around eighty to a hundred and thirty)
  [ ] triage at fixed times; every new item read, owned by name, acknowledged
  [ ] the one-page priority rule, with this desk's examples in the cells
  [ ] the written handover: open, waiting on whom, what will go wrong this week
  [ ] the close rule applied by both people the same way

STAGE 3  THE FIRST TOOL, THREE TO FIVE TECHNICIANS
  [ ] service-level targets per priority on business hours, after a quarter of data
  [ ] the escalation rule: when a ticket moves, to whom, and what the note says
  [ ] categories tied to decisions, ten to fifteen, pruned quarterly
  [ ] the knowledge base: an owner and a date on every article
  [ ] the one-page change record for every change
  [ ] the weekly problem review, one hour, from the repeat-ticket list

STAGE 4  THE FIRST MANAGER (around two to three hundred)
  [ ] the monthly report leadership will read, one page
  [ ] the fifteen-minute change review for the risky changes only
  [ ] the major incident routine: who declares, who leads, who communicates
  [ ] the coverage calendar: leave, cover, on-call if any
  [ ] the quarterly kill test over every process on this ladder

STAGE 5  THE SECOND SITE
  [ ] the catalogue per site: what is supported where, by whom, how fast
  [ ] cover per site and the site visit routine
  [ ] the spares check per site, quarterly
  [ ] the local champion's one-page role

BEFORE ADDING ANY PROCESS (all three must be true)
  [ ] it recurs at least weekly, or monthly with a high cost of error
  [ ] more than one person does it now or within six months
  [ ] doing it inconsistently costs more than following the page
BEFORE KEEPING ANY PROCESS (once a quarter)
  [ ] it changed a decision this quarter; name the decision: ______________________

Sam's ladder, filled in that Wednesday, had the Stage 1 boxes ticked and nothing in Stage 2. That was on a desk of four at a clinic of three hundred that had sixty-four pages of Stage 4 on a shelf. He added triage at nine and two the next morning, the priority rule the following week, and the close rule the week after. He left everything above Stage 3 alone until the spring. The pharmacy's request was found at the first nine o'clock triage. It had been a printer.

Frequently Asked Questions