States the trade as a decision
Turns an over-allocation into the sentence a project director can act on: what it costs in days to respect the limit, or what additional resource would avoid it.
Zepth Rx · Schedule Intelligence
Resource Management
A programme that needs 340 men in a week you have 180 is not a programme. It is a slip nobody can claim against.
Last updated
Zepth Rx module
Resource Management
AI agent built into the module
The resource poolDemand against availabilityLevelling that cascades properlyIt does not quietly give up
Overview
Almost every accepted programme contains resource peaks nobody has checked. The logic is sound, the durations are defensible, and the July demand for formwork carpenters is three times the number the subcontractor has ever put on site.
That programme will slip — not because of an event anyone can claim against, but because the plan was never physically deliverable. It slips quietly, across many activities, and it produces exactly the kind of delay that is hardest to attribute afterwards. Which is why it is worth finding before it happens.
Unclaimable delay
When a plan was never physically deliverable, the slip that follows is difficult to attribute to anyone. There is no event, no instruction, no variation — just a month in which the work needed more people than the site could hold, spread across enough activities that no single one looks like the cause.
That is the worst kind of delay to own, because it is real, it is expensive, and it is nobody’s fault in a way any contract recognises. Finding it in the programme before acceptance converts it into a review comment.
The gap the site sees first
A schedule assumes a crew size. The site records what turned up. The gap between them is the earliest visible signal that a duration is not going to be achieved — usually weeks before the activity’s percentage complete admits it.
Most platforms leave that loop open, because the plan lives in one system and the site record in another. Comparing them is the cheapest early warning available on a project.
How it looks
The instruments this module produces, drawn on illustrative data so the method reads clearly.
- Within availability
- Over-allocated
An over-allocated programme is undeliverable and its slip is hard to attribute. Demand is distributed across each activity’s working days on its own calendar.
- Before levelling
- After levelling
Deferrals are fed back through the full critical path, so they cascade. A levelling pass that shifts bars without re-running the network produces a schedule that cannot happen.
The earliest reliable warning that a duration will not hold — visible well before percent complete moves.
The value
Why it matters
Over-allocation found at acceptance, while it is still a review comment rather than a dispute.
The honest trade stated as a number: this is what your resource limits cost in time.
Deployment against plan — the earliest reliable warning that a duration will not hold.
Achieved productivity that later becomes evidence, on both the disruption and the credibility side.
Capabilities
What you can do
01
The resource pool
Resources defined by what actually constrains them: maximum units per day, their own working calendar, cost per hour or per unit, and whether they are currently active. A crew working six days against a five-day project calendar has a different real capacity from the one a naive calculation assumes.
02
Demand against availability
The demand curve each activity’s assignments imply, distributed across its working days on the right calendar. Against the pool’s availability that gives over-allocation with its size and timing, demand histograms per resource and per trade, utilisation where capacity is idle as well as exceeded, and the trades most exposed to a bottleneck.
03
Levelling that cascades properly
Levelling expresses each deferral as an earliest-start override fed back through the full critical path calculation, so a deferred activity moves everything depending on it, exactly as it would on site. A levelling pass that shifts bars without re-running the network produces a schedule that cannot happen.
04
It does not quietly give up
A run that cannot fully resolve declares exactly what it covered. The engine previously stopped after a fixed number of passes and recorded the run as completed — reporting a partially levelled schedule as a levelled one. That cap is gone.
05
Deployment, plan against site
Where daily reports are captured, planned deployment is compared to actual: manpower by trade and zone, utilisation against plan, achieved productivity, and status by trade.
The workflow
How it actually runs
- 1
Define the pool
Maximum units per day, each resource’s own working calendar, cost rates, and active state. Import from a P6 file or from Excel.
- 2
Build the demand curve
Each activity’s assignments distributed across its working days on the right calendar, shaped by its resource distribution where one is set.
- 3
Find the over-allocation
Where and when demand exceeds capacity, by how much, and which trades and periods are most exposed.
- 4
Level within float
Deferrals fed back through the full critical path, with the delay required to respect the limits reported — and any unresolved conflict declared.
- 5
Compare to site
Where daily reports exist, planned deployment against actual manpower, utilisation and achieved productivity.
AI that does the work
How AI changes Resource Management management.
Flags the widening shortfall
Where deployment on site is falling behind the plan’s assumption, surfaced while there is still time to change the outcome.
Coverage, declared
Resource analysis and levelling both record what they covered. A run that could not fully resolve says so explicitly rather than reporting a partial result as complete.
The engineer’s judgment stays in charge; the AI removes the latency and the blind spots.
Best practices
- Check resource demand at acceptance, not at the first slip. An over-allocated programme is unclaimable delay, and it is cheapest to remove while it is still a review comment.
- Give every resource its own calendar. A six-day crew on a five-day project calendar has a capacity a naive calculation gets wrong, and the error compounds over a long trade.
- Set maximum units per day, or there is nothing for demand to be over-allocated against.
- Read levelling as a costed choice — more resource, or a later date — rather than as a schedule to adopt.
Dashboards & reporting
Planned against actual by trade and zone, utilisation, manpower, productivity and status, with a print-ready report. Over-allocated resources detected, conflicts resolved within float, and the schedule impact of respecting the limits. Resource definitions with Excel and CSV import.
Live dashboards
Drill-down & filters
Export to Excel / PDF
FAQ
Common questions
What do we need before over-allocation can be detected?
Resource assignments on the programme, and a resource pool with maximum units per day. Without an availability figure there is nothing for demand to be over-allocated against.
Does levelling change my completion date?
It reports what respecting your resource limits would cost in time. Deferrals are fed back through the full critical path so they cascade properly — a pass that shifted bars without re-running the network would produce a schedule that cannot happen.
What if there is no float to level within?
The module says so rather than pretending otherwise. A programme with no slack cannot be levelled without moving the completion date.
Why does each resource need its own calendar?
Because a crew working six days against a five-day project calendar has a different real capacity from the one a naive calculation assumes, and the difference compounds over a long trade.
How does this connect to the delay analysis?
Where quantities are tracked, achieved productivity becomes evidence: it feeds the measured-mile disruption analysis, and it grades duration cuts in a recovery programme.
Related modules
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.
See it on your project.
A short, tailored walkthrough on your real workflow — no generic demo.