The Cost of a Bad Tool or a Bad Process, Priced in Hours

Friday, 14:50, at Redbrook Engineering. Dev, on the four-person desk, takes a phone call from the drawing office: a new plotter driver, please, on three machines. He writes it on a sticky note, finishes the ticket he was in, and types the sticky note into the ticket system. He opens the asset spreadsheet to find the three machine names and copies them into the ticket. He e-mails the drawing office manager to confirm the request came from someone allowed to make it, waits, and at 16:10 installs three drivers in twenty minutes. The install was the job. The job took twenty minutes. Everything around it took fifty. Dev will do a version of that fifty minutes about seventy times this month. He has never once thought of it as a cost, because it is simply how a request gets done at Redbrook.

An expensive habit is a repeated way of doing something on a desk that costs more hours than the thing needs. It is kept because it is how things are done rather than because anyone chose it. A bad tool creates habits, because people work around what the tool cannot do. A bad process is a habit with a policy behind it, which makes it harder to drop. The cost map in Where the Money Actually Goes shows the hours in lines called rework, walk-ups and overhead. This article goes inside those lines to the individual habits, prices each one, and decides whether it is worth fixing. This article is part of our The Economics of Support series. Every number in this article is a worked example from a fictional desk, in hours.

It covers the habit as the unit of waste, how to find the expensive ones, and how to price a habit in hours. Next come the four commonest: double entry, the walk-up culture, the approval that takes a week, and rework done as a habit. Then it covers the habits a tool makes you keep, and pricing the fix and deciding. A short war story and the habit cost table to copy finish the article.

A Habit Is the Unit of Waste

Waste on a desk does not arrive as waste. It arrives as a step that somebody once had a reason for and nobody has had a reason to remove. The sticky note exists because the phone is not near the ticket form. The e-mail to the manager exists because a request was once made by someone who should not have made it. The asset spreadsheet exists because the ticket system does not know which machine is which. Each step is small, each had a cause, and together they turn a twenty-minute job into an hour and ten. The habit is the right unit to price because it is the unit you can stop. Nobody can stop "overhead". Anyone can stop re-typing sticky notes.

A bad tool and a bad process produce the same symptom and need different cures, so it matters which one you are looking at. A tool habit is a step people take because the tool cannot do the thing directly: the export, the three-place search, the eleven-click close. A process habit is a step people take because a rule says so: the approval, the form, the weekly meeting, the sign-off. Tool habits are fixed by configuring or changing the tool. Process habits are fixed by changing the rule, which is cheaper and harder. That is because the rule has an owner and the owner is in the building.

Pricing the habit is what gets it changed, because an unpriced habit is an opinion and a priced one is a cost. "We spend too much time on approvals" has been said at every desk I have worked on and changed nothing. "The laptop approval costs requesters about sixty hours a month and the desk three, and the approver has never once said no" changed the approval inside a fortnight. The number did not make anyone cleverer. It made the habit visible to the person who could remove it, in the units they understood, with nowhere for the conversation to go but the fix.

Finding the Expensive Habit

Three instruments find habits. The first is the tally week already described in the cost map article. Every technician, for one ordinary week, marks every task that was about the ticket rather than about the problem, with a rough duration. Re-typing, hunting, confirming, updating a second place, attending a meeting about the queue, writing a status update that the requester could have read. Dev's week at Redbrook had eleven distinct habits on it. He had thought of them as the job.

The second instrument is the ten slowest tickets of the month, read with one question: what happened in this ticket that was not fixing the problem? A ticket that took nine working days to resolve a request that took twenty minutes to fulfil has eight and a half days of something in it. The something is nearly always a habit: an approval waiting on a person, a handoff that restarted from the title, or a request bounced to another team and back. The slowest tickets are where habits compound, and reading ten of them takes an hour.

The third instrument is the approval log, where one exists, or a month of requests with a wait in them where it does not. For every request that needed somebody's yes before the desk could act, record how long the yes took and what the answer was. Suppose a desk finds its approvals take a week and are granted nearly every time. It has found a habit with an owner's name on it and a cost that can be stated to the day. Approvals are expensive because the desk does not pay for them. The requester does, in waiting. Nobody has told the approver what their calendar is costing the drawing office.

Pricing a Habit in Hours

The price of a habit is occurrences a month, times minutes each, times people involved, converted to hours, with the waiting it causes on a separate line. Re-typing seventy phone requests at six minutes each is seven hours a month of one person. The laptop approval involves nine requests a month each waiting about seven working days. During that wait, the requester gets by on a shared machine for perhaps an hour of lost time a day. That is about sixty requester hours a month, plus three hours of the desk's chasing. The arithmetic is never hard. The work is the counting, and the counting is the tally sheet and the approval log.

