Running Problem Management in an Hour a Week

Friday, 15:00, at Acme. Ingrid runs a desk of four, and the calendar entry says "Problem review", as it has every Friday for seven months. Theo has the queue for the hour. The other three sit down with one sheet of paper between them, nine lines long. Ingrid reads the first line out: "Problem 2, VPN drops at lunchtime, Rosa." Rosa says: "Investigating. Timeline done, it is the firewall's session limit, I am checking the counter on Monday at 12:30, review next Friday." Ingrid writes "Mon 12:30, counter" in the next-step column and reads the second line. Nine lines take forty minutes. The last fifteen are spent on two candidates from the Friday sort, one of which becomes problem 10 and one of which is declined with a reason. At 16:00 the sheet is photographed and pinned, and everyone goes back to the queue.

The weekly problem review is one protected hour in which the desk reads its problem list, line by line. It makes sure every line has an owner, a next step and a date. It is not a meeting about problems. It is the mechanism by which problems move, and on a small desk it is the whole of problem management. Everything else in this series, the finding, the analysis, the known errors and the fixes, either happens inside the hour or is scheduled from it. This article is part of our Problem Management series, and it is the one about the hour.

It covers why an hour and why weekly, then the problem list: one page, five to ten lines. Next come the hour minute by minute, then ownership and the one-sentence report. The article covers the cadence around the hour, daily to quarterly, then what to drop when the week is bad. It covers keeping the list honest, followed by a short war story and the problem list to copy, in that order.

Why an Hour, and Why Weekly

An hour a week is small enough to protect and large enough to move nine problems, and both halves matter. A desk of four has about a hundred and sixty working hours a week. One of them spent on problems is under one percent of the desk's time. That hour pays for itself if it removes a single eight-minute repeat that happens once a day. Most desks remove more than that in their first quarter. Anything longer than an hour becomes a meeting, with the attendance and the slides that meetings attract, and gets cancelled the first busy week. Anything shorter does not get through the list.

Weekly, because a week is the longest gap across which the desk remembers what it was doing. The Friday sort, described in Finding the Repeat Tickets, produces candidates weekly, and candidates that wait a fortnight are stale by the time anyone looks. An owner who last thought about problem 7 seven days ago can say what the next step is. One who last thought about it a month ago has to re-read the record first, which is the hour spent twice. And a fortnightly review that is cancelled once has a month's gap, which is where problem lists go to die.

The hour is the process. This is the point most desks miss when they try to adopt problem management from a framework and look for the module, the board and the role. On a desk of two to ten, none of those exist and none are needed. What exists is a list, an hour, and the habit of reading one in the other. Cancel the hour and the list stops moving, whatever the tool says. Keep the hour and the list moves, even if it is a sheet of paper. I have watched a desk with a full ITSM suite hold no problem review for a year while the module filled up with records nobody read. The suite was not the problem.

The Problem List: One Page, Five to Ten Lines

The problem list is one page, one line per open problem, with the same columns for each. Those columns are a number, the symptom in a few words, the owner, and the status. Next come the count of linked tickets this month and in total, the next step, and the date of the next review. The last column is the date the problem was opened. The list lives wherever the desk keeps problem records. That could be a department in the ticketing tool, a page in the knowledge base, or a spreadsheet. And the hour reads the list from the top. The list is not the records; each line points at a record with the detail. The list is what fits on one page and can be read in forty minutes.

Five to ten lines is the working limit, and the limit is doing work. A desk that keeps every repeat on the list has thirty lines, reads six of them before the hour runs out, and reads the same six next week. A desk that keeps ten has read all ten by 15:40 and has time for candidates. The remaining repeats are not forgotten; they sit on the Friday-sort tally, counting. When one of them crosses the threshold or something on the list closes, it is promoted. The list is the set of problems the desk is actively moving, and ten is roughly how many a small desk can move at once. More than that is a wish list with columns.

