Scope Creep and the Expanding Catalog

"Can you just reset the projector in the boardroom before the nine o'clock?" Yes. "Can you just see why the coffee machine's screen is frozen?" It is a screen, and you are standing next to it; yes. "Can you just add the new starter to the coffee machine's app?" Yes, apparently. Six months later there is a ticket category called Kitchen, and it has a backlog. Every one of those requests was reasonable. Every yes was kind. Not one of them was a decision.

Scope creep in IT is not an invasion. It is a drift of a thousand reasonable yeses, each too small to argue about, which is how a desk ends up supporting things nobody chose. This article is part of our series on defining what IT supports. The service catalog article gives you the list (what IT provides, to whom, and how to ask for it). The scope boundaries article gives you the lines around it. This one is about what happens to both after they are written: how the list grows, and how to keep it the right size.

It covers how a favor becomes a service in three steps. Then it covers the one intake question that catches it, and the four outcomes for a new request, with a table. Next come how to retire services nobody uses without a fuss, and the annual catalog review in one hour. Then comes the conversation with your manager, in which scope turns out to be a budget decision wearing a disguise. It ends with a scope-decision card to keep at triage.

How a Favor Becomes a Service

A favor becomes a service in three steps, and none of them involves anyone deciding anything. The first step is the first yes. A technician helps with something that is not on the list because it is quick and the person is nice. Saying no would take longer than doing it. The second step is the second person, who heard about the first. "IT sorted the screen for Dana" is a sentence that travels, and it arrives as "IT does screens". The third step is the third person, whose request arrives as a statement rather than a question. "The screen in room three is down again." Again. The word does the work. The service now exists, and the only people who do not know are the people providing it.

The whole sequence takes about three weeks, and it is driven by kindness, which is why it is so hard to stop. Nobody wants to be the technician who said no to a frozen screen. The problem is not the yes. It is that the yes was never followed by the question "and are we doing this now?" A favor done twice is a service. A favor done three times has a response time, and nobody told you what it was.

Favors are not the enemy, and a desk that never does one is a desk nobody likes. The enemy is the unexamined favor: the one that becomes a service without anyone noticing what it did. It cost hours, displaced something in the catalog, and set an expectation for every department that heard. The fix is not to stop helping. It is to notice when helping has turned into providing.

Why Creep Is Expensive

Each uncounted service costs the desk in four ways, and the hours are the smallest of them. The hours are real: a service that produces three tickets a month at twenty minutes each is a working day a year. The desk has perhaps a dozen of those it never agreed to. Fairness is the second cost. The department that asked loudly has a service, and the quiet department that would have asked for the same thing has nothing. That is because nobody wrote a rule, only a precedent.

Expectation is the third cost. A service in the catalog has a "what to expect" line: how to ask, how long it takes, what you get. An accidental service has none, so every expectation belongs to the user, and the user's expectation is the last time it went well. The fourth cost is invisibility. Hours spent on unlisted services do not appear in any report under a name anyone recognizes. So the staffing case that says "we need a third person" cannot point at them. The desk is busy, the numbers say it is fine, and both are true.

The Intake Question

One question, asked at triage of every request that does not match a catalog entry, catches creep before it sets: is this something we do, or something we are deciding to do? If the answer is "we do this", do it. If the answer is "we are deciding", the request still gets handled. In that case, the decision gets made separately, on purpose, by the decision path in the next section. The question does not slow the ticket down. It adds a note to it.

For the question to work, the catalog has to be open at triage. That sounds too easy until you watch a triage pass. The technician reads the ticket, knows what to do, and does it. The catalog is a page they last opened in the spring. Put the catalog where triage happens, as a short list, and make "does this match an entry?" the second thing triage checks after "who is it from?" The helpdesk fundamentals pillar covers triage as a stage. The intake question is one extra line in it.

The ticket that fails the match gets a tag, something like "off-catalog". The tag is the most useful piece of data the desk will collect all year. It costs one click. In a quarter it tells you, by count, what the organization has been asking IT to do that IT never agreed to do. That is the list the annual review and the manager conversation need. Without the tag, that list lives in the technicians' memories, where it is mostly feelings.

Answer the request in the meantime. The intake question is not a reason to leave someone waiting while the desk holds a meeting about the coffee machine. Reply within the normal acknowledgment time: "We'll sort this one. It isn't something we normally do, so I'm also noting it so we can decide whether it should be." That sentence is honest, it is kind, and it tells the requester that a decision exists. Most people, told that, are fine either way. They were never asking for a policy. They were asking for the screen to work.