Carry the desk's hours and the requester's hours in two columns and never add them, for the reason that runs through this series. A figure that merges two people's time cannot be checked by anyone. Some habits cost only the desk, like re-typing. Some cost only requesters, like an approval the desk is not party to. The expensive ones cost both, like a handoff that restarts a ticket. The two-column price tells you who will care about the fix, which tells you who to show the table to. The method for estimating the requester column is in The Cost of Waiting. Here it is enough to know it goes in its own column.

Quote ranges, because the tally week was one week and the minutes were estimates. Seven hours of re-typing is "six to nine". Sixty requester hours of laptop waiting is "forty to eighty", because some requesters have a spare machine and some do not. A range is the honest width of a one-week sample. A reader handed a point estimate for a habit will, reasonably, ask how you know.

Double Entry

Double entry is the same information typed by a person into a second place. It is the most widespread habit on desks because every one of its instances is defensible on its own. The phone request goes on a note because the caller is talking. The note goes into the ticket because the ticket is the record. The machine names go into the ticket from the spreadsheet because the ticket does not know them. The spreadsheet is updated from the ticket because the spreadsheet is the asset list. Four entries, one request. Dev's fifty minutes around the twenty-minute install was mostly this, and the only unusual thing about it was that he noticed.

The fix for double entry is one door, and most of the doors already exist. A request that arrives by e-mail, by web form, by chat, or is logged by the technician during the phone call, should become a ticket once, in one queue, with nothing re-typed afterwards. If you run QuerySolv, requests from the web form, e-mail, live chat and social messages all become ordinary tickets in the same queue. In that case, the phone call is the only channel that still needs a human to type it. The cure for that is a two-line ticket raised during the call rather than a note raised after it. In any tool, the test is the same: count the number of times one request is typed by a person, and the number should be one.

The second entry that resists is the one into a different system, usually the asset list. The honest position is that most small-team help desks have no asset module and will not get one. The cheap fix is a field on the ticket form that carries the device tag. That way, the ticket knows which machine it was about and the spreadsheet is updated from a monthly export rather than by hand after every move. The method, and when it stops being enough, is in the asset data series. At Redbrook the field took an hour to add, against three to five hours a month of hand updates and a spreadsheet that had been wrong about eleven machines when anyone last checked. (Nobody had checked for a while. It was a spreadsheet.)

The Walk-Up Culture

The walk-up culture is an organisation's habit of taking its requests to a technician in person rather than to the desk. It is distinct from the unlogged walk-up on the cost map. That was a measurement problem; this is a behaviour with a cost whether it is logged or not. The cost is the interruption, the time to find one's place again afterwards, which doubles a ten-minute request. The cost also includes the queue-jumping, because the person who walked over is served before the person who raised a ticket an hour earlier and did it properly. Redbrook's tally put the walk-ups at about two hundred and fifty a month across four technicians at twelve to fifteen minutes each including the recovery. That is fifty to sixty-five hours, plus the time the walkers spent standing at the desk waiting for a technician to look up. That waiting time is their waiting column.

Do not price the walk-up culture as the walkers' fault, because it is the desk's. People walk over when walking over works better than the ticket. Walking over works better when the ticket is slow, the acknowledgement says nothing, and the technician at the desk is visibly available and kind. The fix is to make the ticket the better route. That means a visible queue so that the walker can see their ticket is in it, and a first reply that says when. It also means a technician's script that logs the walk-up in twenty seconds and says "I've put it in the queue, you're third, I'll have it by three". That replaces either dropping everything or sending the person away. The walker is a requester who chose the fastest door. Make the right door faster.

Price the culture and the fix together, because the fix costs an awkward month. Technicians who have always dropped everything will find it uncomfortable to log and queue a colleague standing in front of them. Both will be fine by the second month if the ticket really is answered by three. The cost of the month is some goodwill and perhaps four hours of Priya's time on conversations. The return is fifty to sixty-five hours a month of interruption becoming queued work, and a queue that is fair again. The shadow channel, where a whole department gives up on the desk and walks over permanently, is the extreme form. Its early signs are in The Seven Ways Support Quietly Fails.

The Approval That Takes a Week

An approval is a step where somebody must say yes before the desk can act. The approval that takes a week is usually the most expensive habit on a desk. The laptop request waits for the department manager, who is in meetings. The software install waits for the committee, which meets fortnightly. The new account waits for a form that needs two signatures, one of them from a person on leave. During the wait the requester is degraded or blocked, and the desk chases. The ticket ages in a status that makes the desk's time-to-resolution figure look terrible for a delay the desk did not cause. Nine laptop requests a month at seven working days each is sixty-three requester-days of getting by on a borrowed machine. The desk's share is the chasing.

