Work slips before it is late
By the time a task is overdue, the decision that made it late was taken weeks earlier. The signals were all present and none of them were being counted.
A task becomes late on a particular day, and on that day somebody notices.
The thing that made it late happened much earlier — a date quietly moved, a dependency that never arrived, a person who took on three things in a week when they normally take two. All of those were visible at the time. None of them were counted, because organisations track completion and lateness, and slippage is neither.
Lateness is a lagging indicator#
By definition, a task is late after the point at which anything could have been done about it cheaply.
Everything useful happens in the period before. That period is where a conversation costs five minutes, where material can still be ordered, where an approval can still be chased in time. Once the date has passed, the same problem costs the delay plus the disruption to everything sequenced behind it.
So a board showing what is late is a report on decisions already made. Useful for accountability, useless for prevention.
The signals that precede a slip#
None of these is subtle. All of them are present in ordinary task data.
The date has moved before. Overwhelmingly the strongest signal. A task pushed once is a task with a reason; a task pushed twice is a task with a problem. Very few systems count pushes at all, because the field just gets overwritten.
The remaining time is small relative to how long this kind of work usually takes. Requires knowing the second number, which requires having kept histories.
It has not moved at all since it was created. A task with no activity is not necessarily stuck, but a task with no activity and an approaching date nearly always is.
It is waiting on somebody who is unavailable. Leave, travel, or simply carrying an unusual number of open items. This one is computable from the same system that holds the leave calendar and is almost never joined up.
Its dependency has slipped. Obvious, and requires that dependencies are recorded, which on most projects they are not except in a programme file that nobody updates.
Nobody has asked about it. Work that people are talking about tends to move. Silence around an item with a near date is a real signal.
Counting pushes properly#
If you do one thing from this piece, count how many times a due date has been changed and by whom.
It is one extra row per change and it converts an invisible pattern into a visible one. It also changes behaviour on its own, mildly and usefully: a date that is known to be counted is moved more thoughtfully.
Two cautions.
Distinguish a push from a reschedule. A date changed because the whole programme moved is not the same as a date changed because this task did not get done, and lumping them makes the count meaningless.
Do not make the count punitive. The moment pushing a date becomes a black mark, people stop pushing dates and start letting them pass silently, which is strictly worse — you lose the signal and gain nothing. The same dynamic that governs escalation without shame applies here exactly.
Say why, or the warning is noise#
A predicted slip has to arrive with its reasoning attached.
This is at risk is a number somebody either believes or dismisses, and after the second wrong one they dismiss all of them. Pushed twice, two days left, similar work usually takes five, waiting on an approval that has been open a week is a sentence somebody can act on, argue with, or dismiss for a good reason.
The requirement generalises well beyond risk scoring, and it has its own piece: the app should tell you why.
Accuracy is the whole asset#
Our first version of slip scoring counted every order settled stage-by-stage as money not yet paid, because a staged payment never wrote the field meaning paid. That put a large amount of pure noise onto a board whose entire purpose was to show what needed a human.
The board did not become partly useful. It became ignored — and it was ignored wholesale, because people do not learn to discount one category of false positive while staying alert to everything else on the same screen.
A warning system's precision is not a quality attribute to be improved over time. It is the thing itself. A board that is right most of the time is worth approximately nothing, because the cost of checking a wrong warning is the same as the cost of checking a right one, and after a few weeks nobody checks.
The stuck strip#
The other half of prediction is description, and it is much simpler.
Every task in our system now carries a plain statement of why it is stuck: what it is waiting for, who it is waiting on, and how long it has been waiting. Not a status code — a sentence.
This does more work than it sounds like. Most of the questions asked in project meetings are that question, asked out loud, one item at a time. Answering it on the item itself removes the meeting's main activity and, more importantly, makes the answer available to the person who could have unblocked it, who was not in the meeting.
It also makes the absence of an answer conspicuous. A task that cannot say what it is waiting for is usually a task nobody has looked at, and that is worth knowing on its own.
What to build first#
In order of value for effort:
- Count date changes. One field, enormous signal.
- Put a plain "waiting on what, since when" line on every item.
- Join to the leave calendar, so work assigned to somebody who is away is visible as such.
- Keep durations, so "how long does this kind of thing usually take" is answerable at all.
- Only then, score. A score built on the first four is defensible. A score built on nothing is a random number with a colour.
Most organisations attempt the fifth first, because it is the one that looks like a product. It is the one that requires the other four.
The short version#
By the time something is late, the decision that made it late is weeks old.
The signals that precede a slip are ordinary and mostly uncounted — pushed dates above all. Count them, say why when you warn, warn only the person who can act, and never let the warnings be wrong often enough to be dismissed.
And put one honest sentence on every piece of work saying what it is waiting for. It answers, in advance, the question every status meeting exists to ask.