A resource breakdown structure, or RBS, is a hierarchical breakdown of every resource a project needs, organized by category and then by type. It is the resource equivalent of an org chart: at the top sit broad categories like people, equipment, materials, and facilities, and each branches down into the specific resources underneath. Where the work breakdown structure lists the work, the RBS lists what it takes to do the work. Build the two together and every task has both a deliverable to produce and a defined set of resources to produce it with.
Key takeaways
- A resource breakdown structure is a hierarchical categorization of all the resources a project consumes: people, equipment, materials, facilities, and finances.
- The RBS answers "what do we need," while the work breakdown structure answers "what do we deliver." They are complementary hierarchies.
- You usually build the RBS right after the WBS, because the deliverables in the WBS tell you which resources the RBS has to account for.
- A good RBS makes estimating, assignment, and cost roll-up faster, because every resource has a code and a place in the hierarchy.
- The RBS is a categorization, not a schedule. When and how much of each resource you need comes later, from loading and capacity planning.
Last updated July 2026.
What is a resource breakdown structure in project management?
A resource breakdown structure is a hierarchical chart that lists and categorizes every resource required to complete a project. It starts with high-level categories such as human resources, equipment, materials, and facilities, then breaks each category down into progressively more specific types until you reach the individual resources you can estimate and assign. The result is a tree that captures the full resource picture of a project in one place.
The point of organizing resources this way is control. When resources sit in a defined hierarchy, you can estimate them consistently, roll their costs up by category, and see at a glance whether you have accounted for everything a project needs. It also gives every resource a code, which makes assigning resources to tasks and reporting on their use far cleaner than working from a flat list. In that sense the RBS is the reference structure that the more active work of resource allocation in project management draws on.
Resource breakdown structure vs work breakdown structure
The RBS and the work breakdown structure (WBS) are both hierarchical trees, and they are often confused, but they answer opposite questions. The WBS decomposes the project scope into deliverables and the tasks that produce them: it is about the work. The RBS decomposes the resources the project consumes: it is about what does the work. One is the output side, the other the input side, and a complete plan needs both.
| Dimension | Work breakdown structure (WBS) | Resource breakdown structure (RBS) |
|---|---|---|
| Core question | What do we deliver? | What do we need to deliver it? |
| Focus | Deliverables and tasks | People, equipment, materials, facilities |
| Top level | Major project deliverables | Major resource categories |
| Lowest level | Work packages | Individual resources or resource types |
| Built when | First, from the scope | After the WBS, from the tasks it defines |
| Used for | Scheduling, scope control, assigning work | Estimating, assigning resources, cost roll-up |
Swipe to see more →
The order matters. You build the WBS first, because you cannot know which resources you need until you know which deliverables and tasks exist. Then the RBS is built to supply those tasks. In a mature plan the two link: each work package in the WBS points to the resources in the RBS that it consumes, and that link is what lets you estimate and cost the project accurately.
What resource types go in a resource breakdown structure?
A resource breakdown structure covers every kind of resource a project consumes, not just people, which is the mistake teams make when they treat it as a staffing list. The standard categories are human resources, equipment, materials, facilities, and finances, though you tailor them to the project. A software project's RBS is mostly people and licenses; a construction project's is heavy on equipment, materials, and facilities.
- People. Roles and named individuals: engineers, analysts, designers, a project manager, external contractors.
- Equipment. Machinery, servers, vehicles, test rigs, tools that the work requires.
- Materials. Consumables and physical inputs: raw materials, components, supplies.
- Facilities. Physical space: offices, labs, sites, meeting rooms, storage.
- Finances. Budget lines and funding that back the other categories, where you choose to model money as a resource.
Within each category you break down as far as you need to estimate and assign. Under people you might go from "engineering" to "backend engineering" to two named engineers. The right depth is the level at which you can attach an estimate and an owner, and no deeper.
How to build a resource breakdown structure
Building an RBS is a short exercise once the WBS exists, and it pays for itself the first time you have to cost or re-plan the project.
- Start from the WBS. Work through the tasks and work packages and list every resource each one needs. The WBS is your checklist so nothing gets missed.
- Group into categories. Sort the resources you listed into top-level categories: people, equipment, materials, facilities, finances. Drop categories that do not apply.
- Break each category into types. Under each category, add the specific roles, equipment classes, or material types the project uses.
- Reach the estimable level. Keep decomposing each branch until you hit a level you can put an estimate and an owner against, then stop.
- Code the structure. Give each node a code (1, 1.1, 1.1.1) so resources can be referenced consistently in estimates, assignments, and reports.
- Link to the WBS and validate. Map each work package to the resources it uses, then check every task has resources and every resource has a task. Gaps in either direction are planning errors to fix now.
Once the structure exists, it feeds the numbers side of resource planning: how much of each resource you need and when. That demand-over-time question is answered by loading and by the capacity planning template, and the forward view of whether supply will meet it is covered in resource forecasting.
Resource breakdown structure example
Here is a compact RBS for a small software project, coded and categorized. It stops at the level where each line can carry an estimate.
| Code | Category | Resource |
|---|---|---|
| 1 | People | Human resources |
| 1.1 | People | Backend engineer (2) |
| 1.2 | People | Frontend engineer (1) |
| 1.3 | People | Product designer (1) |
| 1.4 | People | Project manager (1) |
| 2 | Equipment | Hardware and infrastructure |
| 2.1 | Equipment | Cloud environment (staging, production) |
| 2.2 | Equipment | Developer laptops |
| 3 | Materials | Software and licenses |
| 3.1 | Materials | SaaS tool subscriptions |
| 4 | Finances | Contingency budget |
Swipe to see more →
Even at this size, the value is visible: costs roll up cleanly by category, every role has a place, and when scope changes you know exactly which lines to revisit. On a portfolio of many projects, the same categories let you compare and combine resource demand across projects, which is the job of resource capacity planning for project portfolios. The commitments the RBS defines are then recorded and maintained in the resource management plan.
How do you code a resource breakdown structure so it joins to the plan?
Give every node a code, as in the example above, and the structure becomes usable beyond one project. Without codes it is an indented list a human has to read. With codes, every assignment, timesheet line and cost record carries a resource code alongside the work code, so you can report effort and cost by role, by skill or by team across all projects without rebuilding anything by hand.
| Level | What it holds | Example code | What the code lets you answer |
|---|---|---|---|
| 1 | Resource category | 1 People, 2 Equipment, 3 Materials, 4 Finances | How much of this project is people versus everything else |
| 2 | Function or discipline | 1.2 Engineering | Which functions are carrying the portfolio |
| 3 | Role | 1.2.3 Data engineer | Which roles are the actual constraint |
| 4 | Skill or certification | 1.2.3.1 Data engineer, cloud certified | Whether the constraint is the role or one scarce skill inside it |
| 5 | Named person or specific asset | 1.2.3.1.07 | Who is actually committed, for work already in flight |
Swipe to see more →
Keep the codes stable even when the org chart moves. Codes renumbered during a reorganization break every historical comparison you own, which is the one thing the structure was supposed to give you. The codes also give you the join to the work side of the plan: the work breakdown structure says what has to be done, the resource codes say who does it, and the assignment grid sits between them.
How detailed should the structure be at each planning horizon?
Vary the depth by how far out the work sits. Long range pipeline work should be planned at category or role level, approved near term work at role level, and only work already in flight should carry named individuals. Planning everything at level five feels rigorous and produces a plan that is wrong inside a week.
| Horizon | Level of detail | Why | What breaks if you go finer |
|---|---|---|---|
| Pipeline, beyond two quarters | Category and function | Scope is still moving and some roles may not exist yet | Named assignments create commitments to work that may never be approved |
| Approved, next one to two quarters | Role | Enough detail to test whether the portfolio is deliverable at all | Naming people this early triggers conflicts that resolve themselves once scope firms up |
| In flight, current quarter | Named person or specific asset | Somebody has to be accountable this week | Nothing, provided the bookings are actively maintained |
| Scarce skills, any horizon | Skill level, regardless of distance | One certification can gate the whole portfolio | Under detailing here hides the constraint that will actually bite |
Swipe to see more →
That last row matters more than the rule above it. If a single certification, security clearance or specialist tool operator gates several projects at once, model it at skill level even in the distant pipeline, because that is the shortage that surfaces too late to fix. How those bookings get held and released afterward belongs to the resource management plan.
How do you roll the structure up across the portfolio?
Roll-up works only when every project codes to the same resource taxonomy. That is the entire trick, and it is where most attempts fail. Each project invents its own role names, so "Data engineer", "Data Eng" and "ETL developer" become three separate roles, and the portfolio view quietly understates real demand on one team. The taxonomy has to be a PMO owned reference list, not a per project choice.
| Roll-up view | What it answers | What it needs from every project | Common blocker |
|---|---|---|---|
| Demand by role | Which roles the portfolio is short of, and when | Shared role codes, with effort phased by month | Projects reporting one lump sum with no phasing |
| Cost by category | How much of the portfolio is people, vendors or assets | Consistent level one categories | Contractor effort recorded only as cost, so it never appears as capacity |
| Skill exposure | Which scarce skills gate more than one project | Level four coded, for scarce skills only | Skills held in a separate system nobody joins to the plan |
| Team load | Which teams are over committed across projects | Role codes mapped to real teams | Matrix teams appearing under two different parents |
| Vendor concentration | How dependent the portfolio is on a single supplier | Vendors identified at level two or three | Vendor effort hidden inside a project's internal role codes |
Swipe to see more →
Publish the reference taxonomy and make new codes come through the PMO. It sounds bureaucratic, it costs about an hour a quarter, and it is the difference between a portfolio resource view and a spreadsheet somebody reconciles by hand every month. Any resource forecast built on top is only ever as good as the taxonomy underneath it.
Where do resource breakdown structures break?
Most failures are not structural mistakes. They are maintenance failures: the structure gets built once for an approval, signed off, and then never updated as the work and the organization move around it. A structure that is six months stale is worse than no structure at all, because people still trust it.
| Failure | What it looks like | Root cause | Fix |
|---|---|---|---|
| Org chart in disguise | The structure mirrors reporting lines exactly | It was copied from HR rather than built from the work | Build it from what the work needs, then map that to teams |
| Stale after a reorganization | Codes point at functions that no longer exist | No owner and no review trigger | Assign an owner and review it at every portfolio cycle |
| Too deep, too early | Named people sitting against unapproved projects | Detail mistaken for rigor | Set depth by horizon, as above |
| Free text roles | The same role spelled three different ways | No controlled taxonomy | Move to a reference list with codes |
| Built and abandoned | Created for the approval, never opened again | Nothing downstream consumes it | Wire it to the assignment grid and to reporting, or stop producing it |
| Non labor missing | Only people are modeled | Equipment, licenses and facilities feel like a finance problem | Include them at level one, because they cause real schedule delays |
Swipe to see more →
The test for whether yours is alive is short. Ask when a code last changed, then ask what report broke when it did. If nothing downstream would have noticed the change, what you have is documentation rather than a planning tool.
Frequently asked questions
What is the difference between an RBS and a WBS?
A work breakdown structure decomposes the project scope into deliverables and tasks, answering what the project will produce. A resource breakdown structure decomposes the resources the project consumes into categories and types, answering what it needs to produce that work. Both are hierarchical trees, but the WBS is the output side and the RBS is the input side. You build the WBS first, then the RBS to supply it.
What are the resource types in a resource breakdown structure?
A resource breakdown structure typically contains five categories: human resources (people and roles), equipment (machinery, hardware, tools), materials (consumables and physical inputs), facilities (space and sites), and finances (budget and funding). You tailor the categories to the project, so a software project leans on people and licenses while a construction project leans on equipment, materials, and facilities.
When do you create a resource breakdown structure?
You create the RBS during planning, right after the work breakdown structure. The WBS defines the deliverables and tasks, and those tasks tell you which resources the RBS has to account for. Building it in that order means the RBS is complete, because the WBS acts as a checklist that catches any resource you would otherwise miss.
Is a resource breakdown structure the same as an org chart?
No, though they look similar. An org chart shows reporting relationships between people in a company. A resource breakdown structure categorizes all the resources a specific project needs, including equipment, materials, and facilities, not just people, and it is organized by resource type rather than by who reports to whom. The RBS is project-specific and broader than staffing.
How detailed should a resource breakdown structure be?
Break each branch down until you reach a level you can attach an estimate and an owner to, then stop. Too shallow and you cannot cost or assign the resources; too deep and you create maintenance work with no payoff. For most projects that means categories at the top, resource types in the middle, and named resources or role counts at the bottom.
The RBS is the reference structure; the active work is putting those resources against tasks and keeping them from being overbooked. For the assignment mechanics, see resource allocation in project management, and for the chart that shows when a resource is over-allocated, see the resource histogram guide.