Cost Breakdown Structure (CBS): How to Build One + Example

A cost breakdown structure (CBS) is a hierarchical list of every cost in a project, organized so each cost traces back to a piece of work in the work breakdown structure (WBS). The WBS says what work gets done. The CBS says what each piece of that work costs. For an IT services provider, each line of a CBS should carry two numbers: what the work costs you and what you charge the client for it.

TL;DR

• Build the WBS first, then the resource breakdown structure (RBS), then the CBS. Each one feeds the next.
• A services CBS needs cost and price on every line. Cost alone hides your margin.
• Price project management, third-party work and contingency as their own lines. Those are the costs that go missing.
• The worked example below is a 200-user Microsoft 365 migration: 161 labor hours, $28,560 price, 54% gross margin before contingency and 50% after.
• A spreadsheet works. A services CPQ builds the CBS as a side effect of scoping.

What is a cost breakdown structure?

A cost breakdown structure breaks a project's total cost into smaller, named pieces. It starts at the project total and steps down through phases, deliverables and tasks until every dollar sits on a line you can explain.

The CBS borrows its skeleton from the WBS, so when a client asks why the quote is $28,560, you can walk them from the total down to the hours on each task and the rate behind those hours. When a project runs over, you can see which line moved.

Many CBS guides are written for construction and manufacturing, and describe a CBS in terms of materials, equipment and site overhead. For an MSP or VAR the shape is different. Usually most of the cost is people's time, some of it is licenses and hardware, and some of it is work you hand to a subcontractor. The rest of this guide is written for that shape.

CBS vs WBS vs RBS: How the three structures connect

The three breakdown structures answer three different questions. Project management references treat them as related structures, not a fixed sequence. For services work the practical order is WBS, then RBS, then CBS, because you can't cost a task until you know who does it and for how long.

Take one task through the chain. The WBS lists "3.1 Mailbox migration." The RBS says that takes an engineer 40 hours. The CBS multiplies 40 hours by the engineer's cost rate and by their bill rate, and records both. Same task code at every level, so you can follow a dollar from the invoice back to the work.

Two rules keep the chain honest:

• Every WBS task needs a CBS line. A task with no cost line is work you'll do for free.
• Every CBS line needs a WBS task. A cost with no task behind it is padding.

Cost breakdown structure vs cost breakdown analysis

People search for these as if they're the same thing. A cost breakdown structure is the plan, the organized list of costs for a project before it starts. A cost breakdown analysis looks at costs to make a decision, such as comparing what a project should have cost against what it did cost, or finding which cost category drives most of your spend. You need the structure first. The analysis runs on top of it.

What a CBS should include for an IT services project

The categories below cover a typical MSP or VAR project. Add or drop lines to fit the work.

• Labor: Engineering, field technician and help desk hours, priced by role. This is usually the largest category.
• Project management: Coordination, status meetings and change control. Give it its own line or a fixed percentage of labor so it doesn't vanish.
• Software and licenses: Migration tools, security agents, SaaS seats and any license you resell.
• Hardware: Firewalls, switches, servers and end-user devices, at your cost and your sell price.
• Third-party services: Subcontracted work such as cabling, penetration testing or a specialist you don't employ.
• Travel and expenses: On-site days, mileage and per diems.
• Contingency: A reserve for risk. 5 to 10% is common. Work in an environment you haven't assessed can justify 20%.

How to build a cost breakdown structure in 7 steps

1. Start from an agreed WBS

You can't price what you haven't described. Break the scope into phases, deliverables and tasks, and get the client to agree on it before you put a dollar on anything. Our guide to building a work breakdown structure covers this step.

2. Assign a resource and effort to every task

This is your RBS. Name the role on each task (project manager, senior engineer, technician) and estimate the hours. If quantity changes the effort, say so. Migrating 200 mailboxes doesn't take 200 times as long as migrating one.

3. Set up cost codes that match the WBS

Give each CBS line the same number as its WBS task. If your finance team reports by line of business or general ledger code, carry that code too. Then the same item reads the same way in the quote, the PSA and the books.

4. Price direct costs at cost and at sell

Multiply hours by each role's loaded cost rate, then by its bill rate. Do the same for licenses and hardware with your cost and your sell price. Keep both columns. A CBS that only shows sell price can't tell you whether the project makes money.

5. Add project management and other indirect costs

Project management time is real time. Many services teams add it as a percentage of labor hours, often starting around 20%. Others scope the PM's hours task by task. Either works, as long as the hours show up somewhere.

6. Add contingency based on risk

Don't apply one percentage to everything. A migration from a tenant you've never seen deserves more reserve than a firewall swap you've done fifty times. Decide whether contingency is priced into the quote or held against margin, and write that down.

