From Noticing to Acting: The Proactive Loop

Friday, 15:30, on the last Friday of the month, at Pennant Shipping. Freya runs a desk of three for about 300 people across a port office and two terminals. She has an hour blocked in her calendar that says only "the loop". On the table are four pieces of paper: the hotspot cut Ola ran on Tuesday, and the candidates list with two lines circled. Then come the problem list from Wednesday's problem hour, and the maintenance calendar with one line not ticked. Theo has brought the count for the badge-reader driver fix he applied at the east terminal three weeks ago. The hour has five questions in it, in a fixed order, and by 16:30 every piece of paper will have something written on it in pen. Nothing on the desk gets fixed during this hour. It is the hour that decides what gets fixed, by whom, and whether the last fix worked.

The proactive loop is a monthly cycle of five steps, notice, choose, own, fix and measure. It turns a pattern somebody spotted into a cause somebody removed into a count that proves it. Each step has an input, an output and an article elsewhere in this library that owns its mechanics. The loop is the thing that connects them and runs them again next month. This article is part of our From Reactive to Proactive Support series, and it is the one about the habit. The audit, the candidates list, the calendar and the prevention hour from the earlier articles are all things that happen once unless something makes them happen again.

It covers why a loop and not a project, and the five steps in turn. Those are the hotspot, the candidate, the owner and the carrier, the change that makes the fix, and the count that closes it. Then come the loop hour at Pennant Shipping, minute by minute, as a worked example, and what the loop is not. It ends with what to drop when the month is bad, a short war story, and the proactive loop sheet to copy, in that order.

Why a Loop and Not a Project

A project ends and the causes of tickets do not, which is why a proactive programme run as a project is reactive support with a launch date. The audit finds nine causes. A project removes four of them in a quarter, declares success, and is closed. Six months later the audit, if anyone repeats it, finds nine causes again, because the organisation has kept buying docks, hiring people and installing software. The loop assumes this. It is an hour a month, for as long as the desk has tickets. Its measure of success is not "finished" but "this month's count moved and next month's candidate is chosen".

Monthly is the pace because the steps need counts and counts need weeks. A fix applied in week one has produced three weeks of after-data by the month's end, which is the minimum from which anyone can say whether the tickets stopped. Quarterly is too slow: a fix that did not work runs for three months before anyone notices. That is three months of tickets and a candidates list that is out of date. Weekly is the problem hour's pace, and the problem hour already exists for investigation; the loop is for decision. One hour a month, on the lead's prevention hour, is the cost, and a desk of three can afford it without anyone noticing it was taken.

The loop also exists because the five steps are owned by five different habits, and habits do not talk to each other. The hotspot cut lives in a spreadsheet, the candidates list in a document, and the problem list in another. The maintenance calendar lives in the shared calendar, and the before-and-after count in a report nobody has run yet. Each of them works on its own and none of them knows what the others found. The loop is the hour in which they are put on the same table. Without it, the desk has five good practices and no programme. (With it, the desk has five good practices and one more piece of paper, which is cheap for what it buys.)

Step One: Notice, Which Is the Hotspot

The first step takes everything the desk noticed this month and turns it into named causes with counts. Most of what it takes was noticed by somebody else's habit. The quarterly audit from the first article in this series is the big input, once a quarter. The monthly hotspot cuts by device, application, location and group, done the way finding hotspots in the ticket data describes, are the regular one. At Pennant that is Ola's job on the Tuesday before the loop. The daily glance at volume, which catches the spike that is an outage and the slow rise that is a failing system, is in volume as an early warning system. Whatever it caught this month comes to the table. And the technicians' own "I have seen this five times" is the oldest input of all, the one the problem management series starts from. The loop's first question is simply: what did anyone notice.

The output of step one is a line, or several, each naming a cause and not a category, with a count and the hours beside it. "Badge readers at the east terminal gate, nineteen tickets this month, about twenty minutes each, all the same driver fault after the restart" is an output. "Lots of terminal tickets" is a feeling, and feelings are not allowed past step one without a count. If a line arrives with a category and no cause, it goes back to whoever noticed it. The request is to read a month of tickets and tally, which is an afternoon and is the most valuable afternoon the programme has. Noticing is cheap. Noticing with a count is the whole of step one.

Step Two: Choose, Which Is the Candidate

