What an S-curve is supposed to tell you
An S-curve plots cumulative value against time. In a project controls context, "value" is usually one of three things: planned spend (the budget spread over time), actual spend (what has been committed or invoiced), or earned value (the budgeted cost of work actually completed). Sometimes all three are plotted on the same chart.
The shape is characteristically S-shaped because projects typically start slowly — mobilisation, early design, procurement — then ramp up steeply through peak delivery, then taper off as work closes out. Plotting that pattern gives you the curve.
Used well, an S-curve is a compact, readable summary of project financial progress. At a glance, a client, sponsor, or senior manager can see whether spend is tracking the plan, whether the project is behind or ahead, and how much of the budget has been consumed relative to how much work has been done. It is one of the oldest and most durable tools in project reporting — which is exactly why its failure modes are so well-worn and so frequently ignored.
The five ways S-curves mislead
Understanding why an S-curve can mislead requires looking at each failure mode in turn. They rarely appear alone — on a struggling programme, you will often find several at once.
1. The baseline was never realistic
An S-curve is only as useful as the baseline it is measured against. If the original baseline was built on an optimistic estimate, an unrealistic programme, or assumptions that were outdated within weeks of issue, then the curve is measuring progress against a fiction.
This is more common than it should be. Cost plans are often issued under commercial or political pressure to meet a target number rather than reflect a genuine forecast. Schedules are produced to satisfy a gateway requirement rather than to model how the work will actually be sequenced and resourced. When the project starts spending — or not spending — along its actual trajectory, the S-curve shows a divergence that looks like underperformance but is really just the gap between optimism and reality.
The tell is that the actual spend curve hugs the bottom of the planned spend curve from day one. There is never a period where the project is tracking well. The divergence is there in month one and it only grows. That is not a delivery problem — that is a baseline problem. And no amount of project controls reporting will close the gap until someone recasts the baseline to reflect what is actually achievable.
2. The baseline has never been rebaselined
Closely related, but distinct: the baseline was plausible when it was set, but the project has since changed substantially — scope change, contract variations, design development, force majeure — and the baseline has not been updated to reflect the new state of play.
Rebaselining is politically uncomfortable. It requires acknowledging that the project has changed and the original numbers no longer apply. On publicly funded projects, rebaselining can trigger scrutiny from funders, auditors, or ministers. So baselines persist long past their usefulness, and the S-curve becomes a comparison between current performance and a baseline that describes a different project.
The NEC contract suite, which is widely used on UK public-sector projects, has a structured mechanism for compensation events that should, in principle, keep the target cost updated. In practice, disputes about compensation event valuations mean the baseline often lags. The result is an S-curve that is technically correct — it shows actuals against the contractual baseline — but managerially misleading, because the baseline is not the project any more.
The APM Body of Knowledge is clear that the project baseline should be maintained and updated through formal change control. A baseline that is more than six months old on a fast-moving programme should prompt the question: does this still describe what we are building?
3. Aggregation is hiding the detail
An S-curve is a summary. All summaries aggregate. Aggregation conceals.
The most common version of this problem is a programme-level S-curve that looks healthy because one package is running ahead of plan and offsetting another that is running significantly behind. The overall curve tracks the baseline. The project controls team reports no concern. Meanwhile, the mechanical and electrical package is six weeks late and the project manager for that package has been sending warning emails for two months.
S-curves should be produced at the package or work breakdown structure level, not just at the programme level. When an aggregate curve is the only thing reported upward, the people making decisions are seeing a smoothed average that may not reflect the state of any individual part of the work. Package-level curves are more work to produce and harder to present in a single slide. They are also the only version that is genuinely informative.
A related aggregation problem occurs on multi-project programmes, where individual project curves are combined into a portfolio view. Portfolio S-curves have their uses — they give funders and programme boards a high-level view — but they should never be used as a substitute for project-level reporting. The portfolio can look fine right up until the point where it is not.
4. Earned value is being gamed
Earned Value Management — EVM — should make the S-curve more useful, not less, because the earned value line tells you not just what you have spent but what you have actually achieved. Actuals above the earned value line means you are spending more than the work is worth. Actuals below means you are either running efficiently or deferring spend.
In practice, earned value is often the most manipulated number on the chart. Progress is self-reported. The teams reporting progress have an obvious incentive to show momentum. Without rigorous physical percent-complete rules — the 0/100 rule, the 50/50 rule, or milestone-based earning — earned value creep is almost inevitable.
The warning signs are an earned value line that tracks actuals almost exactly (suggesting EV is being reverse-engineered from spend rather than measured from physical progress), or a project that reports 80% complete in terms of earned value but is clearly not 80% done in any physical sense. Both are common. Both mean the S-curve is showing you a reassuring fiction.
Proper EVM requires agreed earning rules, documented in the control account plan, applied consistently, and audited periodically. AACE Recommended Practice 73R-12 covers earned value implementation in detail. The APM Earned Value Management Handbook is a useful UK-focused reference. On MoD CADMID Manufacture-phase contracts the EVMS reporting requirement is stipulated in the contract data and aligns to AACE 11R-88 — and the reverse-engineered earned value signature described above is precisely the failure mode IPA and MPRP reviewers look for at gate. If neither document has been consulted in the production of the EVM system, treat the earned value curve with scepticism.
5. Risk has been ignored
A deterministic S-curve shows one line for planned spend. It has no width. It conveys no uncertainty. It implies that the project will, absent any problems, track exactly the planned profile — and that any deviation is a management failure rather than an expected consequence of the risks inherent in the work.
This is a structural misrepresentation of how projects work. Every baseline is an expected-value plan — it represents the central estimate of what will happen. But there is a distribution of possible outcomes around that central estimate, and the S-curve does not show it.
Adding probabilistic bands to an S-curve — drawing the P20 and P80 envelope around the deterministic baseline — is standard practice in programmes that run integrated QRA. It changes the message of the chart fundamentally: instead of "we are behind plan," the chart shows "we are within the expected range of outcomes" or "we are outside the expected range of outcomes." The former invites unhelpful questions about what went wrong. The latter is an honest acknowledgement that project delivery involves uncertainty.
If your S-curve reporting does not have probabilistic bounds, you are measuring performance against a theoretical perfect outcome. That is not a useful benchmark.
What a healthy S-curve looks like
A well-constructed S-curve for a real project should show a baseline that was built bottom-up from a credible estimate and a logic-linked, resourced schedule. It should be accompanied by a date stamp and revision number so readers know when it was last updated. It should have been through formal change control every time scope or programme changed materially.
The actuals line should track smoothly — erratic spikes and dips usually indicate invoicing or accruals timing problems, not real project volatility. If actuals look smooth and the project feels chaotic on site, the accruals basis needs investigating.
If EVM is in use, the earned value line should diverge from actuals in ways that make physical sense. A project that is genuinely ahead of plan on a labour-intensive activity should show EV above AC. A project that has mobilised heavily but not yet produced much physical output should show AC above EV, with EV expected to catch up as production ramps.
Probabilistic bands, where the programme has run QRA, should be present and should reflect current risk exposure — not the risk register from six months ago. The current actuals and earned value should sit comfortably within the bands for a project that is tracking as expected.
Crucially, a healthy S-curve should be accompanied by a written narrative. The curve shows what is happening. The narrative explains why. A curve without a narrative is a picture without a caption: readable, but not informative.
How to fix it
Fixing a broken S-curve reporting process requires addressing the root causes, not just the symptoms. That usually means three things.
First, audit the baseline. If it has not been updated in more than a quarter and scope has changed, commission a rebaselining exercise. This will be uncomfortable. Do it anyway. A misleading baseline is worse than an honest acknowledgement that the project has moved.
Second, establish proper earning rules if EVM is in use. Write them into the control account plan. Conduct a one-day workshop with package managers to agree how progress will be measured — physically, not financially — and document the outcome. Then audit compliance quarterly.
Third, disaggregate. Produce package-level curves alongside the programme-level summary. Make the package-level data available to the project controls team and the project manager. The programme-level curve is for the board and the client. The package-level curves are for the people running the work.
None of this is novel. The guidance exists — in AACE standards, the APM Body of Knowledge, and NEC contract administration guidance. The problem is rarely knowledge. It is the institutional pressure to produce a report that looks acceptable rather than one that is accurate. That pressure can only be addressed by senior sponsors who ask hard questions about the assumptions behind the curves — and who recognise that an honest curve showing a problem is more valuable than a tidy curve hiding one.
When to abandon S-curve reporting entirely
Sometimes the honest answer is that an S-curve is not the right tool. There are project types where the S-curve convention is so poorly suited to the work that continuing to produce one creates more confusion than it resolves.
Time-and-materials or cost-reimbursable contracts with highly variable scope — consultancy programmes, research and development work, early-stage design commissions — do not have the kind of stable baseline that makes an S-curve meaningful. You can plot actuals against a budget envelope, but the baseline is an estimate with very wide uncertainty, and any apparent divergence may simply be scope crystallisation rather than underperformance.
Phased programmes where phases have not yet been scoped and costed are another case. Plotting phase-three and phase-four spend on a long-horizon S-curve, when the work for those phases has not been defined, is forecasting fiction. Better to show a well-defined near-term curve and acknowledge the uncertainty in the out-years explicitly.
Highly iterative or agile delivery approaches — common in digital and technology programmes — report progress in velocity and throughput, not in financial S-curves. Forcing agile teams to produce S-curve reporting distorts their working practices without adding genuine insight. There are better tools for those environments.
The test is simple: does this S-curve help decision-makers make better decisions? If the honest answer is no — because the baseline is unreliable, the data cannot be trusted, or the format does not fit the delivery model — then producing it is bureaucratic theatre. Stop producing it, and find a reporting method that is honest about what is actually known. Your programme board will not thank you immediately. They will thank you when they avoid a nasty surprise.