Skip to content

Variation Budget Allocation Sheet

An allocation artifact — instantiates Tolerance Stack Management

Divides the system's total allowable variation into an explicit, negotiated per-contributor allowance, so each team knows its slice of a shared budget rather than treating its local tolerance as a private entitlement.

Most tolerance methods work forward — given the parts, what does the stack come to? The Variation Budget Allocation Sheet works backward: it starts from the system's total allowable variation and hands each contributor an explicit slice of it. Its defining function is division of a shared budget: it makes visible, on one sheet, that the fit limit is a common pool and that one team's generous tolerance is another team's forfeited margin. And it does not divide equally by default — it allocates by rule, giving tighter slices where precision is cheap or the contributor is highly sensitive, and looser slices where tightening is expensive or the effect is small. It is the artifact that turns "each part gets whatever tolerance is convenient" into "each part gets its justified, negotiated share of the whole."

Example

An automotive body-in-white must hold the panel gaps around a door to a total of about ±1.0 mm to look and seal right. That total is a shared budget consumed by three contributors: the stamping of the panels, the welding of the body structure, and final assembly. Left to themselves, each shop would claim a comfortable ±0.6 mm and the stack would blow the limit. The Variation Budget Allocation Sheet divides the ±1.0 mm deliberately: stamping, where tighter dies are relatively cheap and the process is capable, is allocated ±0.4 mm; welding, where fixturing variation is stubborn and expensive to reduce, gets ±0.7 mm; assembly, a small and controllable contributor, gets ±0.3 mm — combined statistically to fit the budget. The sheet is the negotiation record: each shop sees its slice, sees that asking for more means taking it from another shop's already-tight allocation, and the allocation rule (cost of precision × sensitivity) is written down so the split can be defended rather than re-fought each release.

How it works

The sheet inverts the stack: it takes the system fit limit as a fixed budget and distributes it across contributors according to an allocation rule that weighs each contributor's sensitivity, its cost of tightening, its detectability, and its dependency on others. Contributors that are cheap to tighten or highly influential are handed smaller allowances; those that are costly or minor get larger ones. The result is a one-page ledger of who owns how much of the shared variation, plus the rationale for the split. What distinguishes it from the analysis methods is direction and purpose: it does not predict a stack, it apportions one — and it makes the shared-budget nature of the limit socially visible so teams stop treating local tolerances as isolated entitlements.

Tuning parameters

  • Allocation rule — the basis for the split: equal shares, sensitivity-weighted, cost-of-precision-weighted, or a blend. This is the sheet's core dial and encodes what the organization is optimizing for.
  • Combination assumption — whether slices are sized to sum worst-case or combine statistically. Statistical combination grants larger individual slices from the same budget but inherits the independence risk.
  • Reserve fraction — how much of the budget is withheld unallocated as margin against surprises rather than fully distributed.
  • Renegotiation cadence — how readily an allocation can be reopened when a contributor proves it cannot hold its slice; too rigid and it fails silently, too fluid and it never stabilizes.
  • Cost-curve inputs — how the cost-of-tightening for each contributor is estimated; a wrong curve mis-allocates precision to where it is expensive instead of where it is cheap.

When it helps, and when it misleads

Its strength is that it makes a shared budget governable: by rendering the fit limit as a divided-up pool with named owners and a written rule, it prevents the classic failure where every team quietly claims a comfortable local tolerance and the stack silently exceeds the limit. Allocating precision by cost-of-tolerance — spending tightness where it is cheap and buying looseness where it is dear — is the principle that keeps the split economically rational rather than merely equal.[1]

It misleads when the allocation is treated as permanent truth: a contributor that turns out unable to hold its slice needs the budget reopened, not a quiet local waiver that the sheet never records — and an allocation frozen against changing process capability slowly drifts from reality. It can also be gamed, with teams lobbying for generous slices regardless of sensitivity. The discipline is to base the split on real sensitivity and cost data, keep a reserve rather than allocating the last micron, and pair the sheet with a live register so that overruns rebalance the budget instead of eroding it unseen.

How it implements the components

  • variation_budget — it renders the global fit limit as an allocable pool and distributes the whole of it across contributors as explicit per-owner allowances.
  • stack_allocation_rule — it encodes and records the rule (sensitivity, cost of precision, dependency, detectability) that decides how much of the budget each contributor receives.

It does not track consumption of the budget over time — that live ledger is Error Budget Register — nor does it verify that the allocated slices actually combine within the limit; that check belongs to Tolerance Stack Analysis.

Notes

Allocation and tracking are two jobs across time and are best kept in two artifacts: this sheet decides the split, an Error Budget Register tracks the spend. Folding them together tends to freeze the allocation (because reopening it disturbs the live record) — precisely the rigidity that pushes teams toward unrecorded local waivers instead.

References

[1] The cost-tolerance relationship holds that tightening a tolerance costs more as it approaches a process's capability limit, and the cost curve differs by contributor. Rational allocation spends the variation budget by buying tightness where its marginal cost is lowest, not by dividing the limit evenly. ↩