GoWarm Work · The argument

Half your work is never going to finish. Your tool cannot say so.

Retainers, maintenance, compliance, training, support, facilities. All real work, all owned by someone, none of it heading toward a finish line. Almost every project tool is built on the assumption that a project is a thing that ends — and that single assumption is why your delivery numbers do not survive contact with reality.

Work asks two questions, and they are independent.

The first is whose work it is: a customer's, or your own. The second is whether it ends. Almost every tool models the first and treats the second as a given.

Because the two are independent, all four combinations occur, and each one is 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 like training or compliance that has no end and never should.

Two independent axes of work A two by two grid. The horizontal axis is customer work against internal work. The vertical axis is timeboxed work that ends against standing work that does not. All four cells hold real examples: a client implementation with a go-live, an internal migration with an owner and a date, a managed service retainer, and a standing capability such as training or compliance. CUSTOMER INTERNAL TIMEBOXED STANDING Client implementation Has a go-live. Baseline frozen, gates between stages, drift measured against the plan. Internal migration An owner and a date, no customer. Counts as delivery, not as overhead. Retainer or managed service Never completes. Retired when it ends, so it is not a project stuck at ninety per cent. Standing capability Training, compliance, upkeep. Real work, kept out of the delivery statistics. the half most tools cannot express

Both rows are ordinary work. Only the top row fits a conventional project tool, which is why the bottom row ends up in a spreadsheet, or nowhere at all.

When a tool offers only the top row, the bottom row does not disappear. It gets forced into the available shape — usually a project or task that is opened once and never closed — and from that moment it is quietly corrupting everything the tool reports.

One never-closing item is enough to break a dashboard.

This is easier to see as arithmetic than as an argument. Four items, one of which is a retainer.

What one never-closing item does to a delivery count A worked example with four items: three finite projects at 100, 80 and 60 per cent, and one standing retainer that sits permanently at 90 per cent and is permanently overdue. Counted together, the four average 82 per cent with one item overdue. Counted with the standing item separated out, the three finite projects average 80 per cent with nothing overdue, and the retainer is reported on its own terms as attended or not. FOUR ITEMS IN ONE LIST Client build A 100% Client build B 80% Internal migration 60% Support retainer 90% · overdue The retainer has been 90% for two years. It will always be overdue. TWO WAYS TO COUNT THEM Counted together Average complete: 82.5% Overdue: 1 of 4 Neither figure describes anything real. Counted separately Delivery — 3 items, average 80% Overdue: none Standing — 1 item, attended on 18 of 20 working days Same four items. One split, and both halves become answerable.

A worked example, not a claim about your business. The point is the shape: the same four items produce meaningless figures in one arrangement and answerable ones in the other.

Notice what went wrong on the left. Nobody entered bad data. Nobody was lazy. The retainer is at ninety per cent because somebody had to put a number in a field that should not have existed, and it is overdue because a date was required for something that has no end. The distortion is created by the model, not by the people using it.

And it compounds. Every additional standing item drags the average further from the truth and adds another permanent line to the overdue list. Once the overdue list contains things that will never not be overdue, people stop reading the overdue list — which is how a company ends up unable to see the projects that are genuinely late.

A metric that includes something which can never satisfy it is not a strict metric. It is a broken one, and everyone quietly learns to ignore it.

The three workarounds, and why each one fails.

Teams do find ways around this. They are all worse than they look.

Roll the date forward every month

Someone quietly pushes the retainer's end date out each month so it stops showing as overdue. It works, and it also teaches everyone that dates in the system are decorative. Once that lesson is learned it applies to the real deadlines too.

Keep it out of the tool entirely

The retainer moves to a spreadsheet and the dashboard becomes clean again. The cost is that a meaningful share of the company's effort is now invisible to the company, including to whoever is deciding where to put people next quarter.

Create a fake project every month

"Support — September", closed at month end, recreated in October. The numbers work. What you lose is continuity: no thread runs through the work, so nobody can see what has been happening on that account across a year, which is precisely the question a renewal conversation asks.

Each workaround trades a real property away to satisfy a model that was wrong to begin with. The alternative is to fix the model.

Tracking mode is a property of the project.

Set independently of who the work belongs to, because the two questions are independent.

Timeboxed

Has an end and a definition of done.

  • Baseline frozen when the plan is committed
  • Stage gates hold the next stage shut until the current one is met
  • Drift measured as the difference from the original plan
  • Counts in delivery statistics: complete, overdue, at risk

Standing

Has no end, and is not pretending to.

  • No completion percentage, because the number would mean nothing
  • Retired when the arrangement ends, not completed
  • Excluded from delivery statistics entirely
  • Judged on attendance: was it worked on, on the working days it should have been

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

The reporting question changes with the mode, which is the whole point. For timeboxed work you ask how far along it is and whether it will land. For standing work you ask whether it is being attended to — worked on, on the days it should have been, by whom, and what was done. Both are answerable. Neither is answerable if you insist on asking the first question about the second kind of work.

How to tell which one you are looking at.

The test is not how long it runs. Some timeboxed projects run for two years; some standing arrangements last three months.

Is there a definition of done?

Not a date — a condition. "The plant is commissioned." "The system is live." 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 compliance function is not a thing that happens. If the end would be an ending rather than an achievement, it is standing.

Does effort scale to a finish, or repeat?

Timeboxed work has a shape — ramp, peak, close. 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 timeboxed project slips. A standing arrangement degrades quietly and nobody notices until a customer does. That difference is exactly why attendance is the right measure for one and progress for the other.

The common mistake

Treating a retainer as timeboxed because it has a contract end date. The contract ends; the work has no internal finish line. It is standing work with a renewal date attached.

The other one

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, not disappear into overhead.

Questions this raises

Can a project change mode?

It happens — an implementation that turns into an ongoing managed service is the usual case. The honest handling is to close the timeboxed project against its baseline and start the standing arrangement, so the delivery record of the first stays intact.

How do you measure a standing project at all?

By attendance rather than progress: whether work was recorded against it on the working days it should have been, by whom, and what was done. That is a real measure, just not a completion one.

Does standing work show up for the person doing it?

Yes, on their day exactly like anything else. The distinction is a reporting one, not an experience one.

What about work that is timeboxed but keeps being extended?

That is timeboxed work with drift, and the frozen baseline is what makes the extension visible instead of absorbed. If it extends indefinitely with no definition of done, it was standing work that nobody named.

Do other tools really not do this?

Most offer a recurring task, which is a different thing — a repeated finite item rather than a continuous arrangement. The tell is whether the tool can report on something without asking how complete it is.

Where does this sit in GoWarm Work?

Tracking mode is set on the project, independently of whether it belongs to a customer, and it governs which statistics the project appears in. See the product →

Count your never-closing items.

Open whatever you track delivery in and find the things that have been at ninety per cent for a year. Bring that list to a twenty-minute walkthrough and we will show you what the numbers look like once they are counted separately.

Book a walkthrough Free · 20 min · No obligation