“S-Curve Template: Free Examples, Download and How to Use It”

What is an S-curve in project management?

It is a cumulative curve, and cumulative is the whole point. A bar chart of monthly spend tells you that April cost $96,000. A cumulative curve tells you that by the end of April you had committed 56% of the budget while claiming 53% of the work, which is a different and much more useful sentence.

The curve gets its name from the shape. At the start, a small team is mobilizing, contracts are being signed, and few deliverables exist, so cumulative spend and cumulative progress both rise slowly. In the middle, most of the labour and materials are consumed, and the slope is close to linear and steep. Near the end, the remaining work is testing, documentation, punch lists, and handover — activity continues but value accrues slowly, so the curve flattens.

That shape is not a convention invented for presentations. It falls out of how work is distributed: a project rarely has 25% of its effort in the first quarter of its timeline, and it rarely finishes with a burst of new construction in the last week.

There are three curves that get called “the S-curve” and they are not interchangeable:

Most project failures in reporting come from plotting the cost curve and calling it progress. They diverge routinely, and the divergence is the signal.

Why does the curve have that shape?

Because work is distributed unevenly across time, and because the last 10% of a project is disproportionately slow. Three mechanisms produce the shape.

The first is mobilization. Design, procurement, permitting, hiring, and setup consume calendar time without producing much measurable output. On a construction project this can be two to four months of a twenty-month schedule. On a software project it is discovery, architecture, and environment setup.

The second is parallel execution. In the middle phase, multiple workstreams run at once, so the rate of value creation is at its maximum. This is also where the curve is most nearly straight, which makes it the easiest part of the project to forecast and the part people mistakenly use to extrapolate the end date. A straight middle does not mean the tail will be straight.

The third is the integration tail. Testing, defect fixing, commissioning, training, and acceptance take longer than the plan usually admits, and they consume cost without moving percent-complete much. That is why real cost curves often keep climbing after the progress curve has flattened — the classic “cost keeps going, progress has stopped” pattern that precedes most overruns.

If you plot both on one chart, the shape itself becomes diagnostic. A progress curve that flattens in month five while the cost curve is still steep is a project in trouble, regardless of what the status report says.

How do you build an S-curve in six steps?

Build it from the bottom up, from costed work packages, never from a top-down percentage. A curve assembled by spreading the budget evenly across months is a straight line with extra steps, and it will be wrong in the two places that matter: the start and the end.

Step 1: fix the baseline. Take the approved cost baseline and the approved schedule. If the baseline is still moving, the curve is a forecast, not a control. Label it accordingly.

Step 2: break work into costed packages. Use the work breakdown structure. Each package needs a value and a time window. Packages shorter than one reporting period should be grouped.

Step 3: distribute each package across its periods. A four-month package does not spend 25% per month. Use a distribution that matches the work: front-loaded for procurement, back-loaded for testing, even for continuous labour.

Step 4: accumulate. Sum across packages for each period, then take a running total. The running total is the curve. The period values are the histogram underneath it.

Step 5: add earned value and actuals. Earned value is the budgeted value of completed work, not the cost of it. Actual cost comes from the ledger and lags by days or weeks, which is a permanent and underrated source of confusion.

Step 6: forecast the remainder. Extend the curve using the remaining work and the current efficiency, not the original plan. The forecast line should be visibly different from the baseline line; if it never is, you are drawing, not forecasting.

Two data-quality rules save months of argument. First, define percent complete by deliverable acceptance, not by hours burned. Second, post accruals before the curve is drawn; a curve built on unpaid invoices shows a project that is under budget right up until it is not.

What does a worked eight-period S-curve look like?

Here is a project with a budget at completion of $480,000 spread over eight monthly periods, with actuals reported through period six. The planned distribution is 6%, 12%, 18%, 20%, 18%, 12%, 9%, and 5% — slow, steep, tapering.

Notice what the first two periods look like: CPI of 0.84 and 0.87, which reads like a disaster. It is not. Early periods carry mobilization cost without proportional earned value, so almost every project is “over budget” in month one. Judging a project on a period-one index is the most common analytical error in project controls.

By period six the picture is stable and unflattering. Planned value is $412,800, earned value is $388,000, and actual cost is $418,000. Schedule variance is $388,000 − $412,800 = −$24,800. Cost variance is $388,000 − $418,000 = −$30,000. The project is about 6% behind plan and about 7% over budget, and both gaps have been widening slowly rather than jumping, which is the signature of a systemic efficiency problem rather than one bad event.

The forecast follows from the same numbers. Cost performance index is $388,000 ÷ $418,000 = 0.928. Estimate at completion is $480,000 ÷ 0.928 = $517,100, an overrun of $37,100. To finish on the original budget from here, the remaining $92,000 of work would have to be delivered for the $62,000 that is left, which requires a to-complete performance index of $92,000 ÷ $62,000 = 1.48. A TCPI of 1.48 in the final third of a project is not a plan; it is a wish.

That single ratio is the most useful output of the whole exercise. It converts a vague “we need to catch up” into a specific efficiency requirement that the team can accept or reject.

How do you read deviations from the curve?

