Docs / Teams

Resources and levelling

Assignments, the work formula, over-allocation flags, and when (not) to act on what the leveller proposes.

Assignments and the work formula

People (or rigs, labs, licences — anything contended) are modelled as resources with a maximum availability in units, then assigned to tasks at some percentage. The classic formula applies: Work = Duration × Units. Assign someone at 50% to a 10-day task and you've planned 5 days of their work spread over 10. Assignments are edited from a task's details in the app; the resource pool itself arrives with an imported plan or through the API, since a resource-management screen has not shipped yet.

Over-allocation, flagged immediately

Whenever a recompute lands someone above their available units on any working day, the over-allocation is flagged at the task, the resource, and the project level — the moment it happens, not in a report next week. Resources can carry their own calendars (part-timers, regional holidays), and availability is computed against those.

Levelling — a tool, not an autopilot

The leveller resolves over-allocations by delaying tasks within their slack where possible, taking priorities into account. It proposes — it reports the delay it would apply to each task and never moves anything on its own. Today it is reached through the API's levelling endpoint; an in-app control to run it and review the proposal is on the roadmap. Two honest warnings for when you act on its output:

  • Levelling trades date confidence for staffing feasibility — your finish date may move. Try the change in a scenario first and compare.
  • A plan that only works when the leveller shuffles it daily is a staffing problem wearing a scheduling costume. The over-allocation view is telling you to hire, descope, or resequence.
Workload and earned-value reports live in the Resource view; baselines plus assignments are what make variance tracking meaningful.