The second step is the candidates list from the previous article, updated with this month's noticing and read against its own rule. The next candidate is cheap, owned by the desk, with a known cause and a known fix. The big one waits with a problem record. The loop chooses one candidate per technician per month, or fewer. A desk of three with three candidates in flight and the queue to hold is at its limit. A desk with eight candidates in flight has eight things half done. The circled lines on Freya's list are the two the desk can finish in the next month's prevention hours. The others are not rejected; they are parked, with a reason, and the reason is read next month to see if it still holds.

Choosing also means un-choosing. A candidate that has been in flight for two months and has not moved is asked why, at this step. The honest answers are that it was harder than it looked, or that its owner lost their hours to the queue. Or the cause turned out to be suspected rather than known. The first two are fixed by re-planning; the third sends the line back to the problem list for investigation, where it should have been. A loop that only ever adds candidates and never parks one becomes a list of fourteen good intentions, and the fourteenth is never reached. The lines that move are the ones the loop keeps few.

Step Three: Own, Which Is the Problem Record

The third step gives every chosen candidate one owner and one carrier, and the carrier is the problem record. A problem record is the one document that follows a cause from the day it was noticed to the day the count proves it gone. It records the symptom, the linked tickets and their running count, and the cause as it becomes known. It records the workaround if there is one, the fix when it is chosen, and the before-and-after count at the end. The record and the "we have fixed this five times" test that starts one are in problems vs incidents. The weekly problem hour that keeps records moving is in problem management in an hour a week. The loop does not run the problem hour. It reads what the problem hour produced and asks whether each record has an owner, a next step and a date.

The carrier matters because the loop is monthly and memory is not. Between one loop and the next, the candidate's owner will spend two or three prevention hours on it, find things, try things, and be interrupted by a major incident. If what they found is in the problem record, next month's loop picks up where they stopped. If it is in their head, next month's loop asks "where did we get to". In that case, the answer is reconstructed from memory, which rounds everything up. The rule that every prevention hour ends with a note, from the prevention hour article, is this step's rule seen from the other end. The note goes on the record, and the record is what the loop reads.

The known-error list is read at this step too, and read for the comfortable entries. A known error is a cause with a published workaround and no permanent fix yet, as known errors and workarounds describes. The loop's question for each one is how many tickets linked to it this month and whether the fix has moved. A known error with a one-minute workaround and thirty linked tickets a month is thirty interruptions the desk has stopped noticing. The loop is where it gets noticed again and, if the count justifies it, chosen as a candidate. Known errors are preparation. The loop's job is to keep asking when preparation can become prevention.

Step Four: Fix, Which Is the Change

The fourth step is the fix, and the fix is a change, with a record, whatever its size. A change in this library's plain words is anything the desk does that alters how something works for more than one person. The one-page record that goes with it, what, why, when, risk, rollback, test and who, is in the one-page change record. Most prevention fixes are small: a setting, a firmware pass, a line in a template, a scheduled restart. Small is not the same as recordless. The badge-reader driver at Pennant's east terminal was changed on fourteen machines in an afternoon. The change record for it took Theo five minutes and said, among other things, which driver version had been there before. That is the sentence that would have mattered if the fix had broken the gate.

The mechanics of the fix are not the loop's business and are owned elsewhere. The scheduled maintenance that removes a pattern, with its window, its notice and its runbook, is in pattern-triggered maintenance. The script that applies a fix to many machines safely, idempotent, logged, tested on one and then five, is in the scripted fixes series. The message to the users who will see the change before they would have seen the fault is in telling users before they notice. The loop asks three things of the fix: is it scheduled, is it recorded, and have the people it will touch been told. If the answers are yes, the owner goes and does it in their prevention hours. If any is no, that is the next step on the record.

Write the counting rule before the fix goes in, not after, because a rule written afterwards is written by someone who already knows the answer. "The cause is the badge-reader driver. The tickets are 'gate reader not responding' from the east terminal. The before count is nineteen a month over three months. The control is the west terminal, same readers, old driver. The after count will be read at the next two loops" is five lines on the record. It is the difference between a fix that can be proved and a fix that can be argued about. The next step depends on it entirely.

Step Five: Measure, Which Is the Count That Moved

