Manage risk before it becomes schedule fiction

1800. Lesson identity

Module

4.11 — Production

Lesson

Manage risk before it becomes schedule fiction

Academic type

Workflow

Schema type

mixed

Order

2 in the module

Estimated time

35–50 minutes, including practice

1801. Learning objective

After this lesson, you can identify production risks, connect them to milestone impacts, and assign an evidence-producing mitigation or discovery action, an owner, and a decision date.

1802. Why this matters

A milestone plan can look precise while depending on unknown technical, design, content, or integration conditions. When those conditions remain implicit, dates become claims rather than useful planning information. A visible risk register lets the team decide what to investigate, what to buffer, what to reduce, and when to escalate. It also gives AI a constrained analysis task instead of permission to invent certainty.

1803. Prior knowledge

You should already be able to convert a bounded scope into reviewable milestones with dependencies, integration checks, review points, rollback conditions, and completion evidence, as practiced in 4.11 L1 — Turn scope into milestones. You should also be able to record a product tradeoff from 4.10 L2 — Record the tradeoff. No complete production schedule is required.

1804. Core concept

A production risk is a condition that may prevent a planned result, change its cost or timing, or force a production decision. Risk management is not predicting the future perfectly. It is making uncertainty visible early enough to act on it.

For every meaningful risk, record five things:

1. Uncertainty: What is not yet known or reliable?
2. Impact: Which milestone, constraint, player-facing result, or schedule assumption could be affected?
3. Action: What mitigation, reduction, isolation, or discovery work will make the uncertainty smaller or less damaging?
4. Decision date: By when must the team decide, even if the uncertainty remains?
5. Owner and escalation: Who will investigate or act, and what condition requires a production decision beyond that person’s authority?

A risk is not the same as an issue. A risk might happen; an issue is already happening. Record both accurately, but do not disguise an active blocker as a future possibility. A task is an action. A risk register explains why that action matters, what it protects, and when its result must be evaluated.

1805. Mental model

Use RISK → RESPONSE → DATE → DECISION.

Add an explicit owner to the register. The owner is responsible for moving the risk toward evidence or a decision; ownership does not mean that person must perform every task.

Use three response categories:

• Discovery: investigate an unknown before committing to a larger body of work.
• Mitigation: reduce the probability or impact of an unfavorable outcome.
• Contingency: define the bounded alternative if the risk occurs.

A buffer is not empty time added to make a date look safer. A useful buffer has a reason, a boundary, and a trigger for consuming or releasing it. If discovery work has no decision date, it can expand indefinitely. If a buffer has no trigger, it becomes invisible slack. If escalation has no decision, it becomes notification without action.

1806. Concrete example

Suppose a milestone plan includes a bounded playable sequence. The team has not yet verified whether the new interaction remains readable when the player enters from every required route.

The point is not to assign a numerical score to every uncertainty. The point is to connect each risk to a milestone, an action that produces evidence, and a date at which someone must decide what happens next. A short discovery task may be more valuable than adding a large buffer to an untested assumption.

1807. AI-native workflow

Use AI to challenge the risk register, not to declare probability, effort, or priority without evidence.

1. Start with the accepted milestone table. Include its scope, exclusions, dependencies, integration checks, review points, rollback conditions, and schedule assumptions.
2. Ask AI to identify hidden assumptions, possible risks, missing discovery work, mitigation options, contingency paths, and decision dates. Tell it to separate facts from hypotheses and to avoid adding features or expanding scope.
3. Compare every suggestion against the actual project context. For each suggestion, record whether you accepted it, modified it, or rejected it and explain the evidence or constraint behind that decision. No particular distribution among those dispositions is required.
4. Ask AI to test whether each proposed response produces evidence before the decision date. A response that only says “monitor it” is incomplete unless it names what will be observed and when.
5. Finalize the register yourself. Record the owner, response, decision date, and escalation rule, then inspect whether the proposed buffer or discovery work changes the milestone plan honestly.

Example prompt:

Review this bounded milestone plan as a production risk critic. Identify uncertain conditions that could affect scope, dependencies, integration, review evidence, rollback, or schedule assumptions. For each candidate risk, propose focused discovery work, mitigation, or a bounded contingency; identify the evidence needed, an owner role, a decision date, and an escalation rule. Separate facts from hypotheses. Do not add features, platforms, content, or unrequested polish, and do not assign confidence scores without supporting evidence.

