Detailed methodology
The rules that make every figure checkable
This page complements the nine phases of the methodology: how levers are prioritized and sequenced, what measurement must prove, how progress is tracked and how deviations are governed. The thresholds quoted are default values, set at scoping and visible in the workbook.
Contents
Prioritization
A matrix that makes the trade-off explicit
Each qualified lever is ranked on three axes: the monthly gain computed on your observed cost, the implementation effort in days, and the risk, with its nature and reversibility. The matrix does not decide for you: it makes the trade-off explicit and quantified, can be replayed if you change policy, and supports the readout.
- Gain: monthly potential computed on the observed cost of your invoice (amortized and cash), never on a public price alone. Until an amount is confirmed resource by resource, it is given as an order of magnitude.
- Effort: working days per lever, with default values that you correct (1 day for a commitment purchase, 2 days for disks or backup, 3 days for a right-sizing, 5 days for a Start & Stop). Outside virtual machines, each lever also receives an ease score, from 1 (very easy) to 5 (difficult).
- Score: by default, the monthly gain divided by the days of effort; if you correct an effort or a risk, the rank is recomputed. At equal score, the least sensitive environments go first. The order you decide takes precedence over the computed score, and both remain visible.
- Three horizons: quick wins (3 days of effort at most by default, or an ease of 1 or 2) are achieved in 0 to 6 weeks; the medium term (1 to 6 months: redeployments, tier changes, migrations) is planned in your maintenance windows; the options to decide fall outside the policy you have chosen.
- Options to decide, for example: reducing production, changing an application whose software vendor certifies precise sizes, lowering the resilience of production backups. They are quantified so that your management decides with full knowledge, and remain undated, outside the planned total, until it has chosen them.
- Nature of the decision: a central policy, meaning a single decision for the whole estate, is handled first. An owner action requires each team to accept and then execute: that is where execution gets lost, and that is where tracking concentrates. A commitment purchase belongs to procurement and follows the expiry calendar.
- Urgency and lifetime before size: what fails if it is not done in time (a commitment expiry, an imposed date) comes before the largest gain. A commitment whose break-even falls after the planned closure of an environment is advised against, and a scope being exited drops to the bottom of the list, with the reason recorded.
Your policy, as configuration. Levers accepted (right-sizing nowhere, in non-production or everywhere; Start & Stop; commitments), coverage targets per environment, exclusions. Non-production goes first and production is never reduced in the base plan. If you change policy, the plan is replayed without rewriting the rules and shows what changes.
No double counting. The matrix shows a gross total, the estimated overlaps between levers, then a net total. In the action plan, only lever lines carry a value; process actions (notes, campaigns, cadences) carry none, so that the plan reconciles exactly with the potential.
The matrix
What each situation implies
| Lever situation | Gain, effort, risk | What it implies |
|---|---|---|
| Quick win | Medium to high gain; 3 days of effort at most, or ease 1 to 2; low, reversible, live risk | Launched in the first weeks; the agreement of the resource owner is enough, without waiting for a committee |
| Commitment purchase | High gain; about 1 day of effort; term commitment | A priority but sequenced: after reduction and the check of existing commitments, bought in tranches with a utilization check |
| Medium-term project | High gain; several days, ease 3 to 5; medium risk (shutdown, latency, data copy) | Planned over 1 to 6 months in your maintenance windows, grouped by resource, preceded by a pilot |
| Option to decide | Variable gain; high risk or outside policy (production, vendor-certified sizes, resilience) | Quantified, undated, outside the planned total until your management decides |
| Small easy gain | Low gain, effort and risk | Handled in a batch: a single request per owner, one change per action type, or a central policy |
| Small costly gain | Low gain, high effort | Postponed or discarded with its reason; on the long tail, stopping or decommissioning rather than optimizing |
| Gain not confirmed by measurement | Not counted; unknown risk | Listed for information, with no saving counted until the metrics confirm it |
Dependencies and sequencing
Every recommendation can be right and the plan still wrong
Two levers on the same resource do not add up, and a commitment bought too early locks in over-reservation. The plan is therefore sequenced: each action carries its prerequisites, what can move in parallel, its owner and its window. Presented at the readout, it applies during execution.
- Reduce before reserving: right-sizing, then Start & Stop, then commitments. Each lever is computed on what the previous one leaves: the Start & Stop of a machine halved in size applies to a cost already divided by two.
- Existing commitments first: before any purchase, we check their scope and utilization. Reserved capacity freed by right-sizing is reassigned to on-demand usage of the same family and region, production first; the share nothing absorbs is quantified as lost capacity and leads to an exchange or reuse action.
- Conflicts on the same resource: when Start & Stop and a commitment are both possible on a machine, the default rule keeps the one that pays more and records the conflict. On a disk, only the best lever is kept, and in the per-scope view overlaps are allocated pro rata.
- Start & Stop and shared commitments: stopping a machine covered by a shared commitment only saves money if another on-demand machine in the same pool runs at the same hour. Start & Stop is therefore deployed in waves, first on the machines whose freed hours are absorbed without loss.
- Machine generations: long commitments on recent generations; short commitments with reduced coverage on older ones, while migrating in waves; no purchase before the upgrade for families that are migrating.
- The commitment calendar is a critical path: inventory of expiry dates, renewal scenarios (term, target coverage, payment mode), a decision taken early enough to leave time for the purchase, according to a lead time set at scoping, then a commitment governance rule (coverage threshold, who decides, when).
- Purchases in tranches: the quantity starts from a stable base of measured usage, served 9 days out of 10, rounded down and expressed in the smallest size of the family. Utilization is checked in the days following the purchase; a top-up is bought the following month only if utilization is full.
- One window per resource: changes to the same machine (size, disk type, modernization) are grouped in a single restart window, with the order of operations and the estimated interruption.
- Operational dependencies: if weekend patching or backups assume machines are running, Start & Stop starts with weekday nights and extends to weekends once the operations scripts have been adapted; monitoring must tell a scheduled shutdown from an incident.
- Refusals propagate: refusing the right-sizing of a machine also sets aside the tier changes of its disks; refusing the reassignment of reserved capacity leaves it quantified as lost, with a line in the action plan.
From week 1. What depends on nothing starts right away: unattached disks, non-production backup, easy services. These actions are local, reversible and commitment-free; they require the agreement of the resource owner, not a committee.
Before anything else. Scoping conditions the rest, with no direct gain: rules validated in committee, a contact person named per scope, commitment purchase rights checked, resource lists frozen and sent, weekly meeting opened.
The dependencies
What must come first, and why
| Dependency | What must come first | What it avoids |
|---|---|---|
| Commitment purchase | Right-sizing, Start & Stop, check of existing commitments, reassignment of freed capacity | Over-reservation, a commitment paid on hours that were removed |
| Start & Stop of a resized machine | Right-sizing of that machine | Counting the same saving twice |
| Start & Stop of a machine covered by a shared commitment | Check that another machine in the pool absorbs the freed hours, otherwise wait for expiry | Reserved hours lost, zero saving |
| Commitment on an older generation | Migration or upgrade of the family, or a short commitment | Committing for several years to a family that is going away |
| Disk type change | Machine shutdown window, grouped with its right-sizing | Two interruptions for the same machine |
| Weekend shutdown | Adaptation of patching and backups | Operations incident, missed backup |
| Extension to a whole scope | Lessons from the pilot | Rolling out an untested schedule or procedure |
| Any action | Scoping: rules validated, contact person named, lists frozen, rights checked | Actions blocked for lack of a decision maker or of rights |
Evidence from measurement
A saving counts only if your metrics confirm it
Native provider recommendations (Azure Advisor, AWS Compute Optimizer, Google Cloud Recommender) are a starting point, not evidence. A saving only counts once the metrics measured on your estate confirm it, over a 30-day window with a minimum number of data points; otherwise the recommendation stays visible, with no amount.
- Double evidence to downsize a machine: the native recommendation and the metrics of the 30 days must be below the chosen threshold: CPU at the 95th percentile, memory at the 95th percentile when it is measured and, when the provider exposes them, peak disk IOPS. Default threshold 50%; the cautious rule uses 40%, so that the half size stays below 80% utilization. Without a native recommendation, no downsizing is proposed.
- Enough data points: a machine that does not reach the minimum number of data points over the window, deallocated or ephemeral, is shown separately and does not enter the rates.
- Unmeasured memory: without a collection agent, memory is unknown; the gain is then reduced, or the machine is not counted, and the limitation is written on the line.
- Production: never reduced in the base plan. If you decide to open it, the measurement window gets longer, usually 90 days, to see month-end peaks, and an application validation is requested.
- Start & Stop: the starting point is observed usage, with billed hours and a target schedule of 12 hours per working day, weekends and public holidays off. Measured hourly profiles place each machine in one of three cases: no weekend activity, constant background noise (agents, monitoring), real 7-day activity to confirm with its owner. When minute-level collection exists, an uptime window is proposed machine by machine, with a one-hour margin and a minimum window of 8 hours.
- Sorting native recommendations: a commitment recommendation repeated identically on every subscription is information; a duplicate is removed when a measured lever already quantifies the same gain; a recommendation computed at list price, when a negotiated discount already applies, is never added up.
- Evidence the owner can read: each line submitted carries a why this recommendation column that cites the measured values. Evidence is kept with its window and confidence level: an auditor can recompute every amount.
- Post-action check, on the same metrics: after a downsizing, peak CPU must stay below 70% and available memory above 20% over a window set at scoping, otherwise the machine returns to its original size; the utilization of a commitment is checked in the days following the purchase.
Billing only. If only billing access is open, amounts are presented as structural assumptions, as a low and high range, flagged as estimates, and we ask for metric access before any action. If metric collection fails for a service, its rules switch to cautious mode and show no gain.
Metric history. Once continuous collection is in place, metrics are kept at minute level per machine and per day: percentiles can be recomputed over 30, 60 or 90 days without querying the provider again, always in read-only mode.
Levers and measurements
What is measured, over which window, with which safeguard
Thresholds are default values, adjustable at scoping and visible in the parameters tab of the workbook.
Machine downsizing
Native recommendation, CPU at the 95th percentile, memory at the 95th percentile if measured, peak IOPS.
- Window: 30 days with a minimum number of data points; usually 90 days if production is opened
- Threshold: below 50% (40% under the cautious rule), half size available in the family
- Safeguard: if not confirmed, the line stays native recommendation only, with no saving counted
Start & Stop
Billed hours, hourly profile, weekend activity.
- Window: analysis window, then the last 7 full days for tracking
- Threshold: quiet weekend (average CPU below 5%, maximum below 30%); minimum window of 8 hours
- Safeguard: 7-day activity is confirmed with the owner before any schedule
Disk tier and size
IOPS and throughput peaks, space actually used.
- Window: 30 days
- Threshold: peaks below 80% of the target tier's limits; size equal to used space plus 30%
- Safeguard: a saturated disk (95% or more) is never lowered; no downgrade without metrics
Databases, hosting plans and storage
CPU, DTU or memory at maximum; transactions for low-activity storage.
- Window: 30 days
- Threshold: maximum below 20%; fewer than 5,000 transactions per day for storage
- Safeguard: order of magnitude, to confirm resource by resource
Idle resource
Maximum CPU, network traffic, connections.
- Window: 30 days
- Threshold: maximum CPU below 5%, near-zero traffic
- Safeguard: deallocation, then retention for a period set at scoping before deletion, with the owner's agreement
Commitments
Daily on-demand and reserved hours, observed price and discount.
- Window: daily series
- Threshold: base served 9 days out of 10, rounded down
- Safeguard: purchase in tranches, after reduction; no purchase on unstable usage; utilization checked (at least 95%) in the days following the purchase
Execution indicators
Progress is measured in value and in evidence
Not in the number of meetings. Three figures structure every review: the target (identified potential), the trajectory (secured run-rate) and the proof (savings generated to date, cross-checked against the invoice). The other indicators explain the gap between these three figures.
- A single value chain: identified (quantified and published after the quality checks and alignment with your policy), validated by the owner, planned (date and change or order reference), realized, verified in the invoice. The amounts at each stage are never added up; statuses carry over from one analysis to the next and are kept up to date in review with your teams.
- Each action carries an owner, an action status (to do, in progress, done, abandoned), a completion rate, a date and a comment. Until an action is marked done with a date, its gain is not counted as generated.
- A saving observed, not declared: for a modified resource, the saving is read on the invoice, as the gap between the average cost per day before and after the date of the change. For a machine covered by a commitment, only the on-demand share and the licenses count as long as the pool does not reabsorb the freed hours.
- Variance bridge: every euro of change in the invoice is attached to a resource and a cause (lower usage, size or tier change, move under commitment, deleted resource). The sum of the causes equals the change exactly, and avoided savings remain in the plan.
- Findings outside the plan and hygiene of the figures: optimizations visible with no plan line and new costs are flagged separately. Credits, one-off corrections and theoretical gaps that no invoice confirms are never counted as savings, and reasoning stays on a constant scope.
- Behavior: the response rate of owners rather than the number of requests sent; the conversion rates (validated over identified, realized over validated); actions blocked beyond a delay set at scoping.
Three figures per review
- The target: identified potential, net of overlaps
- The trajectory: secured run-rate
- The proof: savings generated to date, cross-checked against the invoice
What is tooled. The engine computes the secured run-rate, the amount generated to date and the variance bridge. The before and after check, resource by resource, and spotting deviations outside the plan are done in our tracking workbooks.
The dashboard
Eight key indicators
| Indicator | Definition | Frequency and owner |
|---|---|---|
| Identified potential (the target) | Net monthly gain of the plan's actions, excluding options, after overlaps between levers | At each collection; presented to management |
| Secured run-rate (the trajectory) | Potential multiplied by the completion rate of actions in progress or done, in euros per month | Every week; FinOps lead |
| Generated to date (the proof) | Secured run-rate multiplied by the months elapsed since the realization date, cumulated | Every week; FinOps lead, financial control |
| Invoice at amortized cost (the cross-check) | Amortized cost on a constant scope over the last 7 days then over the month, explained by the variance bridge | Every week and every month; financial control |
| Options awaiting a decision | Gain of quantified options not yet decided | At each management review |
| Conversion rate | Validated divided by identified; realized divided by validated | Every month; steering committee |
| Blocked actions | Actions with no progress beyond a delay set at scoping | Every week; FinOps lead, with escalation |
| Commitment coverage | Share of usage covered, before and after the purchase plan, by scope, family and environment | Every month; FinOps lead, procurement |
As needed, the share of potential secured, the amount secured over a full year, the owner response rate, the execution of commitment purchases, the share of machines to downsize, the non-production Start & Stop rate and measurement quality are added.
Deviations and reviews
A plan always drifts from its first version
An owner refuses, a window slips, an announced action does not show on the invoice. These deviations are recorded, justified and taken into account at the next calculation: the potential shown stays true, and decisions are not lost. This setup applies from validation to handover, and fits into your existing committees instead of adding to them.
- Roles: a named sponsor carries the approach and appears in every communication. A FinOps pair steers it: our consultant and your internal FinOps lead. One contact person per entity, subscription or application appears in the owner column of the action plan. Operations or the managed service provider executes; procurement and finance decide on commitments.
- Feedback register: for each resource and each lever, a line decision (validated, discarded with a reason, to investigate), with its source and its date. The register is read again at each analysis: a discarded recommendation leaves the potential at the next calculation, its reason stays visible, and it does not come back every month.
- Configuration and log: scope exclusions and decisions on commitments are recorded in your configuration and reapplied at each calculation. A log dates every decision and every milestone, with its scope, its reference and its effect in the tracking.
- Deviations read on the invoice: an action announced but not observed is flagged, for example a resource declared deleted that is still billed. A line missing from the next analysis moves to not applicable or to check, with its reason.
- An escalation agreed at scoping: a response time, a follow-up at the due date, then a graduated escalation to the entity lead and finally to management, according to steps set at scoping, always with the quantified impact. Each workstream carries a color status: green, amber or red.
- Decision rules: a single backlog, kept in your tool, with for each line the value, the owner, the decision, the effective date and a mandatory reason for rejection. Actions without downtime or risk go ahead with the owner's agreement alone; a policy without an effective date is not considered decided.
- What is not automated: KeeFinops acts on none of your resources, creates no ticket and changes nothing. We prepare the actions; your teams execute, and verification is done on your invoice.
The pace. Every week, the analysis is replayed on the latest collection or on the archive you upload: replaying a period rewrites it, with no duplicate. During guided execution, a short weekly meeting reviews the statuses, the three summary figures and the cross-check against the invoice, then handles the blockers.
Over time. The cadence of execution and continuous steering: one day a week for three months, then half a day a month. With the autonomy option, a quarterly review of the potential.
The meetings
Who meets, when, and what for
| Meeting | Frequency and participants | Content |
|---|---|---|
| Analysis update | Every week; read-only collection or uploaded archive, checked by KeeFinops | Completeness, workbook and indicators updated, new lines with identified status |
| Execution meeting | Every week during guided execution; FinOps lead, KeeFinops, contact persons concerned | Statuses, rates and dates; target, trajectory and proof; blockers and decisions |
| Scope launch | Once per scope; contact person, owners, KeeFinops | Validation of recommendations, calendar, change windows |
| Management report | Every month; sponsor, management | One page: target, identified, validated, realized, verified, blockers, options to decide |
| Management checkpoint | At each milestone; management, FinOps lead, KeeFinops | Decisions and options, minutes with actions, owners and due dates |
| Commitment review | Every quarter; procurement, finance, FinOps lead, KeeFinops | Coverage, utilization, expiries; one decision per commitment, taken before its expiry |
Frequencies are set with you at scoping and aligned with your existing committees.
Large enterprises
Reinforced governance, package by package
For a group with several entities, the same setup widens: a common framework that each entity applies, committees that decide, adoption indicators per entity. It is installed in fixed-scope packages, run with a FinOps practitioner embedded in your teams, then handed over.
- Package 1, common framework: dictionary of dimensions, if/then allocation rules, keys for splitting shared costs and for chargeback, validated with each entity.
- Package 2, roles and committees: sponsor, FinOps pair, contact person per entity, application owners, procurement, financial control, Green IT lead; a 30-minute weekly meeting, a 45-minute optimization review, a one-hour monthly committee, a vendor committee at each renewal date.
- Package 3, indicators and contracts: adoption KPIs per entity (share of cost allocated, actions with an owner and a date, lead time between identification and decision, commitment coverage and unused share, Green IT indicators); contract register, consumption against commitment, quarterly review with procurement.
- Package 4, operation and handover: budget reforecast every month, each variance explained by its cause (volume, price, new projects, optimizations); taken over by your contact persons or by an internal FinOps practitioner.
Tooling, without overpromising. Showback and explained variances: in our app. Virtual tagging, chargeback keys and contract register: in a workbook, pending their integration, which is planned. Green IT indicators: tooled; emissions published by the provider: practiced in the field.
Reporting. A group format and a per-entity format, GreenOps included, aligned with the providers' monthly publication.
Review requirements
What we check before submitting a recommendation
These requirements are kept in review, line by line, with your teams; they assume no automatically computed status.
One finding, one family, counted once
We file each finding in a family defined by the lever that addresses it: remove, reduce, schedule, buy better, rethink the architecture, allocate and govern. The same resource is never counted twice: an idle resource does not also appear under right-sizing.
Linked data
We link cost, inventory, configuration, usage, organization and decisions, because an isolated cost cannot be acted on. A billing export not enabled at resource level is a major limitation, written as such.
Context before the recommendation
We check with your owners the application, environment, criticality, software vendor constraints and maintenance window of each resource. An unknown eligibility counts as forbidden for any destructive action.
Notions of saving never mixed
We separate the theoretical saving at public price, the gross avoidable cost, the net cash saving after commitments, the reallocation opportunity of a freed commitment and the blocked saving. A saving never exceeds the observed cost.
The effect on commitments, in plain words
We check the effect of each action on your reservations and savings plans: coverage before and after, commitment freed, possible reallocation. When coverage data is missing, the effect is stated as unknown, never as none.
Enough measurements before concluding
We read metrics over 30 days at the 95th percentile, with a minimum number of data points. A single high metric is enough to set aside a downsizing; intermediate metrics go to manual review, and unmeasured memory is written as a limitation.
Idle resources: never a direct deletion
Shutdown, then observation for a period set at scoping, backup of the volumes, notification of the owner and deletion after validation. We propose no deletion if the owner, the eligibility or the backup state is unknown.
Six questions per recommendation
Why it is valid, why it matters financially, whether it is safe, when to apply it, who owns it, whether the native tools have already found it. A recommendation without a rationale or a limitation is incomplete.
An owner for every line
We look up the owner by tag, CMDB or naming convention, then by relationship: a disk follows its machine. Failing that, a fallback dimension carries the line, flagged as such until the review.
Practices by context
What the method adds when the context calls for it
These practices are added to the nine phases depending on the nature of the engagement; they are described with no figure specific to an engagement.
Scoping
Start from what exists
- An immersion period, when the engagement starts that way: an initial findings report in several formats, including a one-page summary to decide. Strengths come before limitations.
- A maturity grid by pillar (allocation, budget, reporting, optimization, governance, tooling and data, culture): when allocation is already solid, we industrialize its production instead of redoing it.
- A reference cost view per use (finance, team steering, technical use, optimization), with a shared glossary.
- A FinOps role expressed as a business need, formalized with your security team: viewing costs and saved reports, reading the detailed export. It grants no write access; billing objects (cost categories, budgets, alerts) are configured by your team, from our proposals.
Collection and diagnosis
Read what the invoice does not say alone
- A prioritized data request: priority, lever unlocked, where the data sits and status (received, partial, to provide). Everything is requested read-only.
- Power management indicators for non-production: a resource is managed if its schedule is configured, running 24/7 if it runs almost the whole window. A schedule set on a resource that runs 24/7 signals a failing automation.
- Managed databases: only compute is counted; on some services, a stopped database restarts on its own after seven days, and stopping a database covered by a reservation saves nothing in cash.
- Signals to investigate: a decommissioning item whose cost is rising, 24/7 non-production in a production account, high availability active outside production. For each, a hypothesis and the missing data.
Prioritization
A plan that follows the dependencies
- A multi-year plan in a workbook, which starts from the invoice and the savings already captured, reconciles the existing backlog to avoid any double counting and lists the data to provide. The recommendations of the native tool serve as a floor.
- Sequencing quarter by quarter, in dependency order: first the no-regret actions, then right-sizing and scheduled shutdown, next commitment conversions at their expiry.
- Commitments when coverage is already mature: keep coverage, repurchase expired reservations, improve the rate; long commitments on the fixed footprint, shorter and tapering ones on the share that may change, coverage capped and reviewed every quarter.
- An estate whose usage will change (growth, consolidation, end of life): the expected usage trajectory, validated with IT and the business, gives each machine one action per period; each decision is justified, with its impact and its risk.
Execution
Have FinOps carried by the teams
- FinOps carried by the platform: non-functional requirements published by your platform team (scheduled shutdown, right-sizing of containers and databases, backup and log retention, allocation tags), each with an adoption indicator, a ticket and an owner.
- Generative AI costs: each call goes through an application profile that carries the mandatory tags (cost center, application, environment, owner), complemented by dedicated budgets, the choice of model according to the task and caching.
- Investigating an anomaly: date of the break, volume and average size of the billed items before and after, main hypothesis and a message ready to send to the team in charge. See the article Detecting a cost anomaly before the incident.
- Start & Stop of non-production SAP environments: quantified on the amortized compute cost of a full month and reasoned by system, not by machine; the shutdown and restart sequence is validated and automated by your operator, after a pilot on a low-risk development system.
Continuous steering
Reporting that every reader understands
- Cost categories and budgets by team, product and cost center, with alerts at 50, 80 and 100%; each drift has an owner, a cause and an action.
- A checked monthly showback: on-demand usage, usage under savings plans and under reservations with their share; the gap between the invoice and the rebuilt amount must tend towards zero.
- Management reporting at amortized cost, with an annual projection and a landing revised by realized and planned savings.
- Rituals at several levels, at frequencies set with you: a meeting with the platform team, a management committee, an awareness session, and a roadmap in quarterly increments, each with its success criteria.
Handover
A handover that holds without us
- One procedure per recurring chain, at least the showback and the management reporting, with a formula-driven workbook and a checklist at each cycle (period, year change, untagged share, exchange rate).
- Alongside an integrator or a managed service provider: its data is used as input and never reproduced, its proprietary templates are excluded from our deliverables, and the split of roles is written down.
Let's see how this methodology applies to your scope
Thirty minutes to choose the entry point, the format and the calendar.