The Four Outcomes

Every off-catalog request ends in one of four places, and the table below is the decision path. Read the "when" column first. The outcome follows from it. The point of having only four is that the decision takes five minutes. That is short enough to make at the weekly review rather than waiting for the annual one.

Two of the four outcomes are the ones desks forget exist. "Do it once and note it" is the permission to be kind without creating a service. It is the right answer more often than the other three combined. "Best-effort with an owner" means IT tries for a fixed time and promises nothing beyond it. It is the answer for the things that are nearly ours. Those include the meeting-room screen that is a computer until it is a cable, and the badge reader that is a door until it is a network port. The scope boundaries article defines best-effort as a real category with a real promise. Here, it is the outcome that stops a gray area from quietly becoming a black one.

The outcome to reach least often is the third, and not because new services are bad. It is because the third outcome is the only one that costs hours forever. Hours forever is a staffing decision, which belongs to the manager conversation below and not to a Tuesday triage pass.

A Worked Example: The Screens at Meridian Parts

Week one. Sam, on the Meridian Parts desk, fixes the screen in meeting room three at 08:50, nine minutes before the sales meeting. Sam switches the input back from the laptop port. Twenty minutes, no ticket, because there was no time. Week two: two more, both rooms, both inputs, both logged this time, both tagged off-catalog. Week five: "The screen in room three is down again" arrives at 08:41 from the sales lead, as a statement. Triage asks the intake question. The tag count says seven screen tickets in five weeks at about twenty minutes each. That is two and a half hours the desk never agreed to spend, plus the one nobody logged.

The decision takes ten minutes at the Friday review. IT does not own the screens; facilities holds the contract with the installer. But fifteen minutes of IT time fixes six of the seven, because the fault is nearly always the input or the cable. Outcome: best-effort with an owner. Dana writes the catalog line in twenty minutes: "Meeting-room screens: best-effort, up to fifteen minutes, usually the input setting; anything else goes to facilities (Marcus), who hold the installer contract." The request form gets a field: which room. Facilities, shown the seven tickets, has the installer re-seat the cabling in all four rooms the following week. Over the next quarter the screen tickets fall to three. Each takes under ten minutes, and none of them arrives as an emergency. That is because the catalog line says what will happen and the sales lead has read it.

The whole thing cost the desk half an hour of deciding and twenty minutes of writing. The alternative was seven tickets a month, forever, with no owner and a growing sense in sales that IT does screens. I have watched that alternative run for two years on another desk. The screens never got fixed, because nobody with a contract ever found out they were failing.

Retiring Services Nobody Uses

A catalog only grows unless something removes entries, and the thing that removes them is a usage check. Once a year, for every entry, count the tickets it produced in the last ninety days. Zero or near zero makes the entry a candidate for retirement. Either nobody needs it, or they get it somewhere else, or it has merged into another entry without anyone updating the page. All three are reasons to remove the line.

Retire quietly, in three moves. Mark the entry "retiring" with a date a month out, add one line to the scope page's change note, and wait. If nobody says anything in the month, which is what happens to a service with no tickets, remove it. If someone does, you have found a user the numbers missed, and the entry stays, with their name on it as the reason. Announce a retirement only when the service had a user in the last year. A service nobody used does not need a farewell. It needs to stop standing in front of the ones people read.

The reason to bother is the catalog with eighty entries. A list that long is not a catalog; it is an archive with ambitions. The entries that matter are buried among the ones that do not. Nobody reads past the first screen. The "does IT do that?" tickets come back, now from people who looked and gave up. Twenty entries that are all true beat eighty that are mostly history.

The usage check is easier than it sounds in any tool that keeps ticket history searchable. Searching the ticket text for the service's name over the last quarter and noting the count is a two-minute job per entry. QuerySolv's full-text search runs across whole conversations and its reports cover a ninety-day window with CSV export. That is the shape of tool this needs. The check itself is just counting.

The Annual Catalog Review in One Hour

The review is one hour, once a year, with three outcomes: add, change, retire. Three people are enough: whoever runs the desk, one technician who works the queue daily, and the manager who signs the staffing case. Any more and the hour becomes a meeting about the meeting.