Price an approval by asking two further questions: how often is the answer no, and what would have happened if the yes had been assumed? At Redbrook, the laptop approval had been granted on every one of the previous year's requests. That means the step had cost forty to eighty requester hours a month to prevent nothing. An approval that almost never says no is not a control. It is a delay with a signature. The honest price of it is the whole of the waiting it causes, because nothing was bought with that waiting.

The fixes are a pre-approved list, delegated approval, and a deadline. A pre-approved list says that the standard laptop for a named role, or the thirty software titles on the list, need no approval at all. The desk fulfils them on receipt. The committee meets only for things not on the list, which turns out to be a request a month. Delegated approval moves the yes to someone who is at their desk. A deadline says that a request not refused within two working days is approved, which converts the approver's calendar from a blocker into a veto they must exercise. Most small-team tools have no approval step built in and the convention is a note on the ticket. How to run approvals without a workflow engine is in Approvals Without a Workflow Engine. The request type itself is defined in Requests, Approvals and Fulfilment. Redbrook adopted the list and the deadline. The approver was relieved, which is the usual reaction and the one nobody predicts.

Rework as a Habit

Rework is a cost line on the map and a habit when it has a repeatable cause. The three repeatable causes are fixing per person, restarting on handoff, and closing without a note. Fixing per person is the shared-drive fault that twenty people hit and twenty tickets resolve, each in forty minutes, when one problem record and a permanent fix would have taken four hours once. The hunt for those clusters is in Finding the Repeat Tickets. Restarting on handoff is the second technician reading the title and beginning the diagnosis again because the first technician's notes were "looked at it, no luck". Closing without a note is the ticket that comes back in a month as a new ticket, worked from scratch.

Price rework habits by the repeat, not by the ticket. The shared-drive cluster at Redbrook was about twenty tickets a month at forty minutes, eleven to fifteen hours, plus each requester's wait. The permanent fix was an afternoon. The handoff restarts were harder to count. From the slowest-tickets read, they came out at about ten tickets a month where the second technician spent half an hour rediscovering what the first one knew. That is five hours. Both are hours spent on knowledge the desk already had, which is the most irritating kind of hour there is. Both have fixes that are habits in their turn: the problem record, the working note, and the resolution note. The replacement habit costs minutes a day, and it goes on the table too.

Habits the Tool Makes You Keep

Some habits cannot be dropped without changing the tool, and the honest table says which ones. The export to a spreadsheet to count tickets by type is a tool habit if the tool has no report for it. The hunt through three places for a device's history is a tool habit if tickets cannot be linked to each other or to a device tag. The eleven-click close is a tool habit. Each is priced like any other habit. The price is the cost of the tool's gap, a figure that belongs in a tool evaluation and almost never appears in one. The criteria that matter when choosing, including the ones about everyday clicks, are in Evaluation Criteria That Matter.

Separate the tool's habits from the process habits before blaming the tool. That is because most desks that change tools carry their process habits across intact and are surprised to find the new tool is slow too. At Redbrook, of the eleven habits on Dev's tally sheet, three were the tool's: the history hunt, the asset spreadsheet, and a report that needed an export. The other eight were process, and would have survived any migration. The three tool habits were worth about twenty hours a month between them, which is a real number and a smaller one than the Monday meeting alone. Hunting for history is also the one that improves most when both conditions are met. Tickets about the same device or user are linked, and the event history on each ticket records every handoff, as it does in QuerySolv and in most mature tools. Those changes let the second technician read rather than reconstruct.

Count the tool change as a fix like any other, with its own hours, which are large. A migration costs the desk weeks and the organisation a quarter of disruption, and its payback against twenty hours a month of tool habits is long. That does not mean never change tools. It means change them for the right twenty hours, after the eight process habits have been fixed for nothing. Include the migration's cost on the same table as the habits it removes.

Pricing the Fix, Then Deciding

Every fix has a cost in hours. The decision is the habit's monthly cost against the fix's one-off cost, which is the payback period from the previous article in this series. Replacing the Monday meeting with a shared queue view and a ten-minute stand-up costs an hour to set up and an awkward fortnight. Against fourteen hours a month, it pays back before the second Monday. The pre-approved laptop list costs six hours of meetings with the department heads. Against two to four desk hours and forty to eighty requester hours a month, it pays back within the month on desk hours alone. Logging walk-ups and running the queue script: four hours of conversations and a month of discomfort, against fifty to sixty-five hours a month. Each of these is a line on the habit cost table, and the table sorts itself.