7. Review, document assumptions and lock the baseline

Have someone else check the hours. Write down what the estimate assumes: user counts, data volumes, who provides access, what's out of scope. Once the client signs, the CBS becomes your cost baseline. Any change after that goes through a change request, priced from the same rates.

After the quote: Track actuals against the same codes

The baseline only helps if delivery logs time against it. Create the project in your PSA with the same phases and task codes, and have engineers enter time against those tasks. Then you can compare estimated and actual hours line by line and feed the difference back into the next estimate. The CBS works the same way for fixed-fee and time-and-materials work. On a fixed fee, the CBS tells you what margin you're risking. On T&M, it's the estimate the client will hold you to anyway.

Cost breakdown structure example: A 200-user Microsoft 365 migration

This worked CBS covers a common MSP project: moving a 200-user client into Microsoft 365 and enrolling their devices in Intune. The rates are illustrative. Swap in your own.

Assumptions: Source is an existing Microsoft 365 or Google Workspace tenant with average mailbox and file volumes, devices are already Autopilot-ready, and the client provides admin access before kickoff. If the assessment in line 1.2 says otherwise, the hours change.

Rates used: Project manager $70 cost, $150 bill. Senior engineer $90 cost, $195 bill. Engineer $65 cost, $165 bill. Technician $40 cost, $110 bill. All per hour.

Contingency here is a reserve held against margin, not a line the client sees. The migration lines carry more of it because that's where the unknowns are. What the CBS shows:

• Gross margin is 54% as quoted ($15,490 on $28,560), and 50% if you spend the whole contingency. Labor alone runs at 58%.
• Migration is the biggest bet. Lines 3.1 and 3.2 are 64 of the 161 hours. If the mailbox assessment in 1.2 finds more data than expected, those lines need more hours.
• Project management is $4,050 of the price. Drop that line and the quote looks cheaper, but the PM still works 27 hours. You just stop getting paid for them.
• Licenses carry thin margin. $600 on $3,000. That's normal for pass-through items. Labor carries the margin.

A simple cost breakdown structure format

If you're building a CBS template in a spreadsheet, these columns cover what a services team needs:

• Code: Matches the WBS number, such as 3.1.
• Item: The task or deliverable, in words the client understands.
• Phase: Plan, build, migrate, close, or your own.
• Resource: The role or the vendor.
• Hours or quantity.
• Unit cost and unit price.
• Line cost and line price: Quantity times each rate.
• Margin: Line price minus line cost.
• Assumptions: What has to be true for the estimate to hold.

Keep the template per project type. A network refresh, a Microsoft 365 migration and a managed security onboarding each have their own standard lines.

Common CBS mistakes on IT services projects

• Pricing from cost only. If the CBS has no sell column, margin gets worked out later, usually by someone in finance after the deal closes.
• Hiding project management. Folding PM time into engineering rates makes the PM line disappear from the quote and from the delivery budget too.
• Treating subcontracted work as a guess. Get the vendor's number, enter it as cost and set your markup. Don't invent an hourly rate to make it fit.
• One contingency rate for everything. Risk sits on specific lines. Put the reserve there.
• Rebuilding the CBS for every deal. Every rebuild is a chance for a different engineer to forget a different line.

See a CBS build itself while you scope

Pick services from your catalog and ScopeStack prices them by role at cost and at sell, broken down by phase.

How ScopeStack builds the CBS as you scope

In a spreadsheet, the WBS, RBS and CBS usually sit on separate tabs, and a change to one has to be carried to the others by hand. We built ScopeStack so they stay one model.

• Your WBS is built from your service catalog. Each standard service can carry a default phase, level of effort and resource. Presales teams define services, deliverables, dependencies and assumptions once and reuse them on every project.
• The RBS is your resources and rate tables. A rate table holds an hourly price and an hourly cost for each resource, so every line is priced at both.
• Project management is a setting. Project governance can add a PM percentage to every project, so a line like 5.1 in the example appears without anyone remembering it.
• Third-party work has its own path. Add a vendor resource with their hourly cost to you and your markup, or a vendor quote with a fixed cost and revenue when the subcontractor gives you one number.
• Approvals run on the numbers. A project can route for review when it crosses a revenue, gross profit or cost threshold you set, or when it contains certain services.
• The baseline goes to delivery. With our native ConnectWise PSA integration, an approved quote creates the project with tasks, phases and budgets.

What customers report after moving scoping into ScopeStack:

ScopeStack is rated 4.9 out of 5 on G2. If you want to see your own project types built this way, book a demo.

FAQ

Related guides

• Work breakdown structure for project management
• Complete guide to resource breakdown structure (RBS)
• Project estimation: techniques, challenges and how to improve accuracy
• How VARs protect margin on professional services quotes