Cost-loaded programs — tying the schedule to the margin

The critical path slipped two weeks ago. Your scheduler knows — it's right there in the program, a red bar that moved. Your commercial manager doesn't know, because the cost of that slip won't show up in the cost report until the under-resourced weeks get claimed, a month from now. So for the next four weeks two people in the same business are looking at the same problem and only one of them can see it costs money.

That's the gap a cost-loaded program closes: it puts the schedule and the cost on one spine, so a delay stops being a picture of a red bar and becomes a dollar figure the day it happens.

Two tools, reconciled by hand

Most teams run the program in one tool — P6, MS Project, a wall of bars — and the cost in another, a cost report in a spreadsheet or a finance system. They live separate lives all month, and then someone spends the back half of every month-end stitching them together: mapping schedule activities to cost codes, working out what should have been spent by now, arguing about why it wasn't.

That reconciliation is manual, late, and exactly where delays turn into surprises. By the time the two pictures meet, the delay they were both describing is six weeks old.

What cost-loading actually means

Cost-loading is simple to state: you attach each budget line to the schedule activity that will spend it. Do that across the program and the cost gets distributed across time — it's no longer a lump sum, it's a curve of what should be spent by when.

That time-phased curve is your planned value baseline. Different activities spend differently — a mobilisation front-loads, a fit-out back-loads, a steady trade runs linear — so each line gets the curve shape that matches how it actually spends. Add them up and you have one baseline: the money the program says you should have spent by any given date.

But a budgeted value smeared across a bar is still a guess. It draws a nice S-curve, but the number underneath it isn't tied to anything real — so the forecast it produces can only ever be as good as the estimate someone typed in. The foundation that makes the forecast trustworthy is linking the actual committed scope to the activity, not just a value.

The foundation — linking committed scope to the activity

This is the part most cost-loading skips, and it's the part that makes forecasting real:

• Subcontract award items — the promised works. When you award a subcontract package, every item in it is a defined piece of work at an agreed price. Link those award items to the program activities that deliver them, and the planned value stops being a smeared lump — it's the real, committed scope sitting on the date it's due to happen. The baseline is now built from what you've actually contracted, not what you guessed at tender.
• SOR contract rates, as the activity approaches. Closer to execution, link the project's Schedule-of-Rates labour and plant contracts to the specific activity being carried out. Now the activity doesn't just carry a value — it carries the rates that will actually be charged against it, on the resources that will actually do the work.

Earned value in plain English

Once cost lives on the schedule, three numbers fall out, and they're the whole of earned-value management:

• Planned Value (PV) — what you budgeted to have done by now.
• Earned Value (EV) — the budgeted cost of the work you've actually done.
• Actual Cost (AC) — what that work actually cost you.

From those three, two indices tell you everything:

Standard earned-value formulas — the numbers in any worked example are illustrative.

An SPI of 0.9 means you've done 90% of the work you planned to by now. A CPI of 0.9 means every dollar of work is costing you $1.11. Two numbers, and you know whether the job is late, over, both, or fine.

Forecast at complete — built up, then performance-checked

Here's where the committed-scope foundation earns its keep. Because each activity carries its real award items and SOR rates, the forecast can be built up from what's actually contracted to happen — not extrapolated from a single project-wide percentage. The remaining work has a price because the scope and the rates behind it are already known.

Earned-value performance then sits on top as the reality check. Your estimate at completion can ride on your CPI — the simplest version is the budget at completion divided by it, so if you're running at 0.9, the job trends 11% over unless something changes. Where the resourced build-up and the CPI trend disagree, that gap is the conversation worth having.

It's a floor, not a prophecy — you can override it where you know something the maths doesn't, a problem trade nearly off site or a productivity gain coming. But between the committed scope underneath and the performance trend on top, the forecast stops being a hopeful number someone typed in.

“

When cost and time live on one model, a critical-path delay shows up as a margin signal the day it happens — not two months later when the costs catch up.

How the site diary closes the loop

Earned value is only real if the progress is real. Planned value comes from the baseline; earned value comes from what's actually been done — and that has to be recorded against activities, not assumed.

That's the job of the site diary: progress logged against the same activities the cost is loaded onto. Record real progress and earned value is grounded in fact. Skip it and EVM is just a tidy way of presenting guesses.

Why a delay becomes a dollar number

Put it together and the scenario from the top of this piece resolves differently. The critical-path slip doesn't wait a month to surface as an under-claimed cost report. Because cost rides on the schedule, the moment the program slips, planned value and earned value diverge, SPI drops below 1.0, and the forecast at completion moves — all on the day the bar moved. The commercial manager and the scheduler are finally looking at the same number.

This is the same live-margin discipline from the margin piece, extended onto the time axis: not just what the job is making, but when the schedule says it'll make it — and what slippage costs.

Where tectm fits

tectm puts the money and the time on one model:

• Budget lines cost-load onto program activities, distributed as planned value with the curve shape that fits how each line spends.
• Subcontract award items link to the activities that deliver them, so the baseline is built from committed scope sitting on its due date — not a value guessed at tender.
• Project SOR labour and plant rates attach to the specific activity being carried out, so as an activity approaches, it carries the rates that will actually be charged against it.
• Earned value is computed from real diary progress, so SPI, CPI, and the forecast at complete are grounded, not assumed.
• A critical-path delay surfaces as a margin signal immediately — the program stops being a picture and becomes a financial control.

A delay you can see the day it happens is a delay you can still recover. One you find at month-end is just a worse number.

Book a demo and bring a real program. We'll put your schedule and your cost on one spine and let you watch a delay become a number.