Some habits are cheaper to keep, and the table should say so rather than pretend otherwise. A habit costing two hours a month whose fix is a twenty-hour change to a process owned by another department pays back in ten months. That fix will annoy the other department. In that case, write "kept" in the decision column and look again next year. A desk that fixes every habit regardless of payback is spending hours on tidiness. The table's job is to find the five habits that cost most and fix cheapest, and at most desks those five are the majority of the waste. The rest is the ordinary friction of people working together, and some friction is the price of having colleagues.

Do the fixes one or two at a time, in payback order, and re-tally a month after each. A desk that changes six habits at once cannot tell which change did what. The technicians, who are living through the changes, will have a reasonable complaint about the pace. Redbrook's first re-tally, a month after the device field and the end of the Monday meeting, showed about twenty hours a month gone from the overhead line. It also showed the queue no worse for not having been read aloud. Dev's sticky notes had become two-line tickets raised during the call. He said the calls were shorter, which nobody had predicted and everybody should have.

A Short War Story: The Software Committee at Stonebridge Insurance

At Stonebridge Insurance, every request to install software not already on a machine went to a fortnightly software committee. That policy was written years earlier after a licensing scare. The desk lead, Dominik, had never priced it because the desk's only part was to wait. When he finally pulled a year of install requests, there were about a hundred and seventy. The average wait was nine working days. The requesters had mostly been working around the gap for about an hour a day, and the committee had refused two. That was roughly fifteen hundred requester hours and eighty desk hours of chasing in a year, spent to prevent two installations. Both had been free utilities with a licence that permitted them anyway. Dominik took the figures to the committee's chair with a proposed list of thirty pre-approved titles and a two-day deadline for anything else. The committee, which had been dreading its own meetings, agreed in one sitting and thereafter met about once a quarter. An approval that almost never says no is not a control but a delay with a signature. It will run for years at the requesters' expense until someone prices it.

The Habit Cost Table

The table below is the pricing method as a form, one row per habit, filled in from the tally week, the slowest-tickets read and the approval log. The left half prices the habit, in two columns that are never added. The right half prices the fix and gives the decision, which is one of three words. Fill in every habit you found, including the cheap ones, so that the table shows what was considered and left alone. A table with only the fixed habits on it looks like a brag. Sort by the payback column before showing it to anyone, and re-tally a month after each fix to see whether the row has gone.

THE HABIT COST TABLE — ONE DESK, ONE TALLY WEEK
Desk: ______________________   Tally week: ____________   Prepared by: ______________
Sources: [ ] tally sheets from every technician   [ ] ten slowest tickets read   [ ] approval log

HABIT             TOOL OR   TIMES A   MINUTES   PEOPLE   DESK HOURS   REQUESTER HOURS
                  PROCESS   MONTH     EACH               A MONTH      A MONTH (separate)
________________  ________  ________  ________  _______  ___ to ___   ___ to ___
________________  ________  ________  ________  _______  ___ to ___   ___ to ___
________________  ________  ________  ________  _______  ___ to ___   ___ to ___
________________  ________  ________  ________  _______  ___ to ___   ___ to ___
________________  ________  ________  ________  _______  ___ to ___   ___ to ___
________________  ________  ________  ________  _______  ___ to ___   ___ to ___

FOR APPROVALS ONLY
   Approvals in the last year ____   refused ____   average wait ____ working days

HABIT             THE FIX                    HOURS TO FIX   PAYBACK      DECISION
                                             (one-off)      (months)     fix / keep / later
________________  _________________________  ____           ____         ________
________________  _________________________  ____           ____         ________
________________  _________________________  ____           ____         ________
________________  _________________________  ____           ____         ________
________________  _________________________  ____           ____         ________
________________  _________________________  ____           ____         ________

ORDER OF WORK (shortest payback first, no more than two at a time)
   1. ______________________   re-tally on: ____________
   2. ______________________   re-tally on: ____________

BEFORE THIS LEAVES THE DESK
   [ ] Desk hours and requester hours are in separate columns and never totalled together
   [ ] Every figure is a range from the tally week, not a point
   [ ] Each habit is marked tool or process, and no tool change is proposed for a process habit
   [ ] Habits kept are listed with "keep" and a reason, not left off
   [ ] The approver has seen the approval rows before anyone else has

Priya's first table had eleven rows, four marked "fix", five marked "later" and two marked "keep". The two kept rows did more for its credibility with the department heads than the four fixed ones. That was because they showed the desk was not using a spreadsheet to get its own way. The laptop approval row went to the approver first, as the checklist says, with a cup of coffee. He read the requester hours column, said "that's just me being in meetings", and signed off the pre-approved list that afternoon. The habit had run for six years. The fix took a coffee.

Frequently Asked Questions