Read the slope first, the gap second, and the combination third. Position tells you where you are; slope tells you where you are heading. A project $24,800 behind but closing the gap at 2% a month is in a different state from one $24,800 behind and diverging.

The fourth pattern is the one teams misread most often. A curve below the baseline in month two usually means the project started late, not that it is saving money. The money did not disappear; it moved to the right. Three months of delay on a $480,000 project shifts $57,600 of planned spend out of the visible window, which looks like discipline and is actually slippage.

A second reading habit: compare the cost curve’s slope to the progress curve’s slope at the same point. If cost is climbing at 4% of budget per month while progress climbs at 2.5%, the project is buying completion at a worsening rate. That relationship, not the absolute gap, predicts the final overrun.

The confidence band — often called the banana curve — adds the honest range. Plot the early and late cumulative curves for the same scope, and the space between them is your tolerance. A data point inside the band is noise; a data point outside it for two consecutive periods is a trend. Two periods is the cheapest filter available and the one most often skipped.

What does the cash-flow version of the curve tell you?

It tells you when you run out of money, which is a different question from whether the project is on budget. Cost curves are accrual-based; cash curves follow payment terms, retention, and advance payments, and the two can be months apart.

Take the same $480,000 project with monthly spend of $28,800, $57,600, $86,400, $96,000, $86,400, $57,600, $43,200, and $24,000. If the client pays 30 days after invoice, the contractor funds roughly one month of work at all times. Average monthly spend is $60,000, so the working-capital requirement is about $60,000. At a 9% annual cost of capital, carrying that for eight months costs $60,000 × 9% × (8 ÷ 12) = $3,600.

Now change one term. A 10% retention held until handover means an additional $48,000 is withheld across the project, and the effective carry rises to roughly $108,000 in the later months. The project is still “on budget” in the accounting sense and simultaneously short of cash — which is how profitable contractors fail.

This is why the cash S-curve belongs in the same deck as the cost S-curve. One answers “are we making money,” the other answers “can we pay Friday’s payroll.”

What are the trade-offs of managing by S-curve?

The curve is a lagging indicator dressed as a leading one. Everything on it happened already. Its value is in pattern recognition, not prediction, and teams that treat the forecast line as a promise tend to stop updating it.

It also rewards smoothness. A curve built from evenly distributed packages looks professional and hides the fact that two critical packages are back-loaded into the final month. Smooth is not the same as realistic, and a slightly lumpy curve that matches the actual work is a better control instrument than a beautiful one that does not.

There is a reporting cost too. Maintaining earned value properly takes time — measuring progress by deliverable, posting accruals, reconciling the ledger — and on a small project with six people and a three-month duration, the overhead can exceed the insight. The pragmatic threshold is roughly: below ten people and three months, use a burn-down chart and a milestone list; above it, and especially with external reporting obligations, the S-curve earns its keep.

Finally, the curve is only as honest as the percent-complete number behind it. If 90% complete is a feeling rather than an accepted-deliverable count, the entire right-hand side of the chart is fiction. Fixing measurement is worth more than improving the chart.

Which mistakes ruin an S-curve?

Spreading the budget evenly across periods is the first and most common. It produces a straight diagonal that cannot show mobilization or the integration tail, which are the two places problems appear.

Using percent spent as percent complete is the second. The two numbers are equal only when the project is exactly on budget, which is the case you least need a chart for.

Mixing baseline and forecast on the same line is the third. Once the baseline is overwritten, there is nothing left to compare against, and the project loses its ability to say “we are late” without an argument.

Forgetting accruals is the fourth. A curve built on paid invoices only lags reality by 30 to 60 days, which is precisely the window in which intervention is still cheap.

Plotting too many projects on one chart is the fifth. A portfolio S-curve is useful for cash planning and useless for control, because the deviations of individual projects cancel out and produce a smooth line that describes nothing.

How does Doitify support S-curve tracking?

Doitify is our product, so treat this section as disclosure rather than review. The workspace holds projects, tasks, sub-tasks, owners, due dates, and budgets, and the reporting layer can produce the two inputs the curve needs: planned value by period from the cost baseline, and percent complete from accepted work rather than from time logged. Gantt and roadmap views supply the time distribution; work and performance reports supply the accumulation.

The honest limitation is that Doitify is not a project-controls package. It will not compute earned value schedules, handle multi-currency accruals, or replace a cost engineer on a $200 million programme. What it does well is keep the underlying data — what was planned, what was accepted, what it cost — in one place so the curve can be rebuilt in minutes rather than assembled from four spreadsheets at month end. For teams below about 200 people, that is usually the difference between a monthly curve and no curve at all.

Conclusion

The S-curve is the cheapest way to see a project’s trajectory as a shape rather than a status colour. Build it from costed packages, accumulate honestly, plot baseline against earned value against actual cost, and read the slope before the gap.

Then use the two ratios it produces. Cost performance tells you what the project will cost if nothing changes; to-complete performance tells you what would have to change to hit the original number. Those two figures, updated every period, are worth more than any amount of narrative reporting — and they take about twenty minutes once the data is in one place.

If this post on s-curve in project management was helpful, you might also enjoy How to Manage Cross-Functional Teams: A Practical Guide and Free Project Schedule Template.