Allocation

Open a resource schedule and look at it. You'll see a grid: names down the left side, dates across the top, and colored blocks scattered through the middle. Each one of those blocks is an allocation — a single assignment that says "this person works on this project from Monday to Wednesday, 6 hours per day."

Allocations are the atoms of scheduling. Everything else — utilization rates, profitability forecasts, workload balancing — is just math performed on top of them.

Anatomy of a Block

A typical allocation carries a handful of properties:

1. Who — the team member. 2. What — the project (and optionally a phase or tag). 3. When — start date and end date. 4. How much — hours per day, usually between 1 and 8.

That's it. No fifty-field form. You drag on the timeline, pick a project, set the hours, done. The simplicity is the point — if creating an allocation takes longer than thirty seconds, people stop doing it and the schedule rots.

Stacking and Splitting

A person can hold multiple allocations on the same day (say, 4 hours on Project Alpha and 4 on Project Beta). When the total exceeds their daily availability, that's overallocation — a red flag your schedule should surface immediately, not bury in a formula.

You can also split a single block into two — handy when a client pauses mid-week and you need to reallocate the gap without losing the original booking. Think of it like snapping a LEGO brick in half and reattaching the pieces where they're actually needed.

Well-maintained allocations feed directly into capacity planning and billable hours tracking, making them the single most important data point in your schedule.