BoQ, WBS and Cost Codes: How Contractors Connect Scope, Schedule and Cost

A Bill of Quantities (BoQ), Work Breakdown Structure (WBS) and Cost Codes do not describe the same thing.

 

• BoQ describes measurable and commercial scope.
• WBS describes how and when work is executed.
• Cost Codes describe how the contractor classifies and controls resources and expenditure.

 

For complex contractors, the objective should not be to force these dimensions into one hierarchy. Instead, it is to establish governed relationships between them. As a result, management can trace physical scope, schedule, resources, cost, commitments, progress and financial outcomes back to the same project baseline.

 

In short, that is the foundation of integrated project control.

 

Why Do Projects Need Three Structures?

 

In practice, people view a project from several legitimate perspectives.

 

• The client may ask: What quantity have you delivered and what can you invoice?
• The planner asks: Which activity should be executing now?
• The Cost Controller asks: Which budget and Cost Code should absorb the expenditure?
• The site manager asks: What resources did we consume to deliver today’s progress?
• Finally, finance asks: Where should we post the resulting transaction?

 

Of course, none of these questions is wrong.

 

Instead, the mistake is expecting one structure to answer all of them.

 

We all agree that: WBS alone is not enough for project cost control

 

The next question is therefore: What should WBS be connected to?

 

For many contractor environments, the answer begins with three dimensions:

 

BoQ ↔ WBS ↔ Cost Codes

 

What Does the BoQ Control?

 

The Bill of Quantities (BoQ) is, above all, a quantified and commercial representation of scope.

 

It answers:

 

• What are we delivering?
• How much are we delivering?
• How is that work measured and valued?

 

A BoQ line may contain:

 

• description;
• unit of measurement;
• quantity;
• rate;
• value;
• commercial or contractual classification.

 

During estimation, however, the BoQ becomes considerably more powerful. That happens when the estimator decomposes each measurable item into the resources required to produce it.

 

For example:

 

1 m³ reinforced concrete

 

may require:

 

• X labour hours across defined specialties;
• Y tonnes of reinforcement;
• Z m³ of ready-mix concrete;
• defined formwork quantities;
• machinery hours;
• subcontractor resources.

 

DANAOS Projects has a BoQ-centric estimating model that is based in site-tested cost recipes/productivity templates based on realistic construction site data.

 

The BoQ therefore answers an economic question that the schedule alone cannot:

 

What measurable output should these resources produce?

 

What Does the WBS Control?

 

The Work Breakdown Structure (WBS) organizes project execution.

 

It decomposes the project into progressively manageable time-constrained work packages. In addition, it provides the structure around which teams organize activities, responsibilities and schedules.

 

It answers:

 

• Where does the work belong?
• How is execution decomposed?
• When should it occur?

 

The U.S. GAO describes the WBS as a cornerstone for defining project work and establishing an integrated framework for schedule, cost and Earned Value Management.

 

U.S. GAO Cost Estimating and Assessment Guide

 

However, WBS and BoQ are not interchangeable.

 

• One BoQ item may contribute to multiple WBS activities.
• Conversely, one WBS activity may consume several BoQ items or resource types.

 

The relationship may therefore be:

 

one-to-one

 

one-to-many

 

or

 

many-to-many

 

depending on the project’s commercial and execution structure.

 

For this reason, mapping is more useful than forcing the structures to become identical.

 

What Do Cost Codes Control?

 

Cost Codes, or Cost Control Accounts structure the Cost Breakdown Structure (CBS) function, provide the internal management lens.

 

They answer:

 

• What type of cost is this?
• Where should it accumulate?
• Who is accountable for it?

 

For example, a contractor may want to distinguish:

 

• labour;
• concrete;
• reinforcement;
• fuel;
• heavy equipment;
• subcontracting;
• temporary works;
• indirect site costs;
• mobilization;
• overhead.

 

Of course, the client does not necessarily need to see the project through that structure.

 

Similarly, the scheduler does not necessarily need to plan through it.

 

But the Cost Controller and CFO do.

 

This is why independent project-control systems also maintain relationships between execution and cost structures.

 

Independent enterprise project-control systems also recognize the need for more than one project structure.

 

Oracle Primavera Unifier, for example, supports project-cost transactions containing both WBS and CBS codes. As a result, the same transaction can roll up to both the WBS Sheet and Cost Sheet.

 

That is important evidence that multidimensional project control is not unique to DANAOS Projects.

How Does BoQ ↔ WBS ↔ Cost Codes Differ from WBS + CBS?

 

