Build a decision-ready budget

1930. Lesson identity

Module

4.15 — Budgets

Lesson

Build a decision-ready budget

Academic type

Guided Build

Schema type

Practical

Order

2

Estimated time

45–60 minutes, including practice

1931. Learning objective

After this lesson, you can produce and explain a bounded project budget by comparing at least two scope-and-schedule scenarios, checking relevant cost-category completeness, identifying the assumptions that drive cost, and describing the tradeoffs behind your recommendation.

1932. Why this matters

A total amount is not yet a decision tool. A useful budget shows what the project includes, how long that scope takes, which assumptions are fragile, and what changes when the scope changes. AI-assisted work may reduce drafting time without making integration, review, testing, correction, or delivery predictable. Your budget must help a team choose between promises, not merely report a number after the choice has already been made.

1933. Prior knowledge

You should already be able to:

• Separate a project promise into work, evidence, and reserve.
• Distinguish a cost category from a scope commitment.
• State assumptions instead of hiding them inside an estimate.
• Describe the difference between a base estimate and uncertainty around that estimate.

These skills come from the previous lesson, Every promise has a cost.

1934. Core concept

A decision-ready budget is a comparison of bounded scenarios, not a single prediction.

Each scenario must define:

1. Scope: What is included and excluded.
2. Schedule: The planned duration and major work phases.
3. Cost basis: The unit and calculation used for every amount.
4. Cost categories: The relevant kinds of work and expenditure, including justified zero or N/A entries.
5. Evidence: What must be demonstrated before the estimate becomes more reliable.
6. Reserve: Which uncertainty remains and how it is represented.

Use one unit system consistently within a calculation. For example, if the scenario uses work units, calculate the reserve and planning total in work units. If it uses person-days, keep the estimate in person-days unless a separately stated rate converts those days into currency. Do not add person-days, currency, and subscription counts as though they were the same unit.

A completeness check prevents a low total from being created by omission. Review implementation, integration, review, testing, correction, delivery, tools and services, and external costs. For each category, enter an amount or mark it N/A/0 with a reason. An excluded category is acceptable only when the scenario boundary explains why it does not apply.

1935. Mental model

Use the Scenario → Completeness → Sensitivity → Tradeoff → Decision model.

Use these unit-consistent formulas:

Reserve units = base estimate × reserve rate
Planning total = base estimate + reserve units

If a currency conversion is required:
labour cost = person-days × stated rate
reserve-eligible currency subtotal = sum of currency costs explicitly marked reserve-eligible\ncurrency reserve = reserve-eligible currency subtotal × reserve rate\ncompatible currency subtotal = labour cost + applicable currency costs\nplanning total = compatible currency subtotal + currency reserve

Calculate each scenario using the same unit basis. A sensitivity test changes one material assumption, recalculates the affected category, recalculates the reserve when the reserve policy requires it, and records the resulting planning total.

1936. Concrete example

Imagine a small stealth prototype with one compact level, one guard behavior, one extraction objective, and a short playable demonstration.

The expanded scenario requires 180 additional work units in the planning total. The difference is not explained only by the second route. It also reflects more behavior, more testing combinations, a longer schedule, and greater uncertainty.

For completeness, the focused scenario might list external vendor fees as N/A — no external vendor is included in this bounded prototype. Tools and services must still be listed, even if their amount is zero because the scenario uses existing tools. Review, integration, testing, correction, and delivery remain applicable categories and cannot be silently omitted.

If behavior testing increases by 25 work units in the focused scenario, record whether the 25 is added to the base estimate. Under a reserve policy calculated from the revised base, the new base is 265 work units, reserve is 265 × 0.20 = 53, and the planning total is 318 work units. State the policy rather than adding 25 to an old total without explanation.

A decision-ready recommendation could be: choose the focused scenario for the first commitment because it provides the demonstration target within a smaller bound; consider the second route only after the first route and guard behavior have produced the required evidence.

1937. AI-native workflow

Use AI to inspect and challenge the budget, not to delegate the decision.

1. Create your own scenario table, unit basis, category checklist, and assumptions before prompting.
2. Ask AI to identify omitted work, duplicated categories, contradictory assumptions, unjustified N/A entries, and untested cost drivers.
3. Ask AI to recalculate the effect of changing one assumption at a time while preserving the stated unit and reserve policy.
4. Compare the response with your source table. Correct arithmetic or reasoning errors yourself.
5. Ask AI to restate the recommendation in a short decision memo, then verify that it preserves your exclusions, category decisions, reserve policy, and evidence gates.

Useful prompt:

Review these two bounded game-development scenarios. Do not invent rates or new scope. Check whether each relevant cost category is present; flag missing categories and require a reason for every N/A or zero entry. Verify that all arithmetic uses the stated unit consistently. Identify the three assumptions with the greatest potential effect on the planning total, calculate the stated sensitivity changes, and flag missing evidence. Keep facts, estimates, and open questions separate.

The learner remains responsible for choosing the scenarios, supplying the assumptions, checking calculations, validating category exclusions, and accepting or rejecting the recommendation.

1938. Common mistake / wrong assumption

The common mistake is to make the optimistic scenario the default and add a vague percentage at the end. A reserve is not a substitute for scope definition, category completeness, or evidence. If the budget does not say what happens when a route, feature, or schedule assumption changes, the percentage only hides the uncertainty.

