Page 6 of 7 · Worked example · a maturity journey, not a metric
Getting to Walk-level Forecasting
Your forecasts are spreadsheets and gut feel. You want them to be something Finance can budget against. This page walks the journey the way the two MCP servers actually answer it: the official Forecasting maturity text tells you where you are and what the next level requires, the framework's own prose names the capabilities that feed it, the KPI library gives you the formulas, and the FOCUS™ server tells you which billing columns carry the numbers — at whichever spec version your export speaks.
Crawl / Walk / Run are the three official FinOps maturity levels — there are no others. The variance figures are the official maturity model's own sample goals, verbatim: “Forecast spend to actual spend accuracy variance is below 20%” (Crawl), “Forecast spend to actual spend accuracy variance is less than 10%” (Walk), “Forecast spend to actual spend accuracy variance is less than 5%” (Run). official
framework · get_maturity_model {}
Where you are official · verbatim
Ask the framework server for the capability's official assessment and it hands back the Foundation's own characteristics, unedited. If most of the Crawl list describes your organisation, that is your honest starting point:
Forecasting @ crawl
official- In organizations with simple implementation models or with limited technology spend, a limited variety of cost data-sources and tools are used for forecasting by stakeholders across the organization
- Forecast models are created manually and/or ad-hoc
- Forecast are primarily based on historical spending, as workloads tend to be more stable or simple
- Forecasting variance analysis is done manually
- Limited/aggregate forecasting visibility (only by business unit or cost center)
- Engineering/Operations teams are not involved with the creation of cost forecasts or tracking of discrepancies from forecasted spend
And here is what the capability is, in the Foundation's words — worth re-reading before you start, because it is a statement about stakeholders as much as about maths:
Forecasting sits in the quantify-business-value domain, alongside Budgeting, KPIs & Benchmarking, Planning & Estimating and Unit Economics — five capabilities in that domain.
framework · get_maturity_assessment {capability: "forecasting"} · get_capability {capability: "forecasting", include: ["summary","definition","kpis","headline_groups"]} · list_capabilities {domain: "quantify-business-value"}
What Walk requires official · verbatim
The gap tool answers the only question that matters next: what changes between here and there? Asked for crawl → walk, the server returns exactly one level of official assessment text — “Official assessment text at each level above crawl up to walk.” Seven characteristics; treat them as the acceptance criteria for the whole programme:
Forecasting @ walk
official- Forecast costs tracked against actual usage and used to establish budgets
- Forecast is inclusive of rate optimization and commitment-based discounts
- Forecast models are rolling and trend-based
- Forecast updates are done on a regular cadence but not automated
- Stakeholder teams (Product, Leadership, Engineering, Finance) have access to cloud cost forecasting data
- Cost forecast data is used to supplement back-end accounting system data
- Regular review cadence by FinOps team of forecast thresholds and trends with stakeholder teams
Read the two lists side by side and the shape of the work is obvious from the official text alone, with nothing invented: manual and ad-hoc becomes a regular cadence; history-only becomes rolling and trend-based inclusive of discounts; “Engineering/Operations teams are not involved” becomes Product, Leadership, Engineering and Finance all having access; and forecasts stop being an artefact and start establishing budgets.
Note what Walk does not ask for. Automation is explicitly out of scope — “Forecast updates are done on a regular cadence but not automated.” So is granularity: the official Run text is where “Granular forecasting visibility (by business unit, cost center, team, product, service, etc …)”, driver-based models and “Integration and automated data flow between technology cost forecast data and back-end accounting systems” appear. Do not buy Run tooling for a Walk problem.
framework · assess_maturity_path {capability: "forecasting", current_level: "crawl", target_level: "walk"} · get_maturity_assessment {capability: "forecasting"}
What the framework itself says feeds forecasting official quotes
Forecasting is not a standalone exercise, and you do not have to guess which other capabilities it leans on — the served capability text names them. The Foundation states the dependency directly:
Below, each row pairs the verbatim sentence from the live server that raises the dependency with the capability's own official one-line summary. Resolving a phrase such as “Anomalies” to the capability slug anomaly-management is this guide's reading, not a link the server publishes — that column carries the derived flag.
| Verbatim from the Forecasting text | Where | Capability reading |
|---|---|---|
| “Forecasts are usually based on Estimating, which looks at a combination of historical spending and evaluates future plans…” | definition | Planning & Estimating “Estimation and exploration of potential cost and value, alongside opportunities for automation, sustainability and optimization, for workloads if implemented in an organization’s technology environment in a particular model or models.” |
| “Forecast models provide an input to the Budgeting capability, where they serve as the baseline for Finance allocating funding.” | definition | Budgeting “Strategic and ongoing process for setting limits, monitoring, and managing technology spending, aligned with business objectives, to ensure accountability and predictable financial outcomes for IT systems.” |
| “…a foundational element of this capability is the ability to fully categorize and allocate technology costs.” | definition | Allocation “Define strategies to assign and share cost and usage using accounts, tags, labels, and other metadata, creating accountability among teams and projects within an organization.” |
| “…allows for not only effective Budgeting, but also better management of Anomalies, better decision making related to on-premises capital spending…” | definition | Anomaly Management “Detect, identify, alert and manage unexpected or unforecasted technology cost and usage irregularities in a timely manner to lower risk and ensure cost-effective operations.” |
| “Forecast is inclusive of rate optimization and commitment-based discounts” | walk assessment | Rate Optimization “Driving rate efficiency through a combination of strategic vendor use, negotiated discounts, commitment discounts, and other pricing mechanisms to meet the organization’s strategic, operational and budgetary objectives.” — the subject of page 5. |
| “Forecast is inclusive of usage optimization opportunities” | run assessment | Usage Optimization “Analyze and optimize technology resources to match specific usage patterns while ensuring that workloads operate efficiently and generate sufficient business value for their cost.” — a Run-level concern, listed here only so you know it is coming. |
One more relationship is worth calling out because it is not stated in the Forecasting prose: Unit Economics. The server links the two through data, not text — the KPI time-to-achieve-business-value is featured on the Unit Economics page while listing forecasting among its officially related capabilities, and both capabilities sit in the same quantify-business-value domain. Unit Economics is what turns a spend forecast into a forecast anyone outside Finance can argue with:
framework · get_capability {capability: "planning-estimating" | "budgeting" | "allocation" | "anomaly-management" | "rate-optimization" | "usage-optimization" | "unit-economics", include: ["summary"]} · get_kpis {capability: "forecasting", limit: 100}
What to instrument official formulas
Walk asks you to track forecast against actual on a cadence — so you need a number for “how wrong were we.” Four KPIs are featured on the Forecasting capability's own page; every formula below is the Foundation's, verbatim.
Forecast Accuracy Rate (Spend) featured
Official data sources: CSP Billing Data · Organizational forecast documents. This is the KPI the maturity model's “variance less than 10%” Walk goal is about.
Forecast Accuracy Rate (Usage) featured
Official data sources: CSP Billing Data · Organizational forecast documents.
Forecast Drift Rate featured
Compares two of your own forecasts rather than forecast to actual — the metric for “are our rolling models settling down?”, which is precisely the Walk transition from ad-hoc to rolling.
Forecast Accuracy Rate for Carbon Emissions featured
Featured on both Forecasting and Sustainability; officially related to intersecting-disciplines and sustainability. Official data sources: CSP Billing Data, carbon emission data source, Organizational forecast documents.
framework · get_kpis {capability: "forecasting", featured_only: true} → total 4
Unit Economics KPIs — the denominators that make a forecast defensible
A spend forecast that only says “we will spend more” loses every budget argument. The five KPIs featured on the Unit Economics capability page give you the per-unit view; formulas verbatim.
| KPI | Official formula | Also related to |
|---|---|---|
| Cost per Gigabytes Stored | Cloud Storage Costs / Number of GB stored | unit-economics |
| Cost per API Call | Cost Per API Call = Total API Costs / Number of API Calls | reporting-analytics, unit-economics |
| Value for AI Initiatives | Return On Investment = (Financial Benefits – Costs) / Costs * 100 | kpis-benchmarking, reporting-analytics, unit-economics |
| Time to Achieve Business Value | Time to Value (days) = Total Value associated with AI Service / daily Cost of Alternative solution | forecasting, planning-estimating, reporting-analytics, unit-economics |
| Data Value Density | Data Value Density = Total Business Revenue or Value Index / Total Data Platform TCO | licensing-saas, rate-optimization, unit-economics, usage-optimization |
Only Time to Achieve Business Value officially lists forecasting among its related capabilities — that single record is the served link between the two capabilities. The other four are Unit Economics KPIs you can forecast against; treating them as forecast inputs is a practitioner choice, not published guidance. reading
framework · get_kpis {capability: "unit-economics", featured_only: true} → total 5 · get_capability {capability: "unit-economics", include: ["summary","definition"]}
What data feeds it UNOFFICIAL mapping
Now switch servers. The FOCUS server serves two pinned spec versions — 1.0 (43 columns) and 1.2 (57 columns, the latest) — and it will tell you, per version, exactly which columns carry the “actual” side of each forecasting KPI. It is careful about what it cannot do:
That is the single most important fact on this page. No FOCUS column holds a forecast. Your billing export gives you the actuals with rigorous, normative semantics; the forecast has to come from your own model, and the join between them is yours to build.
The mapped formulas, in FOCUS terms
Asked for the Forecasting capability at 1.2, the server returns three KPI mappings — each one derived by this project, each flagged official: false:
That third one is Consumption versus Commitment, and it is on this page for a reason: Walk explicitly requires that the “Forecast is inclusive of rate optimization and commitment-based discounts,” and this is the KPI the mapping offers for it — officially related to forecasting among others, though featured on the Rate Optimization page. Its caveat: “Uses spend as a proxy for committed/consumed units at FOCUS 1.0, which has no dedicated committed-quantity column; FOCUS 1.2 adds CommitmentDiscountQuantity/CommitmentDiscountUnit, which a quantity-based ratio should prefer instead.”
focus · get_kpi_mapping {capability: "forecasting", version: "1.0"} → 3 · get_kpi_mapping {capability: "forecasting", version: "1.2"} → 3 · get_kpi_mapping {kpi: "forecast-accuracy-rate-usage"}
The columns, per version
Every row below is a live get_column result. “In the mapping” marks the columns the server's own KPI mapping names for a forecasting KPI; the “why” text is this guide's reading of the served definition. UNOFFICIAL · reading
| Column | Why a forecast pipeline reads it | Type | Feature level | Introduced | Normative reqs | In the mapping |
|---|
focus · list_versions {} · get_column {column, version} × 22 columns × both versions · compare_versions {} · compare_versions {column}
What upgrading to 1.2 actually buys a forecaster
The whole-spec diff is 14 added, 0 removed, 43 changed — and the server refuses to let you read “changed” as “semantic” without checking: “Per the upstream CHANGELOG, most changes are not material unless specifically called out.” Every column in the table above that exists in 1.0 is still there in 1.2 under the same ID, so a 1.0 forecasting pipeline keeps running. Four of the fourteen additions are the ones that matter here:
- CommitmentDiscountQuantity + CommitmentDiscountUnit (Metric / Dimension, both Conditional, introduced 1.1) — turn the commitment ratio Walk asks for from a spend proxy into a real quantity ratio.
- ServiceSubcategory (Dimension, Recommended, introduced 1.1) — “Secondary classification of the Service Category for a service based on its core function.” The Forecast Accuracy (Usage) KPI text explicitly mentions forecasting by serviceSubCategory; at 1.0 there is no such column to group by.
- SkuMeter (Dimension, Conditional, introduced 1.1) — “Describes the functionality being metered or measured by a particular SKU in a charge.” A finer forecast grain than SkuId alone.
One genuine trap the per-column diff catches: ConsumedUnit is reported as a Metric in FOCUS 1.0 and a Dimension in 1.2 — compare_versions {column:"ConsumedUnit"} lists column_type among its changed fields. If your usage-accuracy pipeline typed that column from the 1.0 spec, re-check it before pointing it at a 1.2 export.
focus · compare_versions {} → 14 added / 0 removed / 43 changed · compare_versions {column: "ConsumedUnit"} → changed: description_md, column_type, requirements
First 90 days this guide's synthesis
Not official FinOps Foundation guidance
Everything above this box is verbatim served content or a clearly flagged server-derived mapping. The plan below is ours: one practitioner-plausible ordering of the seven official Walk characteristics, with the tool call that gives you the source text for each. The Foundation publishes the destination, not this route. Adapt freely.
- Days 1–10 · Fix the input, not the model. The definition says forecasting depends on being able to “fully categorize and allocate technology costs.” Measure your unallocated share first; if it is large, the Allocation work is the forecasting work. get_capability {capability:"allocation"}
- Days 10–20 · Pick the period grain and freeze it. Decide whether you forecast on billing periods or charge periods and write it down. Both are Mandatory Dimensions in 1.0 and 1.2, so either is safe — mixing them is not. get_column {column:"BillingPeriodStart"|"ChargePeriodStart"}
- Days 20–35 · Land the actuals side. Build one query: SUM(BilledCost) by billing period, plus SUM(ConsumedQuantity) by ServiceCategory / ServiceName. That is the entire FOCUS half of both accuracy KPIs, and it is the same query at 1.0 and 1.2. get_kpi_mapping {capability:"forecasting"}
- Days 35–50 · Write down last month's forecast before you improve it. Forecast Accuracy Rate (Spend) needs a stored forecast figure — FOCUS has no column for it. Persist the number and its date now, or you will have no history to compute variance from in month three.
- Days 50–65 · Make the model rolling. Walk asks for “rolling and trend-based,” not automated. A recurring analyst-owned refresh with a written method satisfies it; a scheduler does not add maturity here.
- Days 65–75 · Fold in the discounts. Walk requires the forecast be “inclusive of rate optimization and commitment-based discounts.” Forecast on EffectiveCost, and check whether your export actually carries ChargeCategory='Purchase' rows with a CommitmentDiscountId before trusting any commitment ratio — page 5 shows what happens when it does not.
- Days 75–85 · Give the other three personas a door. Walk names Product, Leadership, Engineering and Finance explicitly. One shared view they can open unassisted counts; four bespoke slide decks do not.
- Days 85–90 · Book the cadence and set the threshold. “Regular review cadence by FinOps team of forecast thresholds and trends with stakeholder teams.” Put the recurring meeting in calendars and pick your variance number — the official Walk sample goal is “less than 10%,” and the KPI text is clear that “Each organization defines its acceptable variance.”
What a practitioner walks away with
Seven official Walk characteristics as acceptance criteria; four featured KPIs with Foundation formulas, of which Forecast Accuracy Rate (Spend) is the one the maturity model's own “less than 10%” goal measures; six capabilities the framework text itself names as feeding forecasting; and a FOCUS column set — BilledCost, BillingPeriodStart/End, ConsumedQuantity, ConsumedUnit, ServiceName, ServiceCategory, SkuId, EffectiveCost, ContractedCost, ChargeCategory, CommitmentDiscountId — that is identical at spec 1.0 and 1.2, so the pipeline you build today survives the upgrade. What FOCUS will never give you is the forecast itself; that stays yours.
Next: the same two servers applied to showback reporting and to rate optimization, four more unscripted prompts in Quick Q&A, or the full tool surface on the framework and FOCUS server reference pages.