However, there is also an important architectural distinction.

 

 

For contractors, that distinction matters.

 

• A Cost Breakdown Structure can tell management where a cost belongs.
• Similarly, a WBS can tell management where and when the teams execute the work.

 

But the BoQ or equivalent quantified scope answers another critical question:

 

What measurable output is being delivered, in what quantity and at what commercial value?

 

This is where ProjectVIEW ERP’s BoQ ↔ WBS ↔ Cost Codes architecture differs.

 

In other words, the BoQ adds the quantity and commercial dimension required to relate cost and schedule back to measurable physical output.

 

That enables questions such as:

 

• How much quantity should this WBS activity deliver?
• What resources did the estimate budget per unit of output?
• What quantity has actually been completed?
• Which resources did the crews consume to achieve it?
• What is the resulting actual unit cost?
• How much material must procurement still secure?
• Then, what quantity can the contractor certify or claim?
• How will remaining quantities affect cost-to-complete?

 

In short, the distinction is:

 

WBS + CBS = Where is the work, and where does the cost belong?

 

BoQ + WBS + Cost Codes = What are we delivering, where and when are we delivering it, and what is it costing us?

 

 

BoQ × WBS × Cost Codes: Three Dimensions of the Same Project Reality

 

In summary, the DANAOS Projects model is:

 

• BoQ = Scope / Quantity / Commercial Dimension
• WBS = Execution / Time Dimension
• Cost Codes = Cost Classification / Control Dimension

 

DANAOS describes that model as an integrated project performance baseline.

 

However, the value does not come merely from having all three structures.

 

Instead, the value comes from maintaining the relationships between them.

 

Consider a concrete package.

 

• The BoQ says: 10,000 m³ reinforced concrete
• The WBS says: Pier P05 → Foundation → Concrete Pour 03 → Week 27
• The Cost Codes say: Labour / Concrete / Reinforcement / Formwork / Plant

 

As a result, the organization can now connect:

 

what is being delivered

 

with

 

where and when it is being executed

 

with

 

what it should cost

 

and eventually with:

 

what resources were actually consumed.

 

What Becomes Possible Once the Three Structures Are Connected?

 

1. Cost-loaded scheduling

 

First, planners can time-phase the resources and budget of measurable scope through related WBS activities.

 

As a result, the organization can see not simply what the project will cost, but when economic exposure will likely occur.

 

2. Procurement planning

 

For example, a BoQ item may require 500 tonnes of reinforcement, and the corresponding WBS activity may start in Week 30. In that case, procurement can calculate the required material quantity and work backwards from the need date.

 

This transforms purchasing from:

 

“The site requested material.”

 

into:

 

“The project baseline predicts this material requirement.”

 

3. Productivity measurement

 

Similarly, if the estimate defines the resources required per unit of output, actual execution can compare:

 

• Budgeted quantity vs actual quantity
• Labour: budgeted vs actual
• Budgeted machinery vs actual machinery
• Budgeted unit cost vs actual unit cost

 

Productivity becomes the relationship between output and effort, not simply hours worked.

 

4. Earned Value Management

 

In addition, teams can relate physical progress to the budgeted value of completed work.

 

DANAOS Projects has examined this further in its discussion of Earned Value and construction performance control.

 

5. Forecast cost-to-complete

 

Finally, when actual productivity, committed cost and remaining quantities are visible together, forecasts can respond to execution reality rather than merely extrapolating historical accounting expenditure.

 

What Happens When the Structures Are Disconnected?

 

In practice, the consequences usually appear as reconciliation work.

 

• Planning maintains Primavera P6.
• Meanwhile, estimators retain the original BoQ and budget in Excel or another estimating platform.
• Procurement manages purchasing against material masters.
• Accounting posts expenditure against financial accounts.
• Finally, site teams report progress separately.

 

As a result, the organization technically has all the data.

 

However, the causal relationships between the data are weak.

 

Consequently, management spends time answering questions such as:

 

• Which activity created this cost?
• Which BoQ quantity does this purchase order support?
• What physical output did these labour hours produce?
• Which variation caused the forecast increase?
• Why is the schedule 70% complete while resource consumption is already at 85%?

 

DANAOS Projects has examined this broader problem in The Failure of Generalist ERPs in Capital Projects.

 

In other words, the issue is less about whether each individual system functions correctly.

 

Rather, the issue is whether they describe the same project reality.

 

How Does This Work on a Megaproject with Multiple Contractors?

 