Here is Ingrid's list as it stood that Friday, after the hour. It is shown as a table because that is what it is; the plain-text version to copy is at the end of the article. Read the next-step column: every line has a verb and a date in it, and that column is the entire output of the hour.

The Hour, Minute by Minute

The hour has a fixed order, chosen so that the cheapest and most time-sensitive items come first. That matters on the weeks when the hour becomes twenty minutes. Fixes in their watching period are read first, because a count that is not zero is news and the sooner it is heard the less it costs. Known errors are second, because their counts are the live business cases and their workarounds can quietly stop working. Open and investigating problems are third and take the most time, one sentence each from the owner, a next step and a date. Candidates from the Friday tally are last, because a candidate can wait a week and a watching count cannot. The hour ends with one line written for the week.

Two rules keep the hour inside the hour. The first is that the hour does not investigate. An owner's sentence might turn into a discussion of what the cause might be. In that case, the lead writes "discuss cause, Rosa and Theo, Monday 10:00" in the next-step column and reads the next line. The analysis has its own method and its own time, described in Root Cause Analysis Without a Committee. The review is not it. The second is that every line leaves the hour with a date. "Still looking into it" is not a next step. "Checking the counter Monday 12:30" is. A line that cannot be given a date is a line whose owner needs help or whose problem should be accepted. Either of those is said out loud.

Ownership and the One-Sentence Report

Every line has one owner and every owner reports in one sentence: status, what was done, next step, date. "Problem 2, investigating, timeline done, checking the firewall counter Monday, review Friday." The sentence is a discipline rather than a format. An owner who can say it has thought about the problem this week; an owner who cannot has not. And the gentlest thing the hour can do is let that be visible without comment, because it will be different next Friday. Nobody is asked why nothing happened. They are asked what the next step is, and given a date.

The lead owns the list, not the problems. On a desk of four, the lead might own two or three lines and the others own the rest, spread by who knows the area. The lead's job in the hour is to read, to write in the next-step column, and to decline candidates that do not earn a line. A lead who owns every problem has a list that moves at the speed of one person and a team that has learned problems are not their job. Rotate ownership of new problems so that everyone has owned one by the end of the first quarter. The person who owns a problem learns the system behind the symptom. That is the most useful training a desk can give, and it is free.

On a desk of one, the hour is thirty minutes with the list, and the one-sentence report is said to the sheet. It works, and it matters more, because the solo administrator has no colleague who will notice that problem 4 has not moved since spring. Write the sentence down for each line, in the next-step column, as if someone else will read it on Monday. Someone will, and it will be you, with no memory of Friday. The wider shape of running everything alone is in Running Support Solo. And the half hour is one of the few fixed appointments that article would argue for keeping.

The Cadence Around the Hour

The hour sits inside a cadence that is mostly habits, and the habits are small. Daily, at the moment of closing, each technician asks "have I seen this before?" and links the ticket to its known error or problem if there is one. That takes five seconds and keeps every count on the list honest. Weekly, the Friday sort runs before the hour and hands it the candidates, and the hour hands back a list with dates. Monthly, one afternoon is blocked for permanent fixes, with the queue covered by one person. Each month, one three-line report goes upward: problems closed as fixed, tickets they were generating, and the one fix being asked for next. Quarterly, the three-month read for the slow patterns is done, and the list is pruned.

The daily habit is the one that fails first and quietly. A desk that stops linking tickets at close has a list whose counts freeze on the day the linking stopped. And a freeze looks exactly like a fix: zero new tickets this month. The hour catches it only if someone asks "is that zero because it stopped, or because we stopped counting?" The lead should ask that question of any count that falls to zero without a fix having gone in. The cheapest check is to search for the symptom's words in the week's closed tickets and compare with the linked count. If the search finds four and the count says zero, the habit has lapsed and gets said out loud on Friday.