Another frequent error is mixing units or silently omitting categories. A person-day total cannot be added directly to currency costs, and an external cost should not disappear because it is inconvenient to estimate. Use a consistent basis, convert explicitly when necessary, or mark a category N/A/0 with a reason tied to the scenario boundary.

1939. Guided practice

Build a two-scenario budget for a bounded game feature or prototype. Use a scope small enough to estimate in one sitting.

Step 1: Define the boundary

Write one sentence for each scenario:

• Included player-facing promise
• Explicit exclusions
• Evidence required before expanding the scope

Name the scenarios Focused and Expanded. The expanded scenario must add a concrete promise, not merely “better quality.”

Step 2: State the cost basis

Choose one consistent basis such as work units, person-days, or currency supported by a stated rate. For each major category, record:

• Estimated amount and unit
• Basis for the estimate
• Confidence: high, medium, or low
• Evidence still missing

Include implementation, integration, review, testing, correction, delivery, tools and services, and external costs where applicable. Do not count only the first draft produced.

Step 3: Complete the cost-category check

For each scenario, review this checklist:

Do not mark a category N/A merely because its estimate is uncertain. Mark it N/A only when the defined scope makes it inapplicable. A zero must state why no amount is expected. Check that no category is counted twice under another name.

Step 4: Add schedule and reserve

Give each scenario a bounded schedule with at least three phases. State the unit, reserve formula, what the reserve covers, and what it does not cover. Keep reserve separate from the base estimate.

Step 5: Compare the scenarios

Calculate the planning total for each scenario using the same unit basis. Then create a difference table:

Step 6: Run a sensitivity test

Select three material assumptions. Modify each independently by a stated amount, such as an additional phase, a longer review cycle, or a higher integration estimate. Recalculate the affected category, reserve, and planning total according to your stated policy. Rank the assumptions by impact.

Step 7: Make the decision

Write a recommendation of no more than 150 words. It must identify:

• The selected scenario
• The primary reason for selection
• The largest uncertainty
• The evidence or threshold that would justify expansion
• One consequence the team is deliberately accepting

This recommendation is the mandatory decision in the practice. Do not choose both scenarios merely to avoid the tradeoff.

Step 8: Version the budget and record the decision

Save the completed comparison as a numbered budget version, such as Budget v1. Record the date, the scenarios reviewed, the assumptions changed since the previous version, and the evidence used to support the recommendation. Create a short decision record containing:

• Decision date and budget version
• Recommended scenario
• Decision owner or responsible role
• Assumptions accepted for this decision
• Evidence reviewed
• Tradeoff deliberately accepted
• Threshold or evidence that would trigger a revision
• Next review point or condition

If you revise an assumption or calculation, create the next version rather than overwriting the previous one. Keep the prior version and decision record together so another developer can distinguish the original estimate, the change, and the reason for the change. This versioned record is part of the evidence, not administrative decoration.

1940. Validation / evidence

Your work is complete when another person can inspect it and answer these questions without guessing:

• What does each scenario promise?
• What is excluded from each scenario?
• What unit and formula were used?
• Is every relevant cost category present?
• Why is each N/A or zero entry justified?
• How was each major cost estimated?
• What schedule is assumed?
• What does the reserve cover?
• Which three assumptions are most sensitive?
• Why was one scenario recommended over the other?
• What evidence could change that recommendation?

The evidence to retain is one category-completeness checklist per scenario, one comparison table, one sensitivity table or calculation log, one short recommendation, and one versioned budget with its decision record. The versioned record must show what changed, why it changed, which evidence supported the change, and what condition would trigger another review. A correct total without visible units, assumptions, category decisions, or version history is insufficient.\n\nScore the produced budget with this practical rubric:\n\n| Criterion | Points | Full-credit evidence |\n| --- | ---: | --- |\n| Units and arithmetic | 4 | Units remain consistent, conversions use stated rates, totals are correct, and the reserve basis is explicit. |\n| Category completeness | 4 | Every required category is present with an amount or a scenario-based N/A/0 reason, including review and coordination costs where applicable. |\n| Traceable assumptions | 3 | Major estimates identify their basis, confidence, missing evidence, and reserve eligibility where relevant. |\n| Sensitivity calculations | 3 | Three material assumptions are changed independently; each affected category, reserve, and planning total is recalculated and ranked. |\n| Recommendation | 3 | One scenario is selected with a justified tradeoff, largest uncertainty, and evidence threshold for reconsideration. |\n| Versioned decision record | 3 | The budget version and decision record identify what changed, why, supporting evidence, the accepted tradeoff, and the next review trigger. |\n\nThe practical assessment is complete at 14 of 20 points or higher, with no zero in Units and arithmetic, Category completeness, or Versioned decision record.

1941. Key takeaways

• A budget becomes decision-ready when it compares bounded scenarios.
• Every relevant cost category must be included or explicitly justified as N/A/0.
• Arithmetic must use a consistent unit; conversions require a stated rate or formula.
• Sensitivity testing changes one material assumption at a time and records its effect.
• AI can audit structure and calculations, but the developer owns the assumptions and tradeoffs.
• A strong recommendation includes a condition for revisiting the decision.

1942. Next lesson

The next canonical lesson is Evidence before explanation in 4.16 — Postmortems (lesson-s4-4-16-01-evidence-before-explanation). Carry forward the final versioned budget, scenario comparison, category-completeness check, sensitivity ranking, recommendation, assumptions, decision record, and review trigger. The next lesson will use these materials to organize evidence before interpreting what happened.

1943. Knowledge check