Resource Allocation
A schedule says when work happens. Resource allocation asks the harder question underneath it: is anyone actually free to do that work then? Most late projects had a plausible schedule and an impossible staffing assumption.
In short
- Nobody is 100% available. Plan against real availability — usually 50–70% for people who also carry operational work.
- Overallocation is almost never intentional. It happens when two plans each assume the same person.
- You can only make four moves when someone is over-committed: move the work, move the date, change who, or cut scope.
- Allocation is a planning tool, not a report. Build the grid before you commit to dates.
What counts as a resource
Formally: people, money, equipment, facilities, software, and anything else the work consumes. Practically, on most projects one of these is the binding constraint and the rest are paperwork — and it’s usually people, because people are the only resource you can’t buy more of at short notice.
So this page is mostly about people. The others matter when they’re scarce or slow to obtain: a test environment with a six-week lead time is a resource constraint that will shape your schedule far more than a budget line.
The availability problem
Here is the arithmetic almost every plan gets wrong. A full-time person has five days a week. A plan that assumes they will deliver five days of project work is wrong before it starts, because those five days also contain:
- Standing meetings, one-to-ones and company obligations — typically half a day to a day.
- Operational work: tickets, support, the thing that broke on Tuesday. See 1.3 Projects vs Operations for why this always wins.
- Helping other people — reviews, questions, onboarding. Invisible in every plan, real in every week.
- Leave, illness and public holidays, which are certain in aggregate even though you can’t predict which week.
The practical figures worth planning against:
| Situation | Realistic availability | Why |
|---|---|---|
| Dedicated to one project, no operational duties | 70–80% | Meetings and helping others still exist |
| Project work plus a support rota | 50–60% | Interruptions cost more than their duration |
| Split across two projects | 35–45% each | Context switching takes the difference |
| “Available as needed” | Assume 0% | Not a commitment. Plan for it or get one. |
Note the third row. Two half-time people are not one full-time person — splitting attention costs real throughput, which is why a plan built on many fractional allocations underdelivers even when everyone works hard.
Where the plan quietly breaks
The important detail: nobody did anything wrong to produce this grid. Priya’s 130% is one project asking for 70% and another asking for 60%, each perfectly reasonable in isolation. Overallocation is a coordination failure, not a discipline failure — which is why it can only be seen from a view that spans projects.
The only four moves
When a cell goes over 100%, you have exactly four options. Everything else is a way of pretending you have a fifth.
1. Move the work
Shift tasks with float into quieter weeks. Free, and the first thing to try — but it only works off the critical path. This is what resource levelling means.
2. Change who does it
Give the work to someone with room, accepting it will take longer or need review. Often the right call, and often refused because the specialist is faster — which is true right up until they’re the bottleneck.
3. Move the date
The honest option when the first two don’t work. Painful to say early and much worse to discover late. A date moved in planning costs a conversation; a date moved in month four costs credibility.
4. Cut scope
Deliver less, on time. Usually the sponsor’s decision, not yours — which is exactly why they need to see this grid rather than a summary of it.
The non-option is “they’ll manage”. Sometimes they will, by working evenings, and you will have bought a few weeks at the cost of quality, goodwill and the person’s willingness to flag the next problem early.
Adding people to a late project deserves its own warning. New people consume the time of the people who already know the work, so the project gets slower before it gets faster — and if the remaining time is short, it never gets to the faster part.
The cost side
Once you know who is doing what and for how long, cost mostly falls out of it: hours multiplied by rates, plus non-labour items — licences, hardware, environments, travel, external services.
Two habits keep budgets honest:
- Estimate cost from the same breakdown as effort. A budget derived independently of the task list is a number, not an estimate — the same problem as top-down scheduling in 2.2.
- Hold contingency visibly, at project level. A single owned buffer beats padding hidden in forty individual estimates, because you can see it being spent and decide whether to stop.
Working with external people
Contractors, agencies and vendors solve capacity problems and introduce three new ones: they need onboarding time you must plan for, they have their own competing commitments, and when they leave, whatever they knew leaves with them.
Practical mitigations: pair them with someone internal from the start, write down what “done” means more explicitly than you would internally, and put a knowledge handover in the plan as a dated task rather than an intention. See 7.3 Knowledge Transfer.
How this looks in AB
In AB Projects, three small fields do most of the resource-allocation work:
- Assignee on every task — who is doing it.
- Estimate in hours, defaulting to 1h rather than 0, so unedited tasks aren’t invisibly weightless in any total.
- Project members at the project level — who is in scope to be assigned anything at all.
Together they answer the three questions on this page: who’s doing what, how heavy is it, and is anyone overloaded. The Calendar view rolled up by assignee gives you the shape of the grid above without a separate spreadsheet, and a “tasks assigned to me this week” list keeps each person grounded in their own capacity rather than the project’s optimism.
External vendors are added as members of just the project they’re contributing to, which scopes their access naturally without giving them the run of everything else.
One caveat worth stating plainly: any single tool only sees its own projects. If your people are also committed elsewhere, the honest version of this grid has to be assembled across all of them — usually in a five-minute conversation with the other project’s manager, which is still cheaper than discovering the clash in week four.
Terms used on this page
- Resource allocation
- Deciding who and what is committed to which work, and when. The step that turns a schedule from a wish into a commitment. More →
- Availability
- The share of a person’s working time genuinely free for project work, after meetings, operational duties and leave. Plans built on 100% are always late. More →
- Overallocation
- A person committed to more than their available time in a given period. Usually caused by two plans each assuming the same person, so it’s only visible across projects. More →
- Resource levelling
- Moving tasks within their available float to smooth out peaks in demand. Free when the tasks aren’t on the critical path, impossible when they are. More →
- Float
- How much a task can slip before it delays something else. Float is what makes levelling possible. More →
- Contingency
- Time or money held in reserve for known uncertainty. Useful when it’s visible and owned; wasted when hidden inside individual estimates. More →
- Context switching
- The cost of moving between unrelated tasks. Why two half-time people deliver less than one full-time person. More →
Related reading
3.2 Creating a Project Schedule
Where float comes from, and why levelling only works off the critical path.
4.1 Building a Project Team
Choosing who is on the project in the first place, and what mix of skills it needs.
1.3 Projects vs Operations
Why operational work reliably eats the project hours you assumed you had.