Your forecast is an email you're waiting on

It's the 24th. Your forecast is due to the board on the 28th, and right now it does not exist. It exists as a reply you're waiting on from a project engineer who is on site, has forty other things on, and last opened the program a fortnight ago.

So you send the email. Then the follow-up. Then you walk out to the site office and ask in person, because that's the only escalation that's ever worked. And what comes back three days later is a set of numbers built quickly, under pressure, by someone who is not being asked "what will this job cost?" They're being asked "can you get me something by Thursday?"

That's the forecast the business is about to make decisions on.

The forecast doesn't live where you can reach it

The forecast is downstream of the program. What's left to build, when it's happening, how it's resourced: that's all program. And the program lives in P6 or MS Project, on one licence, owned by one person, in a file that gets exported as a PDF once a month if you're lucky. None of which has anything to do with anyone's competence.

You are not short of a forecast because nobody has done the thinking. You're short of one because the thinking is locked in a tool you have no access to, in a format that can't answer a commercial question, held by someone whose actual job is delivery.

And scheduling tools are commercially blunt by design. They're brilliant at logic, float, and critical path. They are not built to tell you what the next three months cost you, against a live budget, at contracted rates. So even when you do get the file, it doesn't answer the question.

The rebuild tax

This is the part that grinds people down, and it's the part your engineer resents most: they have already done the work, and they have to do it again.

They know the job. They know the slab pour slips a week because the reo delivery is late. They know the crane's off-hire the following Friday. That knowledge is real and current. But converting it into a forecast means rebuilding it from scratch, every single month, against things the program doesn't hold:

1. The contracts. What rate is that subbie actually on? Is there a rise-and-fall clause? Did the variation get approved, and at what price?
2. The program activities. Which activities are genuinely left, at what percentage, and which ones have quietly been resequenced since the last update.
3. Actual availability. Not the planned resource, the real one. Is that plant free? Is the labour hire crew still on the job next month? Has the supplier confirmed the delivery date, or is that still a hope?

None of those three live in the scheduling tool. So the engineer opens a spreadsheet, pulls numbers out of three inboxes and a phone call, and hand-assembles a forecast that will be stale within a fortnight and thrown away entirely by the next cycle.

“

Everyone knows what's going to happen. Nobody can prove it in a number.

Do that twelve times a year and you have spent a genuinely serious amount of senior time producing a document nobody fully trusts.

The forecast changes based on who you engage

What makes this genuinely hard is that the forecast isn't a fixed quantity waiting to be measured. It moves depending on decisions that haven't been made yet.

Take one remaining package. Same scope, same program dates, three ways it could go:

Three different costs. Three different completion dates. Three different downstream effects on everything that follows. And the "right" answer depends on availability you have to go and confirm, from suppliers and subbies who haven't been asked yet.

So the honest version of the question isn't what will this job cost? It's what will this job cost, given who I engage, and what are they actually available to do? A single number in a spreadsheet cell can't hold that. Which is why the forecast you eventually get is one scenario, presented as a fact, with all the assumptions that produced it living in someone's head.

What a forecast actually needs

To produce a forecast that's worth acting on, four things have to be in the same place at the same time:

• The remaining scope. What's genuinely left, by activity, not a percentage someone eyeballed.
• The rates that apply to it. From the contracts you've actually signed, not last year's estimate.
• The dates it lands on. The live program, not the version exported in March.
• The resourcing reality. Who's doing it, and whether they're actually available.

Every one of those already exists somewhere in your business. Forecasting is painful because the information is scattered across a scheduling tool, a contract folder, an inbox, and a conversation, and re-assembling it is a manual job that falls on the one person who has the least time to do it.

Where tectm fits

tectm's answer is to stop treating the forecast as a document someone produces, and start treating it as a read off data that's already there.

• The program lives with the commercial data, not beside it. Activities, budget lines, and contracts sit in one model, so the schedule is something you open yourself rather than a PDF you're sent. No licence, no export, no email.
• Activities carry their real committed scope and rates. When subcontract award items and Schedule-of-Rates contracts are linked to the activities that deliver them, the remaining cost stops being an extrapolation and becomes arithmetic. We walked through exactly how that linkage works in the cost-loaded programs piece, which is the mechanism underneath this.
• Progress updates itself from what's already being captured. Dockets and diary entries are recorded daily against cost codes and activities anyway. That's your percentage complete, captured as the work happens rather than reconstructed at month-end.
• The resourcing falls out of the plan. Once activities carry their labour and plant lines, you get a demand profile off the program: how many crews and how much plant each working day, before anyone has to work it out by hand. That's the question you were emailing about, answered as a read.
• Scenarios instead of a single number. Because the rates and the plan sit as data rather than assumptions in someone's head, "what if we engage the other subbie" becomes a question you can answer yourself, in the moment, without a three-day round trip.

What tectm won't tell you is whether that subbie is actually free in March. Availability is a phone call, and it should be. But it's a much shorter phone call when you already know exactly what you need, on exactly which days, at the rate you've contracted.

The engineer still knows the job better than anyone, and that shouldn't change. What changes is that their knowledge goes in once, as they work, instead of being extracted under duress on the 24th of every month.

The forecast stops being something you chase. It's just there, and it's current, because it was never assembled in the first place.

Book a demo to see what your forecast looks like when it's a live read instead of a monthly rebuild.