The monthly fix afternoon is what turns the list from a record into a result. And it is the piece most desks skip, because it is the one that takes the desk off the queue for four hours. Hold it anyway. One or two fixes a month, each with a one-page case and a change record, is the rate at which a problem list shrinks. The mechanics of the case and the change are in Getting the Permanent Fix Done. The afternoon also gives the one-sentence reports something to say; "fix scheduled for the afternoon of the 14th" is a sentence with a date in it. And a list where every fix has a date is a list the desk believes in.

What to Drop When the Week Is Bad

Some weeks the hour is twenty minutes, and the order of the agenda is designed for that. Read the watching counts, because a fix that has failed is costing tickets today. Read the known-error counts, because they are the business cases and they take two minutes. Then give every open problem a date and nothing else: no sentence, no discussion, just "same next step, review next Friday" written down the column. Skip the candidates; the tally holds them for a week without harm. Skip the accepted problems; they are monthly anyway. Twenty minutes, every line dated, hour over. The hour survives a bad week by shrinking, not by disappearing.

Some weeks there is no hour at all, because the building is on fire in the way buildings are on fire on help desks. That is when the one rule applies: move it, do not cancel it. Thursday, Monday morning, fifteen minutes on Friday at 16:45, any of them is a review. A cancelled Friday followed by a normal Friday is a fortnight, and a fortnight is where the counts freeze and the dates lapse. Never cancel two in a row. If the second week is also on fire, the lead reads the list alone for ten minutes and writes a date on every line. That counts.

Know what never gets dropped, even in the ten-minute version. Every line gets a date. The watching counts get read. And the one line for the week gets written, even if it says "no review this week, all dates moved one week, watching counts zero". A list with a note on it is a list someone is still holding. A list with a gap in it is a list that will be found in a drawer in autumn. The weekly queue-hygiene routine in Queue Hygiene: A Weekly Routine has the same rule for the same reason. The two routines sit well on the same afternoon. One keeps the open list honest and the other keeps the closed list from repeating.

Keeping the List Honest

A list stays honest by losing lines as well as gaining them. The hour prunes it with three questions asked of any line that has not moved in two months. Is this still happening? If the count has been zero for two months with no fix, the problem went away, which is a real outcome. In that case, close it as "went away", with the date, and archive the record in case it comes back. Is anyone going to do anything about it? If the honest answer is no, mark it accepted with the reason, set a re-raise threshold, and take it off the weekly read. Is the owner still the right person? If they have changed roles or have four lines and the others have one, move it. A line that survives the three questions stays. A list of ten lines that each survive them is a list the desk can look at without flinching.

Measure the practice by two numbers and report them monthly in the three-line report. The first is problems closed as fixed in the period, with the number of tickets they had been generating per month. That is the hours the desk has stopped spending. The second is tickets linked to open problems as a share of all tickets this month. That is how much of the queue is still made of things the desk already knows about. The first number should be one or two a month and the second should fall over a year. Neither needs a report module; both come from the list and a count of linked tickets. A desk whose tool cannot filter by the linking convention can get both from a spreadsheet export in ten minutes.

Resist the two ways a list goes dishonest. The first is the trophy list, where fixed problems are never closed because the lead likes the length of it. Closed problems go in the archive, and the list shows what is being moved now. The second is the wish list, where every annoyance becomes a line because somebody once said "we should really sort that out". That sentence is the sound of a candidate, not a problem. The Friday tally holds it, the five-times test judges it, and the hour decides. Ten lines, each with an owner, a date and a count, is what problem management looks like on a small desk. It fits on one page because it is supposed to.

A Short War Story: The Cancelled Hour at Northgate Retail