AI can expose omissions and alternative responses. It cannot observe the game, confirm the actual cost of discovery, or decide whether reducing the player-facing result is acceptable.

1808. Git workflow

Use Git to preserve the relationship between a risk decision and the production state that supported it. Before discovery or mitigation begins, identify the last accepted baseline. Keep exploratory changes identifiable so that a failed experiment can be isolated without confusing it with accepted work. At the decision date, record the evidence, the decision, and the relevant commit or review reference.

Do not use a commit as a substitute for a decision date or risk owner. Git can show what changed and preserve a known state; it cannot determine whether the risk is acceptable or whether the schedule should move.

1809. Common mistake

The most common mistake is recording risks as vague labels: “technical risk,” “UI risk,” or “may take longer.” Such entries cannot guide action. Another mistake is assigning a buffer without stating what uncertainty it covers or when the buffer is consumed. A third mistake is treating discovery as open-ended implementation. Discovery should answer a bounded question and produce evidence by a decision date. Finally, do not escalate every uncertainty immediately. Escalate when the unresolved condition exceeds the owner’s authority, threatens a milestone or constraint, or requires a scope, date, or resource decision.

1810. Guided practice

Use the milestone plan from 4.11 L1 — Turn scope into milestones.

1. List the assumptions behind each milestone’s dependency, integration check, review evidence, and rollback plan.
2. Select the three assumptions whose failure would most affect the player-facing result or the schedule.
3. Convert each selected assumption into a risk statement describing the uncertain condition and its possible impact.
4. For each risk, choose discovery, mitigation, contingency, or a justified combination.
5. Define one concrete action that produces evidence rather than merely observing the problem.
6. Assign an owner role and a decision date. If the exact calendar date is not yet set, anchor it to a named milestone review and state what must be scheduled.
7. Define the decision rule: accept, continue discovery, mitigate, reduce scope, isolate, or escalate.
8. Add a buffer only where you can state what uncertainty it covers, its boundary, and the trigger that consumes it.
9. Ask AI to challenge the register. Evaluate every suggestion and record whether you accepted, modified, or rejected it, with a reason grounded in evidence, scope, or constraints. Do not aim for a predetermined distribution of dispositions.
10. Update the milestone plan if the risk response changes a dependency, review point, completion criterion, or expected sequence.

Make one deliberate production decision: choose one risk to resolve through focused discovery rather than hiding it inside a larger schedule buffer. Explain what evidence will allow the team to stop investigating.

1811. Validation / evidence

Your submission is sufficient when it contains a risk register connected to the milestone plan with:

• at least three specific risks tied to named milestones or production assumptions;
• a clear uncertain condition and potential impact for every risk;
• a discovery, mitigation, or contingency response that produces evidence;
• an owner role and a decision date or named milestone review for every risk;
• a decision rule and escalation condition for every unresolved risk;
• a justified buffer only where its scope and consumption trigger are explicit;
• one documented discovery action that prevents uncertainty from being hidden in the schedule;
• an AI challenge record in which every suggestion is evaluated as accepted, modified, or rejected with a reason, without requiring any particular distribution;
• Git evidence identifying the relevant accepted baseline or experimental state.

Validate one risk by tracing it from the uncertain condition to its response, evidence, decision date, and escalation rule. Then simulate the risk occurring: state whether you mitigate, use the contingency, reduce scope, isolate the change, or escalate, and identify what happens to the affected milestone. The schedule is honest only when another person can see what is known, what is uncertain, what will be investigated, and when the team must decide.

1812. Key takeaways

• A risk register makes uncertainty actionable before it distorts the schedule.
• Every meaningful risk needs an uncertain condition, impact, response, owner, and decision date.
• Discovery work should answer a bounded question and produce evidence by a defined review point.
• Buffers require a reason, boundary, and consumption trigger; otherwise they hide uncertainty.
• Escalation is a decision path, not merely a notification.
• AI can challenge assumptions, but the developer owns the final risk response and production decision.
• Git preserves the baseline and evidence; it does not replace risk judgment.

1813. Next lesson

Continue to 4.11 L3 — Build the Stage 4 delivery plan.

1814. Knowledge check