Predictive forecasting means a project’s Estimate to Complete updates itself from real cost and schedule activity — not that an algorithm is guessing at the future. The prediction isn’t mystical; it’s a formula tied to live data instead of a model someone rebuilds by hand once a month.
That distinction matters, because most organizations already have a forecast. What they don’t have is a forecast that reflects what’s happening right now. Actuals arrive continuously — timesheets, approved vendor invoices, cost postings. But the number a budget owner actually looks at often only gets refreshed when someone has time to pull data from three systems and rebuild a spreadsheet. That lag is where capital overruns hide.
This guide covers what predictive forecasting actually requires, what a stale forecast really costs an organization, and the questions to ask before choosing a platform to manage it.
In This Guide:
→ Why Forecasts Go Stale → What Predictive Forecasting Actually Requires → The Real Cost of a Stale Forecast → Questions to Ask During a Forecasting Software Evaluation → How PACE Approaches Predictive Forecasting, End to End → Frequently Asked Questions (FAQs)
Why Forecasts Go Stale
A forecast is supposed to answer one question: what is this project actually going to cost by the time it’s done? Answering that well requires pulling together the original budget, everything spent and committed so far, physical progress, and what’s genuinely left to do.
In most organizations, that information lives in different places. Actuals post in the ERP. Timesheets sit in a labor system. Vendor invoices get approved somewhere else entirely. Someone — usually a project controls analyst — has to gather all of it, reconcile it by hand, and rebuild the forecast model before anyone can trust the number.
That process takes time. And every day it takes is a day the forecast is describing a project that has already moved on. By the time the updated number reaches a steering committee, new costs have already been incurred against a budget that was sized using the old one.
This isn’t a discipline problem — most project controls teams update forecasts as often as the process allows. It’s an architecture problem: when the forecast isn’t wired directly into the data generating it, someone has to manually close the gap every single cycle.
The consequences go beyond a single missed number. Contingency reserves get sized against a forecast that’s already wrong. Resources get reallocated based on a completion date that’s already shifted. And when the real overrun does surface — usually at a steering committee meeting, not before it — it damages the project controls team’s credibility more than the overrun itself does. Leadership stops trusting the forecast, which means every future number gets second-guessed and re-verified manually, adding even more delay to a process that was already too slow.
What Predictive Forecasting Actually Requires
Six capabilities separate a forecast that updates itself from a spreadsheet that gets rebuilt on a schedule.
1. A Forecast Formula Tied to Real Actuals, Not a Static Model
The underlying calculation should be simple and explicit, and it should recalculate the moment new actual cost data lands — not the next time someone happens to open the model.
- Is the formula behind the forecast documented and transparent, or is it a black box the vendor won’t walk through?
- Does the number change automatically when new actual cost posts, or does someone have to manually trigger a recalculation?
Inside PACE: Estimate to Complete in PACE is calculated as Proposed Cost minus Actual Cost — a documented, explicit formula, not a black box. It recalculates automatically every time “Refresh Actuals” runs, pulling directly from timecards, approved timesheets, and processed vendor invoices.
2. An Enforced Refresh Cadence
A forecasting engine is only predictive if actuals are pulled in on a cadence the system enforces, not one that depends on someone remembering to run a refresh.
- Is there a maximum interval the system allows a forecast to go without a refresh, or can it sit untouched indefinitely?
- Does the platform surface which projects are overdue for a refresh, or does staleness stay invisible until someone asks?
Inside PACE: PACE enforces a mandatory refresh of actuals every two to three weeks — a forecast simply cannot sit untouched for a full reporting quarter without someone being required to act on it. That cadence is a system rule, not a team habit that erodes under deadline pressure.
3. Automatic Rate Cascades
When corporate labor or burden rates change, that change needs to flow through every open forecast line automatically — including revenue where margin is derived from bill rates.
- When a corporate rate table updates, does every affected forecast line update with it, or does someone have to re-key rates project by project?
- Does the cascade reach revenue calculations where margin depends on bill rates, or only the cost side?
Inside PACE: Refresh Cost Rates and Refresh Burden Rates recalculate cost and overhead automatically from the current corporate rate tables and cascade the change through every dependent line — including revenue where margin is derived from bill rates or a fixed markup. A rate change that would take a week to re-key manually across a portfolio applies in a single action.
4. Isolated Scenario Testing
Project controls teams need to model “what if” — a schedule slip, a change order, a resourcing shift — without putting the live, approved forecast at risk while they test it.
- Can a scenario be modeled in a separate, isolated version, or does testing it mean editing the live number leadership is looking at?
- If the scenario works, can it be promoted cleanly to become the official forecast?
Inside PACE: A New Forecast Version creates an isolated working copy for scenario testing, completely separate from the current working forecast. If the trial holds up, it gets promoted to the Current Working Version. Nothing about testing a scenario touches the number anyone else is currently viewing.
5. A Locked Baseline to Forecast Against
A forecast is only meaningful if it’s being compared against something fixed. Once a project is approved, the baseline budget should freeze — so the forecast is measured against a stable reference point, not a moving target that quietly shifts along with it.
- Does project approval actually lock the baseline, or can planning assumptions still be edited afterward?
- If a forecast scenario goes wrong, is there an instant way back to the last approved baseline?
Inside PACE: Project approval in PACE automatically freezes the Current Working Budget into a fixed baseline layer and creates a new working version for ongoing tracking — planning levels (cost, revenue, resource) become permanently non-modifiable at that point. If a working forecast needs to be undone, Revert to Current EAC overwrites it instantly with the last approved baseline — no manual reconstruction.
6. A Direct Line Back to Funding Decisions
Forecasting shouldn’t dead-end in a report. A rising Estimate to Complete should be visible to whoever is managing the funding envelope for that program — not discovered three weeks later when someone happens to compare two spreadsheets.
- Does a rising forecast surface automatically to the people managing that program’s funding, or does it stay buried in a project-level report?
- Is the connection between forecast and funding built into the platform, or does it depend on someone manually forwarding a spreadsheet?
Inside PACE: Because forecasting and funding governance live in the same platform, a rising Estimate to Complete on a capital project is visible in the same environment where Planning Portfolio and Organization Budget decisions get made — it doesn’t require a separate report to reach the people managing the funding envelope.
The Real Cost of a Stale Forecast
Consider a $12M capital project four months into execution. The last forecast update — built six weeks ago — showed Estimate to Complete at $2.1M, putting the full Estimate at Completion at $9.8M: comfortably under the approved budget.
In the six weeks since that update, the project logged $650,000 of change-order-driven actual cost that never made it into the model, and a supplier price increase raised planned unit costs by roughly 8% on the remaining scope.
Refresh the actuals and recalculate: Estimate to Complete rises to $2.9M, and Estimate at Completion moves to $10.6M.
- Previous forecast: $9.8M EAC — appeared under budget
- Refreshed forecast: $10.6M EAC — reflects six weeks of real cost and pricing activity
- Gap: $800K that was already true, just not yet visible
The project didn’t get worse in six weeks. The forecast simply caught up to what was already happening. That $800,000 gap wasn’t a forecasting error — it was the cost of forecasting on a six-week lag, and it’s exactly the kind of gap that shows up as a surprise overrun in a steering committee meeting rather than a manageable variance caught weeks earlier.
Now multiply that lag across a portfolio. A capital program office overseeing 25 active projects, each forecasting on its own three-to-six-week cadence, isn’t looking at one $800,000 gap — it’s looking at a portfolio-level number that’s wrong by an unknown amount at any given moment, because every project is stale on a different schedule. Leadership ends up making funding decisions for the whole program based on a number that’s never actually current for all 25 projects at once. An enforced, uniform refresh cadence doesn’t just fix one project’s forecast — it’s what makes the portfolio-level number trustworthy in the first place.
What Changes Once Forecasting Actually Becomes Predictive
The difference isn’t just fewer spreadsheets. It shows up in how decisions actually get made:
- Funding conversations start from current consumption instead of a model that was accurate three weeks ago.
- A project controls analyst spends their time reviewing what changed and why, instead of reconstructing the forecast from scratch.
- A rising Estimate to Complete surfaces while there’s still budget and schedule flexibility to respond to it — not after the funding envelope is already exhausted.
- Leadership stops treating the forecast as a once-a-month event and starts treating it as a number they can check in on at any point in the cycle.
- Scenario testing — what happens if this change order is approved, what happens if this milestone slips — becomes routine instead of a special exercise that requires rebuilding the model from scratch.
None of this requires a bigger team or a more complex process. It requires a forecast that’s structurally tied to the data generating it, instead of one that’s reassembled by hand on a schedule.
Questions to Ask During a Forecasting Software Evaluation
- Ask what triggers an Estimate to Complete recalculation — a manual entry, or a refresh from timesheets and invoices?
- Ask the maximum time a forecast can go unrefreshed before someone is required to update it.
- Ask to see cost and burden rates change mid-project. Does the update cascade automatically, or does someone re-key every affected line?
- Ask how a what-if scenario is tested without changing the number leadership is currently looking at.
- Ask what happens if a scenario needs to be undone — is there an instant rollback, or a manual rebuild from scratch?
- Ask whether the approved budget baseline is actually locked after project approval, or whether planning assumptions can quietly shift.
- Ask how a rising forecast connects back to available funding at the portfolio level — automatically, or through a separate manual check.
How PACE Approaches Predictive Forecasting, End to End
The six “Inside PACE” notes above aren’t six separate features bolted together — they’re one forecasting engine, built so that no part of the number depends on someone remembering to update it. The formula is explicit and automatic. The refresh cadence is enforced, not optional. Rate changes cascade instead of requiring manual re-entry. Scenarios stay isolated until they’re proven. The baseline locks so there’s always a fixed point of comparison. And the forecast connects directly to the funding decisions it’s supposed to inform.
The result is a forecast that behaves less like a monthly report and more like a live instrument: something a controller or program director can check at any point in the cycle and trust that it reflects what’s actually happening on the project — not what was happening three weeks ago.
Frequently Asked Questions (FAQs)
Is predictive forecasting the same as AI forecasting?
No. Predictive forecasting, in this context, means the forecast recalculates automatically from real cost and schedule data on an enforced cadence. AI can add value on top of that — flagging unusual trends or summarizing variance drivers — but it only works well when it’s operating on current, connected data. An AI layer over a fragmented, manually updated forecast is still limited by that fragmentation.
How often should a capital project forecast actually be refreshed?
It depends on project size and volatility, but a cadence of every two to three weeks is a reasonable enterprise standard — frequent enough to catch meaningful deviations before they compound, without creating unnecessary administrative overhead.
Does predictive forecasting replace the project controls team?
No. It removes the manual work of reconstructing the forecast from scratch each cycle, which frees the project controls team to spend their time analyzing what the forecast is showing and deciding what to do about it — rather than assembling the number in the first place.
What’s the difference between EAC and ETC?
Estimate to Complete (ETC) is the projected cost of the remaining work. Estimate at Completion (EAC) is the total projected cost of the project — actual cost to date plus ETC. A predictive forecasting engine should calculate both automatically as new actuals arrive.
Can we test a scenario without risking the official forecast?
Yes, if the platform supports isolated scenario versions. The scenario should be modeled separately from the current working forecast, and only promoted to become the official number if it holds up under review — with the ability to roll back instantly if it doesn’t.
Does this require a formal Earned Value Management program?
No. Organizations without a formal EVM program still benefit from connecting approved budget, actual cost, physical progress, and forecast in one place. Formal EVM metrics can be layered on top for organizations that require them, but the underlying need for a live, accurate ETC doesn’t depend on running a formal program.
What happens to funding decisions once forecasting is predictive?
A predictive forecast should connect back to the funding side of the program, not sit in an isolated reporting module. When a project’s Estimate to Complete rises, that change should be visible to whoever manages the funding envelope for that program — so a request for additional funding, or a decision to reallocate from another project, is grounded in the current number rather than a forecast that’s already several weeks old by the time the funding conversation happens.
