What Is Planned Value (BCWS)? PV in Construction Explained

<div class="ge-article-wrapper"><nav class="ge-toc" aria-label="Table of contents"><p class="ge-toc-label">In this article</p><ul class="ge-toc-list"><li><a href="#the-definition">The Definition</a></li><li><a href="#how-pv-creates-the-baseline-s-curve">How PV Creates the Baseline S-Curve</a></li><li><a href="#what-pv-tells-you-and-what-it-doesnt">What PV Tells You (And What It Doesn't)</a></li><li><a href="#worked-example-pv-from-a-cost-loaded-programme">Worked Example: PV from a Cost-Loaded Programme</a></li><li><a href="#pv-on-nec4-contracts">PV on NEC4 Contracts</a></li><li><a href="#common-mistakes">Common Mistakes</a></li><li><a href="#frequently-asked-questions">Frequently Asked Questions</a></li></ul></nav><article class="ge-article-body"><p>Planned Value (PV) is the cumulative budgeted cost for work scheduled to be completed by a given date. It comes from the cost-loaded baseline programme, not from any formula. If your programme says 30% of the work should be done by month 5 on a £12M project, PV at month 5 is £3.6M. That's the plan. Not what you've spent. Not what you've delivered. What you said you'd have in the ground by now. </p><p>PV is also known as BCWS (Budgeted Cost of Work Scheduled), which is the older US Department of Defense term. They're identical. Same definition, same number, different acronym. </p><p>This page is part of the <a href="/en/earned-value/definitions">earned value definitions glossary</a>. For the full formula reference, see the <a href="/en/earned-value/formulas">earned value formulas page</a>. For a comprehensive treatment of how PV fits with <a href="/en/earned-value/definitions/actual-cost">AC</a> and <a href="/en/earned-value/definitions/earned-value">EV</a>, see the <a href="/en/earned-value">earned value management pillar</a>. </p><h2 id="the-definition">The Definition</h2><p><strong>PV = cumulative budgeted cost for work scheduled to date</strong></p><p>There's no formula that produces PV. It comes from a programme. Specifically, a baseline programme where every activity has been assigned a budget value (cost-loaded). The cumulative PV at any reporting period is the sum of all cost-loaded activities that should be complete or in progress by that date, weighted by their planned percentage. </p><h2 id="how-pv-creates-the-baseline-s-curve">How PV Creates the Baseline S-Curve</h2><p>When you plot cumulative PV month by month, you get the planned S-curve. This is the backbone of every <a href="/en/earned-value">earned value</a> report. </p><pre class="ge-ascii-diagram ge-anim"> Building the PV Curve From Activity Budgets Activity budgets (from cost-loaded programme): Activity A (£800K): ████████ Activity B (£1.2M): ████████████ Activity C (£600K): ██████ Activity D (£1.4M): ██████████████ Activity E (£1.0M): ██████████ ───────────────────────────── M1 M2 M3 M4 M5 M6 M7 M8 Stacked monthly PV: £K 900 │ ┌───┐ 800 │ ┌───┐ │ │ 700 │ ┌───┐ │ │ │ │ ┌───┐ 600 │┌───┐ │ │ │ │ │ │ │ │ 500 ││ │ │ │ │ │ │ │ │ │ ┌───┐ 400 ││ │ │ │ │ │ │ │ │ │ │ │ 200 ││ │ │ │ │ │ │ │ │ │ │ │ ┌───┐ │└───┘ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘ M1 M2 M3 M4 M5 M6 M7 M8 Cumulative PV (the S-curve): £M 5.0 │ ●────● BAC 4.5 │ ●────● 4.0 │ ●────● 3.5 │ ●────● 2.5 │ ●────● 1.5 │ ●────● 0.8 │●────● └────────────────────────────────────────── M1 M2 M3 M4 M5 M6 M7 M8 At month 4: PV = £3.5M (This is what the plan says should be done) </pre><p>The S-curve shape comes from the typical project profile: slow start during mobilisation, ramp-up through the main works, peak activity mid-project, then tailing off through commissioning and completion. The cumulative total approaches <a href="/en/earned-value/definitions/budget-at-completion">BAC</a> at project completion. </p><h2 id="what-pv-tells-you-and-what-it-doesnt">What PV Tells You (And What It Doesn't)</h2><p>PV tells you one thing: what the plan says should have been accomplished by now, measured in budget terms. That's useful for exactly two comparisons: </p><ol><li><strong>EV vs PV = Schedule performance.</strong><a href="/en/earned-value/cost-schedule-variance">Schedule Variance</a> (SV = EV - PV) and <a href="/en/earned-value/definitions/schedule-performance-index">SPI</a> (EV / PV) both tell you whether progress is ahead or behind the plan.</li><li><strong>PV as a reference point for AC.</strong> If you've spent more than PV but achieved less (EV < PV while AC > PV), that's a double-negative: behind programme and overspending.</li></ol><p>What PV doesn't tell you: whether the plan itself was any good. A project can be perfectly "on PV" while heading for disaster because the baseline programme was unrealistic from day one. PV is only as good as the programme it comes from. </p><p>I've seen a £22M project where the PV curve showed a perfectly smooth S-curve. Beautiful on paper. The problem? The planner had spread the budget evenly across 14 months without accounting for seasonal constraints. The piling couldn't start until April (ground conditions), the cladding couldn't go up in December (weather), and the commissioning needed three weeks of exclusive access that wasn't programmed. PV was smooth. Reality was anything but. </p><h2 id="worked-example-pv-from-a-cost-loaded-programme">Worked Example: PV from a Cost-Loaded Programme</h2><span class="ge-worked-label">Worked Example</span><div class="ge-callout ge-anim"><p><strong>Scenario:</strong> A £12M NEC4 Option C car park construction in Manchester. 10-month programme from January 2025 to October 2025. The planner cost-loads the Accepted Programme during mobilisation.</p><br><p><strong>Cost-loaded programme extract (months 1-5):</strong></p><br><div class="ge-table-wrap ge-anim"><table class="ge-table"><thead><tr><th>Activity</th><th>Budget</th><th>M1</th><th>M2</th><th>M3</th><th>M4</th><th>M5</th></tr></thead><tbody><tr><td>Enabling works</td><td>£400K</td><td>£400K</td><td></td><td></td><td></td><td></td></tr><tr><td>Piling</td><td>£1.8M</td><td></td><td>£600K</td><td>£600K</td><td>£600K</td><td></td></tr><tr><td>Substructure</td><td>£1.6M</td><td></td><td></td><td>£400K</td><td>£800K</td><td>£400K</td></tr><tr><td>Frame erection</td><td>£3.2M</td><td></td><td></td><td></td><td>£640K</td><td>£1,280K</td></tr><tr><td>M&amp;E first fix</td><td>£1.2M</td><td></td><td></td><td></td><td></td><td>£360K</td></tr><tr><td>Other activities</td><td>£3.8M</td><td></td><td></td><td></td><td></td><td>£160K</td></tr><tr><td><strong>Monthly PV</strong></td><td></td><td><strong>£400K</strong></td><td><strong>£600K</strong></td><td><strong>£1,000K</strong></td><td><strong>£2,040K</strong></td><td><strong>£2,200K</strong></td></tr><tr><td><strong>Cumulative PV</strong></td><td></td><td><strong>£400K</strong></td><td><strong>£1,000K</strong></td><td><strong>£2,000K</strong></td><td><strong>£4,040K</strong></td><td><strong>£6,240K</strong></td></tr></tbody></table></div><br><p><strong>At end of month 4 (April 2025):</strong></p><p>- <strong>PV = £4,040,000</strong> (the plan says 33.7% of the £12M should be done)</p><p>- EV (from <a href="/en/earned-value/definitions/physical-percent-complete">physical percent complete</a> measurement) = £3,600,000</p><p>- SPI = £3.6M / £4.04M = <strong>0.891</strong></p><br><p>The project is delivering at 89.1% of the planned rate. It's behind by £440K of value. Not catastrophic, but if the trend continues, the team needs to understand why and whether recovery is planned.</p><br><p><strong>The question for the progress meeting:</strong> "Is the SPI of 0.89 due to a genuine delay, or did the planner front-load the PV curve?" On this project, the piling was 2 weeks late starting due to rig availability. That accounts for roughly £300K of the shortfall. The remaining £140K is slower-than-planned substructure work. Two different issues needing two different responses.</p></div><h2 id="pv-on-nec4-contracts">PV on NEC4 Contracts</h2><p>On NEC4, PV derives from the Accepted Programme. This creates both an opportunity and a risk. </p><p><strong>The opportunity:</strong> NEC4 requires the Contractor to submit a programme for acceptance (clause 31). If accepted, the Accepted Programme becomes a contractual baseline. Cost-loading this programme gives you a contractually grounded PV that's hard to dispute. </p><p><strong>The risk:</strong> If the programme isn't accepted (which happens more often than it should), there's no formal baseline. Your PV is based on the Contractor's intended programme, which may or may not reflect reality. I've worked on projects where the programme hadn't been accepted for 8 months. The EVM data was technically valid but contractually meaningless. </p><p>For NEC4 Option C specifically: the cost-loaded Accepted Programme against the target total of the Prices is your PV source. Every implemented CE under clause 65 adjusts the target and should adjust the PV curve for future periods. </p><h2 id="common-mistakes">Common Mistakes</h2><ol><li><strong>Deriving PV from spend profiles rather than the programme.</strong> Some teams create PV by spreading the budget evenly or using a standard S-curve template. That's not PV. PV comes from the programme. If the programme says 45% of the work should be done by month 6, PV at month 6 is 45% of BAC, even if a standard S-curve would suggest 40%.</li><li><strong>Not updating PV when the baseline changes.</strong> Approved scope changes (CEs on NEC4) change both BAC and the future PV profile. If you add £800K of new work spanning months 7-9, PV at months 7-9 should increase. Historical PV stays unchanged.</li><li><strong>Confusing PV with <a href="/en/earned-value/definitions/actual-cost">AC</a>.</strong> PV is the plan. AC is reality. They'll almost never match. That's the point. The gap between them (and between EV and each) is where the diagnostic value lives.</li><li><strong>Front-loading PV to make early performance look good.</strong> If the planner assigns disproportionate budget to early activities, PV starts high. When EV catches up, SPI looks great. But the project hasn't actually accelerated. The baseline was just sandbagged. A good <a href="/en/earned-value/definitions/performance-measurement-baseline">PMB</a> review catches this during baseline setup.</li></ol><div class="ge-product-note ge-anim"><p><strong>How Gather helps.</strong> Gather's AI reads your site diaries daily and maps progress against your cost-loaded programme, giving you accurate earned value data without manual spreadsheet updates. <a href="https://gatherinsights.com/contact">Book a demo</a> to see it working on a live NEC4 project.</p></div><h2 id="frequently-asked-questions">Frequently Asked Questions</h2><h3>Does PV change during the project?</h3><p>PV at a given past date doesn't change. It's fixed by the baseline. But cumulative PV increases each month as more work becomes scheduled. If the baseline programme is formally revised (re-accepted on NEC4), then PV at future dates changes. Historical PV should never be retroactively adjusted. </p><h3>What's the difference between PV and <a href="/en/earned-value/definitions/budget-at-completion">BAC</a>?</h3><p>BAC is the total project budget. PV is the cumulative budget for work scheduled up to a specific date. At project completion, PV equals BAC (because all work should be scheduled by then). During the project, PV is always less than or equal to BAC. </p><h3>How do I cost-load a programme to create PV?</h3><p>Allocate BAC across programme activities based on their proportion of total work. The simplest approach on NEC4 Option A: use the activity schedule prices. On Option C: use the tender build-up or Defined Cost estimate for each activity. Each activity's cost allocation should reflect its share of total cost. The sum must equal BAC. </p><h3>What if PV and EV are both zero at month 3?</h3><p>Then the programme shows no work scheduled for the first three months and no work has been completed. Check whether this is correct (mobilisation period, design phase) or whether the programme needs revising. A long period of zero PV and zero EV at the start isn't necessarily a problem, but it makes early performance reporting meaningless. </p></article></div>