Resource Allocation Matrix: Who Is On What, How Loaded They Are, and Who Decides
Resource Allocation Matrix is a grid mapping people or teams against the projects they are assigned to, showing how much of each person's capacity each project consumes.
Before you start
Is this your framework?
This answers one question: who is working on what, and how much of them is left. People down one side, projects across the top, and each cell holds the share of that person's capacity the project consumes.
The finding is almost always a row that adds up to more than a hundred percent. The grid shows you that; it does not tell you which project should give way, and it has no view on whether the person is any good at the work. If your question is one of those, the table below points elsewhere.
| If your real problem is… | You probably want |
|---|---|
| Nobody knows who decides or who signs off | RACI Matrix — responsibility per activity. That is accountability; this is capacity Compare this and RACI |
| We do not know who can actually do the work | Skills Matrix — capability against requirement. A free person who cannot do the task is not available Compare this and Skills Matrix |
| Two managers both claim the same person and neither backs down | That is a governance problem, not a data problem. See the matrix organization section below |
| We have more projects than we can fund, not more than we can staff | RICE or Capital Budgeting — choosing what to do, before allocating anyone to it |
| One team is the bottleneck for everything | Theory of Constraints — a systemic constraint that spreading people around will not fix |
| Work stalls between teams rather than inside them | Value Stream Mapping — flow across handoffs, which loading data does not show |
| People are shared across projects and nobody can see the total load | Resource Allocation Matrix — you are in the right place |
What Is It?
One grid. Rows are people or teams, columns are projects, and each cell holds how much of that person the project is using, usually as a percentage or as days per week.
Two totals fall out and they answer different questions. Read across a row and you get utilization: how loaded one person is across everything. Read down a column and you get project demand: how much capacity a project is consuming in total. Most of the value is in the row totals.
The reason it works is that the information already exists and nobody holds all of it. Each project manager knows their own claim on a person and has no visibility of the other four. The over-allocation is invisible from every individual position and obvious the moment the claims are written side by side.
Quick Reference
Reading the grid
Rows, columns, and the number that matters
The construction is trivial and the interpretation is where people go wrong. Four numbers come out of one grid, and they are not equally useful.
| Read | Gives you | What to do with it |
|---|---|---|
| Across a row | One person's total load across every project | The finding. Anything over 100% is a commitment somebody has already made and cannot keep |
| Down a column | Total capacity one project is consuming | Compare against what the project was resourced for. Silent growth shows here |
| Row count | How many projects one person is split across | Three or more usually costs more than the numbers suggest, because switching is not free |
| Empty columns | Projects with no named person against them | Approved work nobody is doing. Common, and invisible without the grid |
Do not fill the grid to 100%
A row at exactly a hundred percent assumes no illness, no holiday, no support work and no meetings, which describes nobody. Planning to full capacity guarantees the plan is wrong from the first week.
Allocate to about eighty percent and treat the rest as the buffer that absorbs reality. Teams that plan to a hundred do not deliver more; they deliver the same and report a variance every month.
Disambiguation
Allocation, utilization, and the matrix organization
Three things share this vocabulary and get confused, and the third is not a tool at all. It is the structure that creates the problem the grid makes visible.
| Term | What it is | Answers |
|---|---|---|
| Allocation matrix this page | A grid of planned assignment: who is committed to what, and how much | Forward-looking. Are these commitments possible? |
| Utilization matrix | The same grid read as actual usage, often billable against available hours | Backward-looking. How much of the capacity we paid for got used? |
| Matrix organization | A structure where people report to a function and to a project at the same time | Not a tool. The condition that makes allocation contested in the first place |
The grid exposes a governance problem it cannot solve
In a matrix organization the same person is legitimately claimed by a functional manager and by one or more project managers, and none of them is doing anything wrong. Writing the claims side by side shows the conflict clearly and settles nothing.
What settles it is a named person with the authority to decide, agreed before the conflict arises. Without that, the grid becomes evidence in an argument between peers, and the person who is over-allocated absorbs the difference personally.
Core Features
- One grid: people down, projects across, capacity share in each cell
- Row totals are utilization: one person's load across everything
- Column totals are demand: what a project is actually consuming
- Plan to about 80%: the rest is absorbed by reality whether you plan it or not
- Forward-looking: planned commitment, not recorded time
- Silent on capability: a free person who cannot do the work is not a resource
Worked example
An IT services firm in Cebu, and the architect at 190%
An illustrative composite. A Philippine software services company of about 240 people ran six client programs at once, each with its own manager, staffed from shared functional teams.
| What appeared | What it meant |
|---|---|
| One row at 190% | The lead integration architect was committed to four programs. Each manager had allocated between 40% and 60% and each believed that was the whole commitment. Nobody had lied to anybody. |
| What had been happening | He was absorbing the gap in evenings and weekends and the programs were each running about three weeks late, which every manager had attributed to their own client. |
| Two empty columns | Two approved internal projects had no named person against them at all. Both had steering meetings and status reports. |
| What was done | The architect was capped at 80% across two programs. The other two used him for design review only, about four hours a week each, which is what they had actually needed. |
| What did not change | Nothing in the grid decided which two programs got him. That took the delivery director, and the first attempt to settle it between the four managers failed in one meeting. |
The number was not new information to him
The architect knew he was over-committed. He had no way of showing it, because each individual claim was reasonable and he could not see the others either. The grid did not discover the problem so much as make it arguable.
That is the honest description of what this tool does. It converts something a few people already suspected into something a room can look at. The decision that follows is a management act, and pretending the grid made it is how these exercises produce a document and no change.
When to Use
- People are shared across several projects and no one sees the total
- Projects are slipping and each manager blames a different external cause
- Before committing to new work, to find out whether it can actually be staffed
- In a matrix organization, where competing claims on the same person are structural
- Quarterly planning, to check the portfolio against the people who exist
- When a specialist is suspected of being the constraint on everything
When NOT to Use
- Where everyone works on one thing, which needs no grid
- As a timesheet, since planned allocation and recorded time are different data
- To decide who should do the work, which needs capability rather than availability
- To settle a conflict between managers, which needs an authority not a spreadsheet
- At a granularity nobody will maintain, because a stale grid is worse than none
- As a performance measure, which turns utilization into a target and corrupts it
In practice
How the matrix goes wrong
The grid is easy to build and easy to render useless. Most failures are about maintenance, granularity, or asking it to make a decision.
| Failure mode | What it looks like | What to do instead |
|---|---|---|
| Planned to 100% | Every row totals exactly a hundred and every project is late | Plan to around 80%. Leave and support work happen whether or not the grid allows for them. |
| Utilization as a target | People measured on being busy, so nobody reports slack and the numbers become fiction | Use it for planning, not appraisal. A measure that decides pay stops describing reality. |
| Too granular to maintain | Hour-level allocation across 200 people, accurate for one week | Half-day or 10% steps, updated fortnightly. Precision you cannot sustain is not precision. |
| Names, not skills | Work assigned to whoever shows capacity, regardless of whether they can do it | Pair it with a capability view. Availability alone is not the same as being able. |
| Expected to decide | The conflict is visible for months and nobody resolves it | Name who arbitrates before you build the grid, not after it shows a conflict. |
| Partial coverage | Only project work counted, so support and operational duties are invisible | Include everything that consumes the person, or the totals understate the load. |
Sourced
Evidence, and how to cite it
The grid has no author; the problem it addresses does.
Nobody invented the resource allocation matrix. It is ordinary project management practice descending from resource leveling in critical path scheduling, which emerged with CPM and PERT in the late 1950s. What is attributable is the structure that makes allocation contested: Jay Galbraith named and described the matrix organization, in which staff answer to a function and to a project simultaneously.
Galbraith, J.R. (1971) ‘Matrix organization designs: How to combine functional and project forms’, Business Horizons, 14(1), pp. 29–40.
The pathologies were documented early.
Davis and Lawrence catalogued what goes wrong in matrix structures, including power struggles between functional and project managers and decisions that stall because no single person can make them. Their observation that a matrix is a state of mind rather than a structure is the relevant one here: the grid exposes the conflict, and only an agreed arbiter resolves it.
Davis, S.M. and Lawrence, P.R. (1977) Matrix. Reading, MA: Addison-Wesley.
Splitting people across projects costs more than the arithmetic shows.
The grid treats a person as divisible: fifty percent here and fifty there sums to one person. It does not, because switching between contexts carries a cost that no cell in the matrix records. Three or more concurrent projects is the point at which practitioners generally report the losses becoming obvious, and the grid will happily show five as a valid hundred percent.
A known limitation of capacity-based planning; the matrix records share of time and not the cost of dividing it.
Utilization becomes fiction once it is a target.
Where people are judged on how loaded they appear, the reported figures stop describing the work and start describing what is safe to report. Slack is hidden, estimates inflate, and the grid loses the one property that made it useful. This is the general problem with any measure used for appraisal, and utilization is particularly exposed to it.
The general form is Strathern's observation that a measure becoming a target ceases to be a good measure; see also KPIs.
How to cite it.
There is no framework author to cite for the matrix itself. Treat it as standard project management practice and reference a project management text.
For the matrix organization: Galbraith, J.R. (1971) ‘Matrix organization designs’, Business Horizons, 14(1), pp. 29–40, or Davis, S.M. and Lawrence, P.R. (1977) Matrix. Reading, MA: Addison-Wesley.
Key Strengths
- Makes a hidden total visible: no individual manager can see the whole row
- Costs an afternoon: a spreadsheet and a round of conversations
- Finds unstaffed projects: approved work with nobody against it, complete with status reports
- Turns suspicion into evidence: the over-committed person usually knew and could not show it
- Two views from one grid: person load and project demand at the same time
Key Weaknesses
- Treats people as divisible: the cost of switching appears in no cell
- Ignores capability: availability and ability are not the same thing
- Goes stale fast: a grid nobody updates misleads more than no grid
- Decides nothing: it shows the conflict and cannot resolve it
- Corrupts under appraisal: utilization as a target stops being a measurement
- Misses invisible work: support and operational duties are usually left out
Sequencing
What to run before and after
The grid needs a decided portfolio to allocate against, and it hands back a conflict somebody has to settle.
Before
Decide which work is actually happening
Allocating people across a portfolio nobody has pruned guarantees over-allocation. If there is more approved work than there are people, the grid will report that faithfully and repeatedly.
During
Check that available means capable
A free person who cannot do the work is not a resource. Capacity and capability are separate views and the grid only holds the first.
After
Name who arbitrates, before the conflict
In a matrix organization the competing claims are all legitimate, so the grid produces an argument between peers. Agreeing the decision right in advance is what turns it into a decision.
Common questions
Resource Allocation Matrix: quick answers
What is a resource allocation matrix?
A grid with people or teams as rows and projects as columns, where each cell holds the share of that person's capacity the project is using. Row totals show how loaded each person is across everything; column totals show how much capacity each project is consuming. The usual finding is a row above 100%.
What is the difference between a resource allocation matrix and a resource utilization matrix?
Direction in time, mostly. Allocation is forward-looking and records planned commitment: who is promised to what. Utilization is backward-looking and records actual usage, often as hours worked against hours available or as billable percentage. They use the same grid shape and answer different questions, and confusing them means planning from data that describes the past.
How do you build a resource allocation matrix?
List the people or teams down the side and the active projects across the top. Ask each project manager what share of each person they are counting on, in percentages or days per week. Put the answers in the grid and total the rows. Include support and operational duties, not just project work, or the totals will understate the real load.
What is a good resource utilization percentage?
Plan to around 80% rather than 100%. A row at a hundred assumes no leave, no illness, no meetings and no support work, which describes nobody, so the plan is wrong from the first week. Teams planned to full capacity do not deliver more than teams planned to eighty; they deliver the same and report a variance every month.
How does this work in a matrix organization?
It is where the tool is most useful and least sufficient. In a matrix structure people answer to a function and to one or more projects at once, so competing claims on the same person are structural rather than anyone's mistake. The grid makes the conflict visible. Resolving it needs a named person with the authority to decide, agreed before the conflict arises rather than during it.
Is a resource allocation matrix the same as a RACI matrix?
No. RACI records who is responsible, accountable, consulted and informed for each activity, which is about accountability. This grid records how much of each person's time is committed, which is about capacity. Someone can be accountable for something that takes two hours a month, and the two matrices will disagree completely about how important they are to it.
How many projects should one person work on at once?
Fewer than the arithmetic allows. The grid treats a person as divisible, so five projects at twenty percent each looks like a valid hundred. Context switching carries a cost that appears in no cell, and three or more concurrent projects is generally where the losses become obvious. Treat the project count in a row as a warning independent of the total.
How often should the matrix be updated?
Fortnightly is usually the right cadence, at a granularity somebody will actually maintain: 10% steps or half-days rather than hours. A stale grid is worse than no grid, because decisions get made on it as though it were current. If it cannot be maintained at the chosen detail, choose less detail.
Deep Resources
Frameworks related to the Resource Allocation Matrix
- RACI MatrixAccountability per activity, which is a different question from capacity…
- Skills Matrix / Competency MappingWhether the available person can actually do the work…
- Delegation MatrixWho holds the authority to settle a competing claim…