Every promise has a cost

1917. Lesson identity

Module

4.15 — Budgets

Lesson

Every promise has a cost

Academic type

Concept

Schema type

text

Order

1

Estimated time

30–40 minutes, including practice

This lesson teaches you to inspect a project promise as a set of cost-bearing commitments. The goal is not to produce a precise financial forecast. The goal is to make omitted work visible before it becomes a schedule, quality, or review problem.

1918. Learning objective

After this lesson, you can identify missing cost categories, state the assumptions behind a project budget, and choose a proportionate response to uncertainty.

1919. Why this matters

A feature promise rarely names all the work required to deliver it. Production includes implementation, integration, testing, iteration, documentation, review, and rework. If those categories are absent, the budget creates a false picture of feasibility. A visible assumption can be challenged and revised; an omitted assumption silently becomes a risk.

1920. Prior knowledge

You should be able to describe a project feature as a concrete deliverable and distinguish planned work from completed work. Review the previous lesson, 4.14 L2 — Build a review-ready legal inventory, especially its practice of separating facts, evidence, obligations, and open questions. This lesson applies the same discipline to cost planning.

1921. Core concept

A budget is not only a list of purchases. It is a structured account of the work and uncertainty required to keep a promise.

For each promise, inspect at least these categories:

The categories are not a universal accounting standard. They are a completeness check. Select and adapt them to the project rather than pretending every project has identical costs.

1922. Mental model

Use the Promise → Work → Evidence → Reserve model:

1. Promise: What outcome is being committed to?
2. Work: What activities must happen for that outcome to exist?
3. Evidence: What review or test will show that the promise is met?
4. Reserve: What uncertainty remains, and what capacity is held for it?

A compact budget row can use this structure:

If a row contains only the promise and production task, it is probably incomplete.

1923. Concrete example

Consider the promise: “Add a new hostile encounter to the playable build.”

A narrow budget might list only enemy implementation and art. A more complete inspection asks:

• Is the encounter design specified, or is design time still unknown?
• Are animation, audio, effects, tuning, and integration included?
• What happens when the encounter interacts with existing weapons, saves, difficulty settings, or progression thresholds?
• Who will test readability, failure states, and edge cases?
• Is there time to revise the encounter after testing?
• Does any external or specialist review apply to the deliverable?
• Which assumptions would make the estimate invalid?

The revised budget does not need false precision. It can state: “Estimate assumes existing combat systems and reusable effects; compatibility testing and one tuning pass are included; unresolved animation requirements remain a risk; reserve capacity is held for integration findings.” That statement is more useful than a single confident number with hidden work.

1924. Common mistake

The common mistake is treating contingency as an admission that planning failed. Contingency is not a blank cheque and it should not hide poor analysis. It is a deliberate reserve for uncertainty that remains after known work has been identified. A second mistake is adding a generic percentage without explaining what uncertainty it covers. The reserve should be proportional to the risk and connected to explicit assumptions.

1925. Guided practice

Use this supplied small-project scope and promise list:

Small project scope: a compact playable prototype with one controllable character, one room, one interactable door, one simple objective, and a review-ready desktop build. The project uses existing engine systems and placeholder presentation assets. Currency estimates are not required; use hours, days, capacity units, or clearly labeled cost bands.

Promises:

1. The player can move through the room and reach the door.
2. Interacting with the door completes the objective when the required condition is met.
3. The prototype communicates success and failure states clearly.
4. A reviewer can install or open the build and verify the complete interaction.

Select one promise from the list and complete this table:

Then make both required decisions:

1. Identify one cost category that is missing from a deliberately narrow entry containing only the visible implementation task. Add that category and explain why the selected promise requires it.
2. Choose an uncertainty-response decision: hold a named reserve, reduce the promise to remove the exposure, or resolve an unresolved uncertainty before estimating. State which uncertainty your decision addresses. If you hold a reserve, also state a time or capacity amount, or a labeled capacity band. Do not provide a reserve amount or band for the other two responses, and do not use a generic percentage without naming the risk.

Your explanation must refer to the selected promise and its evidence, not to habit or a generic template.

1926. Validation / evidence

Your work is sufficient when another developer can read the budget row and answer four questions without guessing:

1. What outcome is promised?
2. What work is included and what work is excluded?
3. What evidence will show that the promise is met?
4. What assumption is documented, and what uncertainty is addressed by the selected response?

The row must also show the added cost category and the uncertainty-response decision you made from the supplied scope. If that decision is to hold a reserve, include its time or capacity amount, or a labeled capacity band; do not include a reserve amount or band for scope reduction or uncertainty resolution. If any answer requires an undocumented interpretation, revise the row and record the missing assumption.

1927. Key takeaways

• A project promise includes more than its visible implementation task.
• Production, verification, iteration, operations, and applicable review are distinct cost categories.
• Assumptions make the boundaries of an estimate inspectable.
• Contingency is a deliberate reserve for stated uncertainty, not a substitute for analysis.
• A useful budget connects each promise to work and evidence.

1928. Next lesson

Continue with 4.15 L2 — Build a decision-ready budget. Bring your completed budget row, added category, assumptions, and uncertainty-response decision as inputs for the next lesson.

1929. Knowledge check