Budget and margin report

The problem this solves

A margin looks comfortable right up until someone asks what the numbers are made of. Half the values are estimates, a tenth of the system has no value recorded at all, and the total is presented as though every figure were measured. The subsystem that is well over its own allocation stays invisible because the system total is still green.

How it works

Any resource rolled up the hierarchy, with the margin stated against how real the data underneath is. Best estimate, contingency, predicted value, allocation and margin kept separate throughout, coverage printed next to every total, and a delta that reports the rate of growth as well as its size.

You are producing a budget and margin report from the Dalus model
[model name]: a rollup of a resource through the system hierarchy,
with margins stated honestly against the maturity of the data
underneath them.

BEFORE ANYTHING ELSE, LOAD THE XLSX SKILL and follow it for
construction and formatting.

WHAT THIS IS FOR. Any tool can add a column. The reason to run this
against a system model is that the model knows the hierarchy, the
allocations, the requirement each limit comes from, and what changed
since last time. The report's job is to say what the number is, how
much of it is real, and where it moved.

CONFIRM FIRST, in one message: which Dalus model and branch; which
budget (mass, power, thermal, cost, data rate, volume, or another the
model carries); the scope (whole system, one subsystem, one mode or
configuration); whether a previous run exists to compare against; and
whether the limit comes from a requirement in the model or the user
will supply it. Ask anything else in the same message. Then begin.

MODE MATTERS FOR SOME BUDGETS. Power and thermal are meaningless
without an operating mode: peak, cruise, safe, standby, launch. If
the model records states or modes, ask which one, and if it records
several, offer to produce the rollup per mode, since the worst case
is usually in a mode nobody looks at. Mass and cost are
mode-independent. Say which case you are in.

READ THE MODEL: the part hierarchy in scope; the resource values on
each element with their units; multiplicities, so a component
appearing four times counts four times; any allocation or budget
target recorded per subsystem; the requirement stating the system
limit, with its ID; any contingency or margin policy the model
records; data maturity or provenance attributes on the values; and
states or modes where the budget is mode-dependent.

ESTABLISH DATA MATURITY PER ITEM, and carry it through everything.
Classify each value as:
- Measured: from real hardware or test.
- Calculated: derived from a design that exists.
- Vendor-specified: from a datasheet or quote.
- Estimated: an engineering judgment.
- Allocated only: no bottom-up value at all, just the number the
  subsystem was given.
- Missing: nothing recorded.
Use the model's own maturity attribute where it has one. Where it
does not, ask the user how they mark maturity rather than inventing a
scheme, and if there is no way to tell, say so and report the whole
budget as unclassified maturity, which is itself the finding.

NEVER INVENT A VALUE. No typical masses, no estimated power draws, no
substituting a similar component. An element with no value is
reported as missing and counted, and the total says how much of the
system it represents. A rollup that silently fills gaps is worse than
one with holes in it, because the holes are what the engineer needs
to see.

THE ARITHMETIC, and keep these five separate throughout:
- Current best estimate: the bottom-up sum of what is recorded.
- Contingency: applied per item according to its maturity and the
  team's policy. If the model records a policy, use it. If not, ask
  for the percentages rather than assuming, and if the user has none,
  apply a clearly labelled default set and put the labels next to
  every number that used them.
- Predicted value: best estimate plus contingency.
- Allocation or limit: from the requirement, with its ID.
- Margin: stated both ways, against the best estimate and against
  the predicted value, in absolute terms and as a percentage.
The line that usually matters most is the second margin: the budget
that looks comfortable against raw estimates and disappears once
contingency is applied at the maturity the data actually has. Say
that in words where it is true.

ROLL UP THROUGH THE HIERARCHY, showing the contribution at each
level, with multiplicities applied. Show the arithmetic so it can be
checked: children sum to parents, parents sum to the system. If they
do not, stop and report it before presenting any total. Where a
subsystem has an allocation of its own, compare its rollup against
its allocation, since a system in margin can contain a subsystem well
over its budget and that is the actionable finding.

COVERAGE, next to every total: what percentage of the total comes
from measured or calculated values, what percentage from estimates,
how many elements have no value at all and what share of the system
they represent. A total with 40% coverage is a different object from
one with 95% and the report must never let them look alike.

THE DELTA, if a previous run exists. Report what moved: the change in
best estimate, predicted value and margin; which subsystems the growth
came from, largest first; items added or removed since last time;
items whose maturity improved, which usually reduces contingency and
is good news worth naming; and any item that grew by more than a
threshold the user sets. Growth is normal in development, so report
the rate as well as the amount: at this rate of growth, the margin
reaches zero in roughly this many weeks. That sentence is the one
chief engineers act on. If no previous run exists, say so, record
enough for the next run to compare against, and note that subsequent
reports will be more useful.

FINDINGS, ordered by consequence:
- Subsystems over their allocation.
- The system over its limit, against best estimate or predicted.
- Elements with no value, by share of the hierarchy they cover.
- The largest contributors, since attention goes there first.
- Items whose maturity has not improved in several runs, which
  usually means nobody owns them.
- Values that look wrong: wrong unit, wrong order of magnitude, a
  duplicate counted twice through the hierarchy.
- Where the limit comes from a requirement, note if that requirement
  has no verification.

THE WORKBOOK:
- Cover: model, branch, revision, date, scope, mode, the limit and
  its requirement ID, headline numbers, coverage, and the delta
  summary in plain language.
- Rollup: indented hierarchy with value, maturity, multiplicity,
  contingency applied, contributed total, and per-level subtotals.
- By subsystem: allocation versus rollup versus margin.
- Delta: item-level changes since the previous run.
- Findings.
- Gaps: every element with no value, with its model ID and owner
  where recorded.
- Assumptions: contingency percentages used and where they came
  from, unit conversions applied, elements excluded and why.
Model element IDs stay on every row so a number can be traced back.

BEFORE DELIVERY, render and check: formulas resolve, subtotals match
the hierarchy, the cover matches the sheets, percentages are
consistent, and no unit is mixed within a column. Fix and check
again.

DELIVER the .xlsx and give a short spoken summary: the headline
number, the margin both ways, the coverage, where the growth came
from, and the one thing to look at first. Offer, do not execute:
running the same budget for the other modes, opening tasks for the
elements with no value, writing the rollup back onto the model's
subsystem attributes, and re-running as a delta before the next
review.

THIS WORKFLOW IS READ-ONLY on the model.

Replace the [bracketed] placeholders with your model and project names.

What you get

Common questions