Pick your granularity first. More granular = more accurate, but more effort. Match it to the decision you’re trying to support.
Forecast from business demand, not from last month’s bill. Past usage is a weak predictor; business plans are a strong one.
Forecasts get better by iterating. Run a monthly post-mortem on last cycle’s variance. Adjust. Repeat.
Aggregate bottom-up. Team/app forecasts roll up to the total — not the other way around.

Why most forecasts are bad

Forecasting is the FinOps task nobody wants. Allocation is tedious but mechanical. Optimisation has obvious wins. Forecasting has neither — it’s judgement-heavy, the feedback loop is slow, and everyone who looks at the number assumes it’s either pessimistic or optimistic depending on which way they wanted it to lean.

I spent a long time looking for a clean runbook on how to actually do it. The FinOps community is full of articles explaining what a forecast should look like — accurate within some tolerance, updated on some cadence, aligned to the business. All true. None of it tells you where to start on Monday morning.

This article is what I’ve learned doing it with customers. Not theory, not a framework — just the practical sequence.

Pick where you forecast before you forecast

The first decision is granularity.

The general rule: the more granular the forecast, the more accurate it ends up — but the effort grows in step. A top-down forecast for the whole company takes one meeting. A per-application forecast takes twenty.

        Granularity                      Effort    Accuracy
        ──────────────────────────       ──────    ────────

        Organisation-wide                Low       Low
        └── Business Unit                │         │
            └── Team                     │         │
                └── Application          High      High
                    └── Service / SKU

Top-down is fast but blind to local reality. If you forecast the whole company by extrapolating last quarter, you miss the two new products launching in Q3 and the migration retiring in Q4. Bottom-up is slow but honest — the person forecasting the application actually knows what’s being built.

My default recommendation is to start at the team or application level and roll up. That is where the business context lives. A central FinOps team can aggregate, but it cannot meaningfully forecast an application it does not own.

If your organisation is small enough that the whole cloud fits in one person’s head, a top-down forecast at the BU level is fine. Everyone else: start bottom-up.

Forecast from business demand, not from the bill

The second — and more important — decision is what drives the forecast.

A forecast based on last month’s bill plus a trend line will tell you what cloud spend would look like if nothing changes. That is almost never the actual question. The actual question is: given the business plans, what will cloud spend be?

Two ways to turn business demand into a cost number.

Option 1 — Resource-based estimation.

Translate the business demand into the cloud resources it will consume, then price those resources.

“We expect to ingest 3× more events next quarter. That means roughly 3× the Kafka capacity, 2× the storage, and 1.5× the downstream compute.”

Then plug those numbers into a cloud calculator. Quick, rough, and you need some engineering input to translate demand into infrastructure. Good for new workloads, rough architectural shifts, or anything where unit economics don’t exist yet.

Option 2 — Unit-economics multiplication.

If you already know your cost-per-unit (cost per user, per transaction, per GB of data, per API call), the forecast is just a multiplication.

Cost per subscription = $0.30/month. Expected new subscriptions next quarter = 1,000. Additional forecast = $300/month.

This is much more precise, but it requires two preconditions:

You have calculated unit economics for your workloads.
The business owners can give you forward-looking unit counts.

When both are true, use it. Unit-economics forecasts are the closest thing FinOps has to a reliable prediction.

 Business demand     ──►    Cost model            ──►    Forecast
 (from product/biz)         (resource or unit)           (by team/app)

 "+1,000 subscribers"       Unit: $0.30/user/mo          +$300/month
 "+3× events"               Resource: +$X Kafka          +$X/month
 "New ML feature"           Resource: +$Y GPUs           +$Y/month

Notice what is not in this diagram: historical cost data. History is useful for validating the forecast after the fact. It is not where the forecast comes from.

Tweak precision iteratively

A first forecast will be wrong. A second forecast will still be wrong, just less. That is not a failure — that is how forecasting works in every industry. The machinery that makes it eventually correct is the monthly cycle.

Once a month, sit down with:

The FinOps practitioner
Engineering / application leads
Business owners for each forecasted area

Review the previous cycle’s variance: where the forecast was off, and why. Was the demand wrong? Was the cost-per-unit wrong? Did something unexpected land (a new compliance requirement, a spike, a pricing change)? This is a post-mortem on the forecast itself.

Over three or four cycles, the forecasters learn where their blind spots are — which teams over-estimate, which under-estimate, which services are consistently mis-modelled — and the accuracy climbs. You are not trying to get the forecast right in one shot. You are trying to make the forecasting process converge on correct.

One practical knob: apply a variance threshold to the forecast (e.g., ±5%) to absorb noise and anomalies. If actuals fall inside the threshold, the forecast was “correct enough.” If they fall outside, that’s the trigger for the post-mortem. This stops the process from churning on every small wobble.

Aggregate the bottom-up forecasts

By now the FinOps practitioner has a pile of forecast reports from teams and applications. The final step is to consolidate them into a single organisational forecast.

This is more than a sum. Three things happen in the aggregation:

Reconcile overlaps. Some initiatives span multiple teams. Make sure the cost is counted once, not twice.
Apply shared and allocated costs. RIs, Savings Plans, support contracts, cross-team infrastructure. These don’t fit neatly into any single team forecast — FinOps owns spreading them.
Feed into the financial system. The aggregated forecast becomes the input to the actual budget cycle. That usually means integration with the internal FP&A tool, SAP, Oracle, or whatever the finance team runs.

The aggregated forecast is then the baseline for next year’s cloud IT budget. Which closes the loop: the forecast feeds the budget, the budget gets tracked against actuals, variance feeds back into the next forecasting cycle.

A common mistake worth calling out

I’ve seen organisations spend weeks building an elaborate forecasting model, then never update it. They treat the forecast as a deliverable — build it once, present it, done.

That is not forecasting. That is a prediction made once. A prediction you never revisit is indistinguishable from a guess.

The process only becomes forecasting when the cycle runs — monthly, quarterly, every planning window. The first forecast is always wrong. The tenth one, if you’ve been iterating honestly, is usually pretty good.

Summary

Decide granularity first. Start at team or application level unless you have a reason not to.
Drive the forecast from business demand, not from historical cost. Use unit economics if you have them; use resource-based estimation if you don’t.
The forecast is a process, not a document. Run a monthly variance review. Improve iteratively.
Aggregate bottom-up into one organisational forecast, reconcile overlaps, add shared costs, and feed it into the budget cycle.

Thanks for reading. If this helped, share it. Questions or topic suggestions — send them through.