How should project task ageing be reviewed?
By owner, oldest-first, across every module at once — never module by module. The person carrying eleven overdue items spread across five modules is invisible in all five and unmistakable in a single combined list.
The module view hides people
Look at your RFI log: two items overdue for that engineer. Reasonable. The NCR log: two more. The submittal log: three. The issues log: two. The meeting actions: two.
Each list looks fine. The person is carrying eleven overdue items and is drowning, and nobody has noticed — not through anyone’s negligence, but because no list existed that would have shown it. This is a reporting artefact, and it is entirely fixable.
Age, not status
Status is what people report. Age is what is true. An item can sit at “in progress” indefinitely, and on most projects it does.
Sort by age, oldest first, and read the top of the list. Anything sixty days old is telling you that its owner cannot resolve it and has not said so — which is almost never laziness and almost always a blockage they do not have the authority to clear.
And escalate on a rule
Because escalating somebody else’s stale item is socially expensive. You are telling a colleague, in writing, in front of the project, that they have not delivered. Most people will simply not do it, and the item will age instead.
A published ageing trigger removes the choice, and therefore removes the awkwardness. Nobody escalated it. The rule did.
References
- module: /modules/tasks/ — ageing by owner across modules, and rule-based escalation
Zepth is the construction project delivery platform — it runs construction, procurement and asset management on one record, and does the work: reading the drawings, reviewing the submittals, matching the invoices and flagging the risks, with a human sign-off on anything consequential.
Related questions
See Zepth on your project.
A short, tailored walkthrough on your real workflow — no generic demo.
Book a meeting