Open whatever you track delivery in and look for the items that have been at ninety per cent for a very long time. Most services businesses have at least one. Agencies and managed service providers usually have several.

They are not stalled projects. Nobody is neglecting them. They are retainers, support arrangements, maintenance agreements — work that is being done well, every week, by people who know exactly what they are doing. The ninety per cent is not a status. It is a number somebody typed two years ago because the form required one.

This looks like a cosmetic problem. It is not. That single item is quietly corrupting every delivery figure you look at, and the mechanism is worth walking through because the usual fixes all make it worse.

The arithmetic

Take four items in one list. Three are finite projects: a client build at 100 per cent, another at 80, an internal migration at 60. The fourth is a support retainer, sitting at 90 per cent and permanently past its end date.

Counted together, that list reports an average completion of 82.5 per cent and one item overdue out of four. Both figures are technically correct and neither describes anything real. The 82.5 includes a number that was invented. The overdue count includes an item that cannot ever not be overdue.

Count the retainer separately and the same four items produce something usable: three delivery projects averaging 80 per cent with nothing overdue, and one standing arrangement reported on its own terms — attended on eighteen of the last twenty working days, say. Two clear statements instead of two misleading ones, from identical underlying facts.

Notice what went wrong in the first version. Nobody entered bad data. Nobody was careless. The retainer is at ninety per cent because a field demanded a percentage for something that has no percentage, and overdue because a date was required for something with no end. The distortion was created by the model, not by the people using it.

Why it compounds

One retainer is a rounding error. The problem is that services businesses accumulate them, and each one drags the average a little further from the truth while adding another permanent line to the overdue list.

The second-order effect is the expensive one. Once the overdue list contains four or five items that will never not be overdue, it stops being a list anyone reads. People learn — correctly — that most of what is on it is noise, and they stop scanning it.

Which means that when a genuinely late project appears on that list, nobody sees it. The permanent residents have camouflaged the actual emergency. This is how a company ends up discovering a three-week delay at a client review rather than on the day it happened, in a business that has an overdue report running every Monday.

The three workarounds, and what each costs

Teams do find ways around this. All three of the common ones trade away something real.

Roll the date forward every month. Someone quietly pushes the retainer's end date out so it stops showing as overdue. It works, it takes thirty seconds, and it teaches everyone in the company that dates in the system are decorative. That lesson does not stay confined to retainers. Once dates are understood to be soft, the real deadlines lose their force too, and you have traded a reporting annoyance for a cultural problem.

Keep it out of the tool entirely. The retainer moves to a spreadsheet, the dashboard goes clean, everyone is happier. The cost is that a meaningful share of your company's effort is now invisible to the company — including to whoever is deciding where to put people next quarter, and including to whoever is trying to work out whether that account is profitable. For an agency where retainers are half the revenue, this is not a small omission.

Create a fake project every month. "Support — September", closed at month end, recreated in October. The numbers work beautifully. What you lose is continuity: no single thread runs through the work, so nobody can see what has been happening on that account across a year. That is precisely the view you need walking into a renewal conversation, and it is now spread across twelve closed containers.

Each workaround gives up something genuine in order to satisfy a model that was wrong to begin with. The alternative is to fix the model.

Two questions, not one

Work asks two independent questions. The first is whose work it is — a customer's, or your own. The second is whether it ends. Nearly every project tool models the first and treats the answer to the second as a given.

Because they are independent, all four combinations occur and all four are ordinary. A client implementation with a go-live. An internal migration with an owner and a date. A managed-service retainer. A standing internal capability such as compliance or training. Only the first two fit a conventional project tool, which is why the other half ends up in a spreadsheet or nowhere at all.

When tracking mode is a property of the work rather than an assumption baked into the software, the handling becomes obvious. Timeboxed work gets a baseline frozen at the start, gates between stages, and drift measured against the original plan. Standing work gets none of those, because they would be meaningless — it is retired when the arrangement ends rather than completed, and it stays out of delivery statistics entirely.

Standing work is not second-class in this arrangement. It is fully tracked, fully logged against, and appears in the manager view and each person's timeline exactly like anything else. What it does not do is appear in a figure that assumes a finish line.

How to tell which you are looking at

The test is not duration. Some timeboxed projects run for two years; some standing arrangements last three months. Four questions sort it faster:

  • Is there a definition of done? Not a date — a condition. "The system is live." "The plant is commissioned." If nobody can state one, it is standing work however firmly a date has been written down.
  • Would finishing it be good news? Completing an implementation is a success. Completing your support function is not a thing that happens. If the end would be an ending rather than an achievement, it is standing.
  • Does effort ramp toward a close, or repeat? Timeboxed work has a shape. Standing work has a rhythm that looks the same in month two and month twenty.
  • What happens if nobody touches it for a month? A project slips. A standing arrangement degrades quietly, and usually a customer notices before you do.

Two mistakes are common enough to name. Treating a retainer as timeboxed because the contract has an end date — the contract ends, but the work has no internal finish line, so it is standing work with a renewal date attached. And treating an internal project as standing because it has no customer — an internal migration with an owner and a date is timeboxed delivery and should count as such rather than disappearing into overhead.

The measure that actually fits

If percentage complete is the wrong question for standing work, something has to replace it. The one that fits is attendance: was this worked on, on the working days it should have been, by whom, and what was done.

That is a real measure with a real denominator. It degrades visibly if the work stops. It supports the conversation you actually need to have about a retainer, which is never "how far along is it" and always "are we serving this account properly and is it worth what we charge".

It also makes the delivery numbers honest again, because the only thing that was polluting them has been given a home of its own.

The longer argument is here, and GoWarm Work sets tracking mode on the project itself, independently of whether it belongs to a customer.