Cost Aggregation
Cost technique · See it on the map
Runnable here
Adding up cost estimates from the smallest tasks up through the whole project into one traceable budget.
When to use it
Whenever you need a cost baseline that survives being questioned: every figure at every level should be recoverable by adding the level below it. Do it once the WBS is stable enough that work packages won't keep moving between control accounts.
When to avoid it
Don't re-aggregate from scratch every time one estimate changes — that's how a spreadsheet turns into an hour of clicking. If the WBS itself is still churning, aggregate loosely and re-baseline later rather than chasing a moving structure to the penny.
Steps
What it produces
- A cost baseline: one total, traceable down to every work package that makes it up.
- A control-account-by-control-account breakdown usable for later variance reporting.
Common pitfalls
- A work package attached to two control accounts, silently doubling its cost in the rollup.
- Contingency buried inside individual estimates instead of held visibly at the account level, so nobody can later tell how much cushion is left.
- Aggregating before the WBS is stable, then re-aggregating every time a package moves, instead of waiting for a natural re-baseline point.
Worked example
A tenant-improvement build-out has three control accounts: Demolition, MEP rough-in, and Finishes. Demolition sums four work packages to $38,000; MEP rough-in sums seven to $164,500; Finishes sums nine to $97,200. The project total, before reserve, is $299,700. The team adds $18,000 of contingency reserve at the project level, giving a BAC of $317,700 that a stakeholder can trace back to any of the twenty work packages underneath it.
Source
- PMBOK-6 §7.3.2.2
Where it comes from: this technique is named by the PMBOK Guide, 6th edition.