The fifth step reads the count for every fix applied in the last two or three months. It writes one of three words on the record: removed, reduced, or returned. The method uses before and after by ticket type, a control type for drift, ranges rather than points, and the counterfactual said out loud. It is in measuring the tickets that never arrived. The loop applies it rather than re-deriving it. Theo's count for the east terminal was two tickets in three weeks against a baseline of nineteen a month, with the west terminal, still on the old driver, at seventeen. That is "removed", with the west terminal as the control that says the drop was the driver and not the season. The record gets the word, the date and the two counts. The west terminal gets the same fix next month, which is the loop feeding itself.

"Returned" is the word that makes the loop worth having, and it is the one desks skip. A fix that did not work sends the tickets on under the same symptom, or, worse, under a slightly different one that the category report files elsewhere. A loop that stops at step four never finds out. When the count says returned, the line goes back to step one with the failed fix as a clue, which is valuable. A fix that did not remove the cause has ruled something out. The problem record is where that gets written down so that nobody tries it again in a year. I have applied the same confidently wrong fix twice, eighteen months apart, on a desk with no record. The second time was not faster.

The measure step is also where the maintenance calendar is checked, line by line, with the three questions from the maintenance article. They are: was it done, what did the category count do, and is the next date set. A line skipped this month is noted; a line skipped twice is reported as a category on its way back. If you run QuerySolv, the standard volume report gives the before-and-after count by ticket type. The event history on each ticket then shows which fix it was linked to, so the measure step is a filter and a glance. In any tool, an export and the agreed form of words in the resolution note do the same job in half an hour.

The Loop Hour at Pennant Shipping

Pennant's loop hour, the one in the opening scene, ran like this, and the shape is reusable. The first fifteen minutes were measure, because the counts are the news and the news goes first. The verdict for the east terminal badge readers was "removed": nineteen to two, control steady. The fix was to be applied at the west terminal next month. The manifest application's print queue restart had been scheduled nightly a month earlier. Its verdict was "reduced", from about twelve tickets a month to five. A note said that the five remaining were all from one shift and probably a different cause. One maintenance line, the quarterly dock firmware check, was not done, and moved to the second week of next month with Ola's name on it. The second fifteen minutes were notice. Ola's cuts showed nothing new by device or location. But the group cut showed the customs team raising the same "cannot open the shared tracking folder" ticket about eight times a month. That went on the list as a candidate with a suspected cause and a tally to be done. The third fifteen minutes were choose and own. The west terminal driver was chosen, owner Theo. The customs folder was parked pending the tally, owner Ola. The one big candidate, the manifest application's slowness at month-end, was still parked with its problem record, its owner and a supplier call booked. The last fifteen minutes were the known-error list, three entries. One of them had twenty-two linked tickets and a workaround that had become comfortable, and was promoted to a candidate for the following quarter. Those minutes also covered the calendar, five lines, four ticked.

Four pieces of paper went into the hour and four came out with pen on them, and the pen is the point. Nothing was fixed between 15:30 and 16:30. What happened was that the desk now knew, in writing, that one fix had worked, one had half worked, and one had slipped. It knew that one new pattern existed, and two people had one candidate each for the month ahead. That is a month's prevention decided in an hour. It is the same hour next month, which is the only reason it keeps being decided.

What the Loop Is Not, and What to Drop

The loop is not the problem hour, which is weekly and investigates; the loop is monthly and decides. The problem hour asks "what is causing this"; the loop asks "which cause do we remove next, and did the last one go". A desk running both will find the loop short, because the problem hour has done the thinking. A desk running only the loop will find step one thin, because nobody has been tallying causes between loops. The loop is also not the quarterly hotspot review. That is bigger, has leadership in the room, and picks one hotspot a quarter to kill, as the quarterly hotspot review describes. The loop feeds that review three months of records and reads its decision back as a parked candidate with an owner.

And the loop is not a status meeting. There is no round-the-table, no "any other business", and nobody reports what they did this month except as a count on a record. The hour is one person, or two, with the papers, and the output is pen on the papers. A loop that grows to six people and ninety minutes has become a meeting, and meetings are where prevention goes to be discussed. If more people need to know what the loop decided, the sheet at the end of this article is a page, and a page can be sent.

When the month is bad, drop steps in a fixed order and never drop measure. A major incident week, two technicians on leave and a queue at sixty is a month in which no new candidate is chosen and nothing is parked or unparked. That is fine, and the loop takes twenty minutes. What it still does is read the counts for the fixes already applied and check the calendar. A fix that returned during a bad month is producing tickets into a queue that cannot afford them. A calendar line skipped during a bad month is exactly the line that will be skipped again next month unless someone writes it down. Measure survives everything. It is the step that makes the other four true.

