Resources & levelling

Resourcing is opt-in per project. A schedule that has not switched it on has not failed anything — the quality check's resource point reports not-applicable rather than failing every row.

The pool#

Resources live in a pool with a capacity profile — what is available, and when. Capacity may be stated as a percentage or as a count, and a resource that states nothing is treated as one full-time unit, which is the common case and the only defensible default.

Rates are carried alongside capacity and may be dated, so a rate rise part-way through a job is a fact about the resource rather than a manual correction on every row.

Assignments#

An assignment states units, in one of three ways, and this is where most resourcing arithmetic goes wrong:

These do not add up, so everything is normalised to percent of one full-time unit before anything is summed:

⚠⚠ Hours with no hours-per-day on the resource is reported as indeterminate, never assumed to be eight. A levelling proposal built on an invented working day would move real dates on made-up arithmetic. The day is flagged and levelling refuses to act on it.

Daily allocation#

For each resource and each working day, Sequence computes what is demanded by every row active that day and what is available from the capacity profile. Days where demand exceeds availability are over-allocations, and each one carries the rows contributing to it — so a conflict is clickable rather than a red cell you then have to explain.

Levelling#

Levelling never rewrites the schedule. It produces a proposal.

A proposal is a list of suggested moves — row, current dates, proposed dates, days delayed — each individually acceptable or rejectable. The whole accepted set lands as a single undo step.

Which row gives#

Given two rows fighting over one person on one day, one of them has to give. The one that gives is chosen by, in order:

1. An explicit priority column, if the project names one.
2. Most total float first — the row with slack is the one that can move without costing the project.
3. Row id, so the result is reproducible.

That last tiebreak matters more than it sounds. A levelling run that suggested different moves each time it was asked would be impossible to review.

What you can bound it with#

⚠ A row with no value in the priority column is treated as lowest priority and moves first, not highest. A blank priority on a levelled schedule almost always means nobody has triaged the row, and protecting untriaged work over work somebody explicitly ranked is the wrong default.

⚠ The pass count is bounded rather than run to convergence. Levelling can chase its own tail — moving A into B's day, then B into A's — and a proposal that never returns is worse than one that says what it could not fix.

What levelling deliberately does not do#

It does not split, stretch or re-rate anything. The moves are moves: a row shifts later until its resource is free. Splitting a task across a gap is a different operation with a different undo story.

It does not add people to shorten a task. That is effort-driven scheduling, which is a different feature and is not levelling.

⚠ Levelling is desktop-only, and it proposes rather than applies — you review the moves before they land.

What resourcing feeds#

• Cost — assignment units × rate × duration is one of the three cost sources.
• Look-ahead — the crew, so a foreman's list says whose work it is.
• Impact and recovery — the named resources on each compression candidate.
• Quality checks — point 10, rows with no resource assigned.

Related#

• Activities, logic and the critical path
• Cost & earned value