This becomes even more important at owner or program level.

 

For example, a megaproject may involve several contractors, each with:

 

• its own WBS;
• different physical-area hierarchies;
• its own Cost Codes;
• different subcontract structures;
• thousands of assets and handover objects;
• different methods for measuring physical progress.

 

It is unrealistic to assume that every contractor will use an identical execution hierarchy.

 

Therefore, the solution is not necessarily to impose one enormous universal WBS.

 

Instead, a stronger approach is to create common normalization dimensions above or across contractor structures.

 

These may include:

 

• project phase;
• discipline;
• work class;
• physical area;
• system;
• asset;
• deliverable;
• contractor;
• weighted worksteps.

 

The owner can then associate assets or deliverables with each contractor’s respective WBS. At the same time, it still classifies them through common owner dimensions.

 

As a result, the owner can analyze progress by:

 

• Contractor
• Area
• Discipline
• Project Phase
• Work Class
• Asset/System

 

while preserving each contractor’s detailed execution structure.

 

In turn, that creates a stronger foundation for normalized S-curves, cross-contractor progress comparison and auditable verification of progress claims.

 

In short, the principle is the same:

 

do not force every control question into a single hierarchy—maintain relationships between governed dimensions.

 

How Does ProjectVIEW ERP Apply the Model?

 

ProjectVIEW ERP is built around the explicit association:

 

BoQ ↔ WBS ↔ Cost Codes

 

The ProjectVIEW ERP Cost Control Module documents this relationship together with Oracle Primavera P6/MS Project integration, resource allocation, multiple BoQ/WBS versions, actual site progress, labour, plant, subcontractor activity and actual-vs-budget cost.

 

The ProjectVIEW ERP Budget Estimation & Bidding Module establishes the quantified, resource-based baseline. Against that baseline, the contractor then controls execution.

 

In addition, the wider ProjectVIEW OS for the BUILD World extends the principle into a structured project data model intended to support construction, marine/offshore, mining, shipbuilding and other project-driven environments.

 

However, the objective is not merely to display three codes on the same transaction.

 

Instead, it is to allow procurement, resources, subcontractors, site progress, commitments, cost and financial transactions to inherit the same project context.

 

The Model Also Applies Beyond Construction

 

The terminology will vary by industry.

 

• A shipyard may use Job Lists, vessel systems, blocks, production work packages and repair items.
• Similarly, a marine contractor may organize work around vessels, offshore locations, dredging quantities or installation packages.
• A mining contractor may organize execution around areas, production quantities, development activities and equipment fleets.
• Finally, a project-based manufacturer may use bills of materials, production orders and engineered assemblies.

 

ProjectVIEW ERP adapts the model to these different operational structures.

 

The universal principle is:

 

Quantified Scope ↔ Execution Structure ↔ Cost Structure

 

The names may change.

 

However, the need to connect them does not.

 

What Should Enterprise Contractors Test?

 

A practical project-controls architecture should be able to answer:

 

1. Can you trace every significant project cost to scope and execution?
2. Can one BoQ item map to multiple WBS activities where required?
3. Similarly, can one WBS activity consume multiple cost categories?
4. Can actual physical progress be related to measurable quantities?
5. Can procurement derive its requirements from the project baseline and WBS need dates?
6. Likewise, can the team relate labour and machinery consumption to the output it produced?
7. Can committed cost be traced to scope before an invoice exists?
8. Can variations preserve the relationship between BoQ, WBS, Cost Codes and revenue?
9. Also, can management analyze the project by multiple dimensions without duplicating data?
10. Can operational transactions ultimately reconcile with corporate finance?

 

If the system cannot answer these questions consistently, adding another dashboard may not solve the underlying problem.

 

Instead, the problem is likely structural.

 

Conclusion: Integration Is More Important Than Hierarchy

 

BoQ, WBS and Cost Codes perform different jobs.

 

As a result, trying to collapse them into a single structure can remove useful context.

 

Keeping them completely separate creates reconciliation.

 

Therefore, the better approach is relational.

 

BoQ tells us what and how much.

 

WBS tells us where, when and in what sequence.

 

Cost Codes tell us what resources and cost categories the project consumes.

 

When those dimensions remain connected, the contractor can follow the full chain:

 

Estimate → Budget → Schedule → Procurement → Execution → Progress → Cost → Forecast → Financial Outcome

 

That is the real value of BoQ ↔ WBS ↔ Cost Codes.

 

Not three codes.

 

Three coordinated views of the same project reality.