Missed Game Development Milestone: A Recovery Plan

A missed milestone is not a signal to push the same plan harder. For a small game team, the useful response is to compare the promised playable outcome with what actually exists, identify the cause of the slip, and rebuild the next milestone from current evidence. Keep the original date as history; create a recovery plan with reduced or resequenced scope, explicit owners, and one new review point.

Start with the gap, not the explanation

The first recovery meeting should answer one question: what part of the promised playable result is missing?

Do not begin with hours worked or percentage complete. Those numbers do not tell you what must change.

Compare three things:

• the original milestone outcome;
• the build or assets that exist now;
• the minimum missing work required to make the outcome testable.

If the milestone was “a new player can complete the first combat loop with final input and readable feedback,” then “combat is 85% done” is not useful. Name the missing evidence: controller remapping fails, hit feedback is placeholder, or the encounter cannot reach its end state.

The PMI project-recovery guidance recommends rebuilding troubled plans around defined scope and deliverables, prioritized risks, a fresh basis of estimate, and a revised milestone schedule. That is more useful than treating the old plan as something the team can catch up to through effort alone.

Find the cause before you pick the fix

A missed milestone usually has more than one symptom. Choose the cause that changed the plan.

Common categories for a small game team are:

• underestimated work: the task was larger than the evidence justified;
• scope growth: new work entered without an equivalent cut;
• dependency failure: a required handoff arrived late or unusable;
• quality rework: “done” work failed integration or acceptance;
• capacity change: someone became unavailable;
• unresolved design risk: implementation continued while a core decision was still moving.

Game-development postmortems show why this distinction matters. In the Magicka postmortem, Arrowhead describes repeatedly revising an unrealistic schedule while still relying on crunch and optimism; the team later gained more control after adopting better task estimation and progress tracking. A classic Asheron’s Call postmortem similarly describes recurring missed milestones and eventually re-evaluating the feature set.

The fix should match the cause. A dependency problem needs a changed handoff or fallback. A scope problem needs a cut. An estimation problem needs new evidence.

If dependencies caused the slip, revisit the dependency map before the next milestone instead of copying the same sequence forward.

Build a recovery milestone, not a catch-up milestone

Do not put all unfinished work plus the next milestone into one larger bucket. That creates a catch-up milestone with more work and less confidence.

Use this recovery template:

• Original playable proof: what the missed milestone was supposed to prove.
• Current proof: what the latest build can demonstrate now.
• Missing evidence: the smallest gaps that prevent acceptance.
• Cause: one primary cause for each gap.
• Decision: finish, cut, defer, replace, or split.
• Owner: one person accountable for the next observable result.
• New acceptance check: what must be true in the build.
• Review date: when the team will judge the recovery build.
• Deferred work: everything removed from the recovery scope.

Keep the original milestone in the record. Atlassian’s current scope-creep guidance recommends maintaining a visible baseline and making changes through explicit trade-offs: adding work should mean changing scope, schedule, or resources rather than pretending the original constraints still hold.

Example: recover without turning one miss into three

Consider a hypothetical four-person team building a co-op action game.

Their milestone promised one complete mission with online join, combat, a revive mechanic, and a results screen. On review day, combat works and players can join, but revive desynchronizes and the results screen sometimes fails after a reconnect.

The team first considers moving the date one week and keeping the next mission on the same schedule. That is the dangerous option: unfinished networking work now competes with new content.

Instead, they create a recovery milestone:

• keep the same mission;
• make revive synchronization the only must-fix gameplay risk;
• accept the reconnect edge case as a known limitation for this internal build;
• defer the second mission entirely;
• require three clean two-player runs from join through results before closing the recovery milestone.

This does not guarantee the original release plan is still achievable. It does produce new evidence about networking reliability and gives the next planning decision a firmer basis.

If the original milestone itself was too broad, rebuild it using the playable milestone method before committing to another date.

Do not hide the miss with crunch or a silent rebaseline

Three recovery mistakes are especially costly.

First, moving the date without changing the plan preserves the cause of the miss.

Second, using overtime as the primary recovery mechanism converts planning uncertainty into fatigue. The Magicka postmortem is a useful warning: repeated crunch did not make unrealistic milestones realistic.

Third, rewriting history makes future estimates worse. Keep the original commitment, the actual result, and the recovery decision visible.

A missed milestone is useful only if it changes the next plan. Record the gap, choose the cause, cut or resequence the work, and review a smaller recovery build before resuming normal production. If PlayablePlan is where your team keeps its production plan, use the recovery milestone to preserve those decisions beside the work instead of letting the old schedule quietly disappear.