A Short War Story: The Loop That Stopped at Fix, at Meridian Parts

Meridian Parts' desk of four, led by Casper, ran a proactive loop for a year that was, on paper, exemplary. It had a candidates list, an owner per line, and a fix most months. It had a quarterly report that listed every cause removed with its before count beside it. The report never had an after count, because the loop had five steps on its sheet and four in practice. Measure had been dropped in the second month, on a bad week, and had not come back. Nobody noticed because the report looked complete without it. By the fourth quarter the report claimed about ninety tickets a month removed across eleven causes. The finance director, who read the overall volume chart out of habit, pointed out that total tickets had fallen by about twenty. Casper spent a fortnight reconstructing after counts from the ticket history and found that four of the eleven fixes had not worked. Two had moved the tickets into a neighbouring category. The stale-credential fix had been reverted by an update three months earlier and was producing lockouts at the old rate under a workaround nobody had reviewed. The cost was the fortnight, the credibility of every number the desk had reported that year, and the hour. The hour survived the review only because Casper brought the honest table to it himself. A loop without the measure step is a list of good intentions with dates on it.

The Proactive Loop Sheet

The sheet below is one page a month, filled in during the loop hour, filed with its predecessors, and sent to whoever needs to know what was decided. Sections A to E are the five steps in order, each with room for the few lines a small desk will actually have. The measure section comes first in the hour but sits last on the sheet, because the sheet is read top to bottom by people who were not in the room. Section F is the short list of what was dropped if the month was bad, with the reason. That makes a dropped step a decision and not an omission. Twelve of these in a folder are the programme's history, and the quarterly report in the last article of this series is written from them.

THE PROACTIVE LOOP — ONE HOUR, ONE MONTH, ONE PAGE
Desk: ______________________   Month: ____________   Loop held on: ____________   By: ______________

A. NOTICE — what was seen this month, with a count (a cause, not a category)
   Source (audit / cut / volume glance / "five times")   Cause named                              Tickets/mo   Hours/mo
   __________________________________________________   _______________________________________   ______       ______
   __________________________________________________   _______________________________________   ______       ______
   Sent back for a tally (category, no cause yet): ________________________________  by: ______________

B. CHOOSE — this month's candidates (one per technician at most)
   Candidate                                   Owner          Cheap / owned / cause known / fix known?   Finish by
   ___________________________________________  ___________    ____ / ____ / ____ / ____                   __________
   ___________________________________________  ___________    ____ / ____ / ____ / ____                   __________
   Parked, with reason: ______________________________________________  Unparked this month: ______________
   In flight two months and not moved: ______________________  why: harder / hours lost / cause only suspected

C. OWN — the carrier for each chosen line
   Candidate                        Problem ID   Owner        Next step                           Date
   _______________________________  _________    __________   _________________________________   ________
   _______________________________  _________    __________   _________________________________   ________
   Known errors reviewed: ____   with linked tickets this month: ____ / ____ / ____   promoted to candidate: ______________

D. FIX — for each fix due next month
   Fix                               Change record?   Window        Users told?   Counting rule written? (before ____, control ______________)
   ________________________________  yes / no         __________    yes / no      yes / no
   ________________________________  yes / no         __________    yes / no      yes / no

E. MEASURE — every fix applied in the last three months
   Cause fixed                       Fixed on    Before/mo   After/mo   Control before/after   Word: removed / reduced / returned
   ________________________________  ________    ______      ______     ______ / ______        ______________
   ________________________________  ________    ______      ______     ______ / ______        ______________
   Returned lines sent back to A with the failed fix noted on the record: ______________
   Maintenance calendar: lines due ____  done ____  skipped ____  (skipped twice, category returning: ______________)

F. IF THE MONTH WAS BAD
   Steps dropped this month: ______________   because: ______________________________
   Measure was done: yes   (it is always done)

Freya's sheet for that Friday had two lines in A, two in B, three in C, one in D, two in E and nothing in F. It took the last ten minutes of the hour to write. The west terminal got its driver in the second week of the following month. Its count, at the next loop, was one.

Frequently Asked Questions