The S-curve: how to read it and what to do when you fall behind schedule
The S-curve is a chart showing a project's cumulative progress over time, comparing what was planned against what was actually built. It takes its name from its shape: a slow start, acceleration through the middle and a slowdown at the end. It is the most widely used tool for answering, at a glance, whether a project is doing well or badly.
The trouble is that almost everyone looks at it and very few people use it to decide. Seeing the actual line run below the planned one is not actionable information. What is actionable is understanding why, by how much, and what happens if it is not corrected.
Why it is S-shaped
It is not a drawing convention. It is how a project actually behaves.
The start is slow. Site setup, mobilisation, permits, foundations. Time is consumed and little visible progress is produced. The first weeks almost always look like a failure and they are not.
The middle is fast. Structure and masonry, with several fronts open and crews in their stride. This is where most of the progress piles up.
The close is slow again. Finishes, details, testing, closing out comments, handover. A lot of low-value, highly scattered work. The last 10 % of progress usually eats 20 % of the schedule.
Understanding this matters for reading it. A project that is 10 % complete at 20 % of the schedule may be perfectly fine. The same ratio at 60 % of the schedule is an emergency.
How it is built
You need two series of cumulative data over time.
The planned curve comes from the schedule. For each period, the cumulative percentage you should have completed. It is worked out by spreading each item’s value across its planned duration and adding up.
The actual curve comes from your progress records. For each period, the cumulative percentage actually completed.
The question that always comes up: physical progress or financial progress?
| Type | How it is measured | When to use it |
|---|---|---|
| Physical progress | Quantities completed over total quantities, weighted | To control execution |
| Financial progress | Value completed over total contract value | To control cash flow and billing |
They are not the same and it pays to keep both. A project can look fine in physical terms and bad in financial ones if you built a lot of the cheap items and little of the expensive ones. The value-weighted version —each item weighs what it represents in the budget— is the one that best reflects reality, and the one most contracts use.
An example
A $2,400,000 project with a 300-day schedule. We are on day 120.
| Day | Planned cumulative | Actual cumulative | Gap |
|---|---|---|---|
| 30 | 3 % | 2 % | −1 pp |
| 60 | 10 % | 7 % | −3 pp |
| 90 | 20 % | 15 % | −5 pp |
| 120 | 32 % | 24 % | −8 pp |
In money, at day 120: you should have $768,000 built and you have $576,000. A $192,000 difference you did not bill.
But the most useful figure is not the gap in percentage points. It is the ratio between the two curves:
Actual progress 24
Index = ─────────────────────── = ──── = 0.75
Planned progress 32
An index of 0.75 means you are advancing at 75 % of the planned speed. That number is far more useful than “we are 8 points down”, because it does not depend on where you are in the project and it can be projected forward.
How to read the gap
Three questions, in this order.
Is the gap widening, closing or stable? It comes first and almost nobody looks at it. In the example, the gap went from 1 to 3 to 5 to 8 points: it is widening steadily. That is worse than a large but stable gap, because it means the cause is still active.
Is it a speed problem or a late start? Starting two weeks late and then running at the planned rate is not the same as starting on time and running slower. The first is recovered by compressing or overlapping activities. The second is not recovered without changing something fundamental, because the cause is still there.
Which items explain the gap? The aggregate curve hides the useful information. The delay is almost always concentrated in two or three items while the rest is fine. Breaking it down by item is what turns the curve into a diagnosis.
What to do when you are behind
- Check that the planned curve is still valid. If there were scope changes, change orders or authorised suspensions and the schedule was never updated, you are measuring against a baseline that no longer exists. Comparing against an obsolete schedule produces false arguments.
- Work out whether the constraint is resources or sequence. If the problem is capacity —not enough people, not enough plant— the answer is more resources, and it can be quantified. If the problem is sequence —a predecessor that does not release the front— throwing people at it does nothing and only raises the cost.
- Decide between recovering and rescheduling. They are different roads.
- Document the causes, which is what gets neglected most. Days lost to rain, late material from the client, fronts not released, instructions that arrived late. All of it dated and with contemporaneous evidence. A gap explained with a dated record is the basis of an extension-of-time claim. The same gap without a record is your liability by default.
| Recover | Reschedule |
|---|---|
| Add crews or shifts | Update the completion date |
| Overlap activities | Renegotiate interim milestones |
| Raises the cost | May carry liquidated damages |
| Only works if the constraint is resources | Is the honest answer if the constraint is structural |
The most common mistake
Updating the curve once a month.
With monthly updates you find out about a problem 15 to 30 days after it started, and by then the gap has already opened. In the example, the trend was visible from day 60: the gap doubled three times running. Whoever updates weekly sees that pattern in week 8. Whoever updates monthly sees it on day 120, when fixing it costs three times as much.
The update frequency sets how fast you can react. It is the cheapest decision you can make about site control and also the one most often put off, because updating the curve requires having progress measured, and measuring progress daily is precisely the habit that is hard to install.
Frequently asked questions
- How often should I update the S-curve?
- Weekly at the very least. On short or fast-moving projects, daily. Monthly is for reporting upwards, not for deciding.
- What is the difference between the S-curve and the schedule?
- The schedule shows which activity happens when and in what sequence. The S-curve boils all of that down to a single line of cumulative progress. The curve is derived from the schedule, it does not replace it: when the curve flags a problem, the schedule is where you go looking for the cause.
- Can I have an S-curve per line item?
- Yes, and it is the most useful thing you can do with the tool. The aggregate curve tells you there is a problem; the per-item curves tell you where. Focus it on the items that carry most of the budget.
- Is an actual curve above the planned one always good news?
- Not necessarily. It can mean you front-loaded the easy items and left the complex ones for the end, which pushes risk to the close, when you have the least room. It is worth checking what that lead is made of.
- How do I handle change orders in the curve?
- By updating the planned curve to take in the new scope, dated, and keeping the previous version. If you mix new scope in without updating the baseline, the curve stops meaning anything and you lose the trace of why it changed.
Founder and CEO of Paladio. He has spent more than 15 years building financial products that touch the lives of millions of people. He writes about what he sees on site: how progress is really measured and where the money leaks.
See all their articles →