FinOps maturity assessments
Delivered by the person who wrote the assessment methodology.
This is for you if you already have a FinOps practice, formal or informal, and you want an independent, evidence-based read on where it actually sits, what to do next, and which gaps matter most. A typical engagement runs four to eight weeks, depending on scope.
I wrote the FinOps Foundation Maturity Assessment methodology. It is used by AWS, Google Cloud, and Microsoft Azure, or by derivatives of it, to evaluate customer FinOps practice.
An assessment delivered by me is not a tooling exercise, and it is certainly not a vendor pitch dressed up as analysis. It is a structured, opinionated view of where your practice sits, where the gaps are, and which of those gaps to close first.
- 22 Framework capabilities A targeted six or eight tells you more than a thin average across all of them.
- 5 Scoring lenses Knowledge, process, metrics, adoption, automation. Each scored 0 to 4.
- 4 to 8 Weeks per engagement Scaling with scope, from a single function to a federated estate.
What an assessment covers
Assessments are scoped to be useful, not exhaustive. The methodology explicitly recommends focusing on the capabilities that matter most given where your practice currently stands, instead of scoring every one. A targeted assessment of six or eight capabilities tells you something useful; trying to assess all 22 in one engagement produces a thin average that hides the variance you really need to see.
Four decisions shape an assessment before any evidence is gathered. Target scope is which of the FinOps Framework’s 22 capabilities to assess, chosen to match where your practice is currently investing or struggling. Target group is the part of your organisation in scope, ideally a coherent group at a similar maturity level, so you do not end up with a cross-section that averages out the variance that matters. Lens weighting sets the relative importance of each of the five maturity lenses for your business priorities at this stage. Target score is a realistic short-term goal for each capability, and becomes the benchmark for measuring progress at re-assessment.
The four FinOps Framework domains all sit above these capabilities: Understand Cloud Usage & Cost, Quantify Business Value, Optimize Cloud Usage & Cost, and Manage the FinOps Practice. The assessment reports against these domains as well, rolling up the capability-level scores within each.
How capabilities are scored
Each capability in scope is evaluated through five lenses, each scored on a 0 to 4 maturity scale:
- Knowledge: how widely the capability is understood across the target group.
- Process: how consistently and formally the work is defined and executed.
- Metrics: whether the capability is measurable, and how those measures are defined and used.
- Adoption: how broadly the capability is operationalised across the target group.
- Automation: the extent to which repeatable activity in this capability is mechanised.
The maximum score per capability is 20 (five lenses at a maximum of four each), expressed as a percentage. Lens weighting tilts the aggregate toward whichever lenses matter most for your business at this stage. The result is an evidence-backed view of each capability that can be compared directly with a future re-assessment using the same scope, target group, and weighting.
How an engagement runs
The standard shape, scaled up or down with scope:
- Discovery and design: defining the four decisions above (target scope, target group, lens weighting, target score) so the assessment is meaningful for your situation, not generic.
- Stakeholder identification: identifying the people with primary impact on the chosen capabilities, and SMEs who can give evidence-based input on each lens.
- Evidence-gathering interviews: structured 1:1 conversations across the identified stakeholders. Capabilities served by overlapping subject-matter experts are typically grouped to make efficient use of everyone’s time.
- Documentation and tooling review: direct examination of billing data, allocation hierarchy, dashboards, governance documents, and any existing FinOps tooling that sits within the scope.
- Lens-by-lens scoring: for each capability in scope, scoring all five lenses against the rubric, with the evidence captured so the rationale is auditable.
- Draft report: a written deliverable structured for both executive and practitioner audiences.
- Review iteration: one round of factual review with you before the report is finalised.
- Executive readout: a synchronous walk-through of findings and recommendations with whichever stakeholders need to be in the room.
What you get
A written report structured to be useful to multiple audiences: short enough at the top for an executive briefing, and detailed enough underneath for the people who will do the work. Length scales with scope, so a focused four-or-five capability assessment lands shorter than a full multi-business-unit one.
It opens with a current-state read for executives: what is working, where the practice is constrained, and the 12-month roadmap that follows. Underneath that sit the identified strengths, which always exist and become the foundations for the gap work rather than something to skip past, and the identified gaps, each with the cost of leaving it unchanged. Then come typically four to six prioritised initiatives, each with scope, sequencing, and dependencies, sized to your organisation.
The evidence follows: capability-level scoring with the five-lens breakdown and the supporting evidence behind each score, then aggregate analysis covering domain-level rollups, target against actual, and the lens patterns that emerge across capabilities. Consistently weak automation across several capabilities usually points to a tooling problem rather than a capability-specific gap.
The re-assessment baseline closes it out: the same scope, target group, and weighting are recorded, so a future assessment is directly comparable and improvement is measured against your own definition of progress.
The output is suitable for sharing internally with finance, engineering, and executive leadership without translation. It is explicitly designed so it doesn’t need to be reworked per audience.
Two engagement shapes
Most assessments fall into one of two patterns, decided during scoping:
Single-document assessment. One report covering the chosen capabilities end to end. This is the right shape for organisations with a single, coherent FinOps function (even when the cloud estate is large) where the goal is a unified view and a single roadmap.
Multi-report assessment. A central report covering the enterprise-wide function, plus separate focused reports for each business unit or division, plus an executive summary that draws the comparative threads across them. This is the right shape for federated organisations where individual business units are at very different maturity levels, and where the enterprise-wide view alone would average out the variance that matters.
Both shapes use the same underlying methodology and produce comparable scoring. The decision is about how findings are packaged for your organisation, not about depth of analysis.
Who it’s for
An assessment is most useful when:
- You have an existing FinOps practice (formal or informal) and want an independent, evidence-based view of where it actually sits.
- You are about to invest meaningfully in tooling, headcount, or organisational change, and want to make sure the investment is targeting the right gaps.
- Internal stakeholders disagree about the state of the practice, and a third-party, methodology-backed view is needed to break the deadlock.
- You are scaling a practice across business units or geographies and need to know which are leading and which need direct support.
An assessment is not the right starting point if you don’t yet have any FinOps activity to assess. In that case, a strategic advisory engagement to set up the practice first is usually a better use of budget. A maturity assessment 12 months on then has something meaningful to measure.
Assessment engagements are scoped on enquiry. The first step is a discovery conversation to understand your environment, the questions you are asking, and which capabilities are worth bringing into scope.