• Ten minutes: the usage numbers. Tickets per catalog entry over the last ninety days, read aloud, lowest first.
• Twenty minutes: the off-catalog tag. What did the desk do this year that is not on the list, how often, and how long did it take. Each item gets one of the four outcomes.
• Twenty minutes: the retirement candidates. Each entry with no tickets gets a "retiring" date or a named reason to stay.
• Ten minutes: write it down. The catalog page is updated. The scope page's change note gets its lines. The three or four changes that affect users get a three-line announcement each.

The output is not a document. It is a shorter, truer catalog, a change note, and a list of hours that the manager has now seen with their own eyes. The publishing article covers the change note and the announcement. The review is where they get their content.

The Manager Conversation

Scope is a budget decision in disguise, and the manager conversation is where you take the disguise off. Every "add as a service" is a small hiring decision: it commits hours forever, and the hours come from somewhere. A desk that adds services without that conversation is spending money nobody approved, slowly, in a currency that does not appear on any invoice. Managers notice that eventually, usually as "why is everything taking longer?"

Bring three things to the conversation: the off-catalog count for the year, in hours; the services the new one would displace, by name; and the choice. The sentence is: "We can do this. Here is what it costs in hours a month, and here is what we would do less of. Which would you like?" Not "no". Not "yes". A price in hours and a choice. A choice with a price attached can be decided in a minute. "The desk is overloaded" cannot, because it is a feeling, and feelings do not have budget lines.

The conversation goes wrong when the desk brings only the problem. "We are doing too much" invites "do less", which is not a decision anyone can act on. "We are spending eleven hours a month on screens, badges and the lobby television, none of which is in the catalog; here are three outcomes and what each costs" invites a decision. The decision is the manager's to make. Scope belongs to the people who fund it, and the desk's job is to show them the bill. For a one-person desk the same conversation is sharper and shorter. The one-person IT department pillar covers holding the line when there is nobody to hand the ticket to.

A War Story: Acme's Thirty-One Entries

Acme's catalog began as eleven lines on a wiki page, and two years later it had thirty-one. Nobody had added the extra twenty on purpose. Each was a favor that had been done twice and then written down so the desk would stop being asked whether it was a service. The first annual review, run by Tomas with one technician and the operations manager, took eighty minutes instead of sixty and retired nine entries. Three of the nine were the entries that had produced the most tickets in the whole catalog. They were the lobby television, the meeting-room booking screens, and the visitor badge printer. IT held a contract for none of them, and facilities had assumed IT wanted all of them. Facilities took two of them with their installer. The badge printer was replaced by the building's own system within the quarter. The desk's monthly ticket count fell by about a sixth. Nobody outside IT noticed the nine entries had gone. That was the strongest evidence that they should have gone sooner.

The Scope-Decision Card

Keep the card below where triage happens: printed, pinned, or at the top of the triage checklist. It is the intake question and the four outcomes on one page, with the blanks that make the decision a record rather than a feeling.

SCOPE-DECISION CARD                        Ticket: ________   Date: ________

The intake question:
  Is this something we DO, or something we are DECIDING to do?
  [ ] We do it (catalog entry: ______________________)  -> handle as normal
  [ ] We are deciding                                    -> tag "off-catalog",
                                                            reply, then decide below

What was asked, in one line: _________________________________________________
Who owns the thing, if not us: ____________________  Time it took: ______ min
Times seen before (tag count): ______  Last time: __________

The four outcomes (pick one):
  [ ] DO IT ONCE AND NOTE IT
      Why it is a one-off: ___________________________________________
  [ ] ADD AS BEST-EFFORT WITH AN OWNER
      Time limit: ______ min   Owner beyond that: ______________________
      Catalog line written: [ ]   Scope page updated: [ ]
  [ ] ADD AS A SERVICE WITH A FORM
      Hours per month (estimate): ______   Agreed by (manager): ___________
      Displaces or reduces: _______________________________________
      Entry written: [ ]  Form/field: [ ]  Knowledge note: [ ]  Announced: [ ]
  [ ] DECLINE WITH A POINTER
      Who does it: ____________________  Address: ______________________
      Added to the "who does" table: [ ]

Reply sent to requester (one of the four sentences): [ ]   Decided by: ________

The card is deliberately dull. It is dull so that the decision is the same on a calm Tuesday and on the Friday when four things broke at once. The next "can you just" will arrive tomorrow, and it will be reasonable, and the person asking will be nice. Say yes if yes is quick. Then ask the question, tick a box, and let the coffee machine remain the coffee machine's problem.

Frequently Asked Questions