Project Budget Baseline Guide

The project budget baseline (also called the cost baseline) is the approved, time-phased version of the project budget. It serves as the reference point against which all cost performance is measured throughout the project lifecycle. Without a solid baseline, Earned Value Management produces meaningless numbers.

This guide explains what a budget baseline is, how it differs from the Budget at Completion (BAC), how to establish one correctly, and how to manage it when scope or cost changes occur.

Cost Baseline vs. Budget at Completion (BAC)

In PMBOK terminology, BAC = Cost Baseline. Management reserves sit above the cost baseline and are not part of BAC. They require a change request to access.

How to Build a Project Cost Baseline

Step 1: Complete the WBS and WBS Dictionary

Every work package in the Work Breakdown Structure (WBS) must be defined well enough to estimate its cost. The WBS dictionary provides the scope narrative, deliverables, and acceptance criteria for each work package.

Step 2: Estimate Costs Bottom-Up

For each work package, estimate:

• Labor costs: hours × loaded labor rate for each resource type
• Material costs: quantities × unit prices (include waste factors)
• Equipment costs: rental rates, fuel, maintenance
• Subcontractor costs: vendor quotes or analogous estimates
• Indirect costs: overhead, site facilities, shared services

Step 3: Add Contingency Reserves

Contingency reserves cover known risks (risks documented in your risk register). Calculate based on expected monetary value (EMV) of identified risks, or use a percentage of the base estimate (typically 10–20% depending on project risk level).

Step 4: Time-Phase the Budget (Create the PV Curve)

Spread the budget across the project timeline according to the schedule. This creates the Planned Value (PV) for each reporting period — the S-curve that EVM uses as its baseline. Total PV at end = BAC.

Step 5: Get Formal Approval

The cost baseline must be formally approved by the project sponsor or change control board before execution begins. This approval makes it the official reference point.

Managing Baseline Changes

The baseline must be protected from informal changes. Every change to BAC should go through:

1. Change request: formally document the scope change and its cost impact
2. Impact assessment: quantify cost, schedule, and risk impacts
3. Change control board review: approve, reject, or defer
4. Baseline update: if approved, update both the BAC and PV curve
5. Communication: notify all stakeholders of the updated baseline

Common Baseline Mistakes

• Setting baseline too early: Baselinng before scope is fully defined leads to unrealistic budget and constant changes
• Informal scope additions: Team members accept small changes without formal approval; scope creep erodes the baseline's integrity
• No time-phasing: A single lump-sum budget without time-phasing cannot generate PV data for EVM
• Revision without documentation: Changing BAC without recording the change history makes performance trends uninterpretable
• Padding every estimate: Individual work package owners adding hidden contingency creates a bloated baseline and inaccurate EVM data

When to Revise the Baseline

A baseline revision (re-baselining) is appropriate when:

• Approved scope changes add or remove significant work
• TCPI(BAC) exceeds 1.10 and the original BAC is demonstrably unachievable
• A force majeure event fundamentally changes project conditions
• Management chooses to re-baseline to restore meaningful performance measurement

Re-baselining resets the EVM clock — prior performance variances are absorbed into the new baseline. This should be used sparingly and only with sponsor approval.