Northgate Retail's desk of five ran a Friday problem review for a year and closed eleven problems in it. Then a store refit programme arrived and the lead, Hana, cancelled the hour for a busy week, then the next. Then she stopped putting it back; nine Fridays passed without a review. In those nine weeks the counts on the list froze on the day the technicians stopped linking tickets. So the list said problem 12, the receipt printers, had generated no tickets since the summer, which everyone read as fixed. It had generated sixty-three. The known error for problem 9, which had been fixed in week two of the gap, stayed published without a fixed-on line. Technicians applied its workaround to a new and different fault on the same tills for two months, which hid the new fault completely. The refit team, meanwhile, asked the desk which till problems to design out of the new stores. The desk, reading its frozen list, named the wrong ones. Hana restarted the hour in week ten, as a twenty-minute version. She spent the first three Fridays finding out what the list had stopped knowing. The cost was two months of a hidden fault across fourteen stores, sixty-three unlinked tickets, and a refit specification written from stale data. Cancelling the hour had not paused problem management. It had switched it off, and nothing in the tool had said so.

The Problem List

The list below is the one page, as plain text, with the columns the hour reads and the lines the hour writes. Keep it wherever the problem records live, print it for the hour if the desk sits together, and photograph the marked-up copy afterwards so the dates survive. The bottom section is the week's one line and the monthly three lines. They are written in the last five minutes and are the only report the practice produces. Ten lines fit on a page at a readable size. If they do not, the list is too long, and that is the finding.

PROBLEM LIST — ONE PAGE
Desk: ______________   Week ending: __________   Reviewed by: ______________
Hour held:  [ ] full   [ ] short (____ min)   [ ] moved to: __________

READ IN THIS ORDER: watching first, known errors, open, candidates, accepted.
Every line leaves the hour with a next step (a verb) and a date.

No.  Symptom (few words)         Owner    Status        Tickets    Next step (verb + date)            Review   Since
___  _________________________   ______   ___________   __ / ___   ________________________________   ______   ______
___  _________________________   ______   ___________   __ / ___   ________________________________   ______   ______
___  _________________________   ______   ___________   __ / ___   ________________________________   ______   ______
___  _________________________   ______   ___________   __ / ___   ________________________________   ______   ______
___  _________________________   ______   ___________   __ / ___   ________________________________   ______   ______
___  _________________________   ______   ___________   __ / ___   ________________________________   ______   ______
___  _________________________   ______   ___________   __ / ___   ________________________________   ______   ______
___  _________________________   ______   ___________   __ / ___   ________________________________   ______   ______
___  _________________________   ______   ___________   __ / ___   ________________________________   ______   ______
___  _________________________   ______   ___________   __ / ___   ________________________________   ______   ______

Status words: Open / Investigating / Known error KE-__ / Fix scheduled /
              Fixed, watching until ____ / Accepted, re-raise if ____

CANDIDATES FROM THE FRIDAY TALLY
  _________________________  count ____  same fix? [ ]  -> [ ] promoted No. __  [ ] kept on tally  [ ] declined: ________
  _________________________  count ____  same fix? [ ]  -> [ ] promoted No. __  [ ] kept on tally  [ ] declined: ________

LINKING CHECK (any count that fell to zero without a fix)
  Symptom words searched in this week's closed tickets: ________  found ____  linked ____

CLOSED THIS WEEK
  No. ____  as: [ ] fixed  [ ] went away  [ ] accepted      No. ____  as: [ ] fixed  [ ] went away  [ ] accepted

THE WEEK IN ONE LINE
  "________________________________________________________________________"

MONTHLY (last review of the month, three lines upward)
  Problems closed as fixed: ____, which were generating ____ tickets a month
  Tickets linked to open problems this month: ____ of ____ total
  The one fix we are asking for next: ________________________________

Ingrid's sheet that Friday ended with "Week: 10 opened, 6 still watching at zero, 5 cable Wednesday, nothing closed." It is not a thrilling sentence, and it was not meant to be. Seven months of such sentences had closed eleven problems, which between them had been generating about ninety tickets a month. The desk's queue was a third shorter than it had been in spring without anyone having been hired. None of that happened in the hour. All of it was scheduled there, one dated line at a time, by three people and a sheet of paper, on Fridays at three.

Frequently Asked Questions