When a Vendor Misses a Milestone: A Producer’s Recovery Playbook

When an outsourcing vendor misses a milestone, requesting a new date is not enough. First establish what is finished, what is blocking the remaining work, and which changes could restore a workable schedule. Communicate the immediate impact while you investigate; a revised commitment needs evidence, but affected teams should not wait for a complete diagnosis.

If you own the vendor decision, a missed milestone tests your scorecard, your MSA and your exit plan at once. If you run production, affected teams need an updated view of asset availability and schedule risk. This guide starts after the miss, when the date has passed or a batch has failed review. The warning signs that come before it are covered in our guide to keeping an outsourced art team on schedule, and we do not repeat them here.

What is a vendor recovery plan? It is an operational plan for addressing a missed delivery or acceptance target. It records asset-level status, supported causes and unresolved questions, the chosen changes to scope, sequence, capacity or dates, a forecast with assumptions, named owners, and checkpoints for reviewing progress. Changes to contractual commitments follow the agreement’s change procedure.

What “Missed” Actually Means: Four States, Four Responses

Use these four working labels to describe the delivery state. They can overlap: a late batch may also be partial or fail review. Record which delivery or acceptance target was missed, then assess the effect on dependent work.

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

• Late but complete. The batch arrived after the date and passes the agreed criteria. Record the variance and check its effect on dependent work and later milestones. If the impact has been absorbed, a brief review may be enough. If downstream dates remain at risk, plan the recovery even though this batch is complete.
• Delivered but rejected. The batch fails the agreed criteria. Record the specific failures and use the consolidated feedback process described in our quality control guide. A recovery plan is needed when correction work threatens an agreed acceptance date or dependent activity; repeated failures are not a prerequisite.
• Partial. Some assets passed, and the rest did not arrive or did not pass. A per-asset plan can separate accepted work from outstanding items and support partial acceptance where appropriate.
• Silent. No delivery and no reliable status. Treat progress as unconfirmed. Use the agreed escalation route promptly, with urgency based on production impact and response commitments. Protect dependent work while the named contacts establish status.

The stakes grow with each step of a poor response. A new date accepted without a diagnosis can reproduce its cause: if the plan was unrealistic or your own review queue was the bottleneck, the next milestone inherits the same problem with less room. A quietly rewritten schedule hides the variance, so nobody can tell at the third milestone whether this was a one-off or a pattern. A replacement chosen in frustration brings a new onboarding curve into a production that is already behind.

For an outsource decision-maker, that chain ends at the exit clause in your MSA: a decision made without evidence is hard to defend to your own management and harder to enforce against the vendor. For a producer, it ends in the capacity plan: assets that level design, animation or engine integration were waiting for arrive later than the forecast those teams were given, and each team re-plans on its own. None of this needs a dramatic failure. A batch that is slightly late and misunderstood can cost more than one that is clearly late and understood.

The Initial Review Window: Status, Impact and Blockers in Parallel

Use the first three working days as an initial review window, not a waiting period or a universal deadline. Start status collection, impact communication, diagnosis and removal of obvious blockers in parallel. Shorten the window when a release dependency or an agreement requires faster action.

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

1. Get asset-level status. Record not started, in progress with its current stage, delivered awaiting review, changes required, or accepted. Track blockers separately, with the dependency, responsible contact and next action. Include the latest file revision and the date of the status update. Keep vendor-reported progress distinguishable from reviewer-confirmed status.
2. Control changes to the affected batch. Record each change, its approval, the affected revisions and its schedule impact. Defer optional directions and variants while the recovery plan is being established. Address urgent corrections and changes needed to remove blockers promptly, using the agreed change procedure and updating the forecast.
3. Keep the original baseline visible. Record the variance next to the revised forecast. Overwriting the plan removes the evidence you need to tell a one-off from a pattern.
4. Notify affected teams promptly. Tell dependent teams what is confirmed, what remains uncertain, which activities are affected and when the next update will arrive. Do not wait for a revised delivery commitment before communicating the impact.
5. Name one owner on each side. Each needs the authority to decide, and both join one working call inside the window. Escalation goes to the senior contacts already named in your SOW.
6. Separate facts from interpretations. Record timestamps, file revisions, decisions and unresolved disagreements. Avoid unsupported accusations, while preserving documented concerns that need investigation.

By the end of the initial window, aim to have a current status record, immediate containment actions and a next update time. Mark any unconfirmed status explicitly rather than filling the gaps with assumptions.

Triage: Whose Delay Is It?

Our guide to vendor risk management in game art outsourcing names three usual causes behind a missed deadline: the vendor committed more capacity than it had, acceptance criteria were not specific enough to avoid a late rejection, or a dependency was never mapped. Two more belong on the list when you investigate after the fact: delay on your own side, and planning assumptions that did not hold. Several causes may contribute, and their importance can change by asset group. Treat the table as a set of checks, not a diagnosis. Identify supported contributors, show how each affected the schedule, and keep unresolved explanations separate. Do not force a secondary cause where the evidence does not support one.

Possible contributor	Evidence to examine	First action	Limit of the inference
Vendor capacity or execution	Stage progress, assigned availability, work-in-progress revisions, missed commitments and reported staffing changes	Ask for a credible resource plan and verify progress against the files	Slow replies or a shift toward simpler assets do not establish a capacity shortage on their own
Specification, acceptance or quality	Approved brief versions, reference changes, conflicting feedback, repeated defects and interpretations of criteria	Compare failing assets with the agreed criteria; clarify ambiguity and consolidate feedback	Repeated defects can reflect execution problems even when the specification is clear
Client review or inputs	Delivery timestamps, review waits, unanswered questions and late references or builds	Clear actionable blockers and publish review commitments	A late client response explains delay only where it prevented scheduled work or acceptance
Dependencies	Blocked tasks, prerequisites, ownership and expected availability	Map the affected sequence and progress work that is genuinely independent	A blocker on one asset does not explain unrelated delays elsewhere
Planning assumptions	Remaining work by stage and complexity, review effort, resource availability and prior comparable throughput	Reforecast with explicit assumptions and identify the constraint	Historical batch averages may not represent the remaining asset mix

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

For the response-time evidence, compare actual reply times with the response tiers in your agreement. If you have none, the tiered response structure in our guide to distant studios provides a practical starting structure to adapt to your engagement.

Consider an illustrative scenario, not a case study or a result from a Nasty Rodent project. An environment batch for a PC tactical title arrives late. Blockout passed on schedule, but a later client approval exceeded the agreed review window and a reference changed mid-batch. Check whether the approval wait blocked scheduled work and which tasks the reference change added. Where the records support those links, client review and changed scope explain part of the slip. Continue checking vendor progress before assigning the remaining delay or choosing the recovery action.

Share the triage with the vendor before you share the plan. A vendor that sees its own evidence next to yours can correct the facts, and a shared record makes the plan easier to agree.

Recovery Options: What You Can Trade

A recovery plan buys time by spending something else: scope, order, money, risk or your own team’s hours. Say which currency you are spending before you agree to anything, because an unnamed trade turns into a hidden cost later. The table lists the options producers use, what each one fits, what it costs beyond the obvious, and what to put in writing. It is a cost map, not a ranking, and combinations are normal.

Option	Fits when	Hidden cost	Put in writing
Prioritize schedule-driving assets	Their availability constrains a dependent activity or a key milestone	Deferred work may create another constraint later	The revised sequence, dependency assumptions and forecast for affected work
Trade scope for time	A date is fixed by a release, certification or publisher milestone	Deferred work may require later capacity; removing work changes the agreed deliverables, and simplification may affect visual consistency	Which assets are deferred, simplified or removed, the effect on payment and acceptance criteria, and any agreed later delivery
Partial acceptance	A usable subset passes its applicable criteria and the agreement permits separate acceptance	Shared dependencies or incomplete integration may limit immediate use	The accepted revisions, outstanding work, exceptions and payment consequences
Add capacity at the same vendor	The cause is capacity and the vendor can show who will work on the batch	New artists need briefing and review time from reviewers who are already behind	Assigned roles, committed availability, start dates and first-asset reviewers
Add a parallel source for one asset family	The family is independent and well specified	Style consistency, a second onboarding and extra coordination	The specification, the handoff files and who owns the consistency review
Finish part of the work internally	Your team has the required files, permissions, capacity and technical context	Internal work is displaced; responsibility for later changes needs clarification	The transferred files, revised scope, payment arrangements and remaining obligations
Move the date	The original commitment can be changed by the authorized parties	Downstream work may need replanning, depending on dependencies and available slack	The approved commitment change, affected forecasts and retained history

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

Scope trades should pass through the change request procedure described in our guide to game art scope creep, so that the recovery does not become the next source of untracked scope.

Additional capacity helps when the work can be divided and the added team can become productive before the relevant deadline. Account for briefing, shared dependencies, review capacity and integration. Experienced artists already familiar with the pipeline may help the current batch; others may contribute mainly to later milestones. Test the expected benefit against the actual bottleneck.

A Concise Recovery Plan: Facts, Forecast, Owners, Checkpoints

Keep the decision summary concise; one page can work, with supporting records linked separately. Include:

1. Current facts. Asset status, revisions and the effect on dependent work.
2. Supported causes and open questions. Evidence, schedule impact and disputed points.
3. Chosen changes. Scope, sequence, resources or dates, with their costs and approvals.
4. Forecast and assumptions. Estimate remaining work by category, complexity and stage. Use comparable throughput as a check, then account for review, rework, dependencies and available resources. A batch-wide asset count divided by an average rate is only a rough check for comparable work under stable conditions.
5. Owners. Who performs the work, makes decisions and removes each blocker.
6. Checkpoints. Deliverables, review criteria, dates and actions if a checkpoint is missed.
7. Recovery and escalation criteria. What demonstrates a workable schedule and what triggers reconsideration.

Check the agreement’s notice, correction and termination requirements immediately. Do not wait for both sides to agree on the diagnosis before checking or meeting any required notice deadline. Have the responsible commercial or legal owner handle formal notices while production continues the recovery work. The RFP and SOW guide covers how to write late-delivery, cure-period and termination clauses.

If the cooperation ends early, who owns partially completed work depends on the transfer trigger written into the agreement. Our guide to IP, NDA and liability terms covers that question.

Your own side is part of the plan. Our published Terms & Conditions list timely feedback among the client’s responsibilities and note that delays on the client’s side may affect delivery dates, which is why the triage above checks your queue first.

Continue, Supplement or Replace: Conditions for the Decision

The decision is easier when you treat it as three paths with conditions, not as a number of missed milestones. Our vendor onboarding guide treats one underperforming milestone as data and repeated ones as a trend. The conditions below add the cause to that count.

• Continue when the remaining work and resource plan are credible, identified blockers are being resolved, and checkpoint evidence supports the revised forecast.
• Supplement when a separable part of the work can benefit from additional capacity and the coordination, review and integration effort is justified.
• Consider replacement when material failures remain unresolved, the recovery plan is not credible, progress cannot be verified, or the vendor cannot support required work. Assess severity, available alternatives and the agreement’s process; communication concerns alone do not automatically require termination.

These are conditions, not thresholds. The right trigger depends on the cause and on your contract, and a number copied from another production can point the wrong way.

Before changing vendors, establish which files and documentation are available for transfer, what access or payment conditions apply, and which remaining work the replacement can actually take over. Check the agreement’s transition requirements and the cost of onboarding, validation and integration. Our framework for in-house versus outsourced art helps compare those production costs.

If the answer is a second studio for one asset family, expect the same discipline you asked of the first. When we start work through our game art outsourcing services, regular milestone reviews and feedback rounds are defined in the project scope before production starts, as our published terms describe, and delivery formats are fixed during planning.

Telling Your Stakeholders: What a Revised Forecast Should Contain

Stakeholders and dependent teams do not need the full triage. They need five things, in this order:

1. Where we are. Facts per asset group, not a percentage.
2. Why. The supported causes in a sentence or two, with your own side named if it is part of it.
3. What we are trading. Scope, order, capacity or date, and the cost of that choice.
4. How confident we are. The next date, what could break it, and when you will know.
5. What we need. Decisions, approvals or access that sit outside production.

Send the revised forecast with the original baseline visible beside it. A date that comes with its variance is easier to trust than a date that appears from nowhere, and it protects you if the recovery needs a second revision. Communicate the slip and current impact promptly. If the evidence is incomplete, provide a provisional range or explain what is still needed to forecast, with an explicit next update time. Distinguish the working forecast from an approved revised commitment, and update both as the evidence changes.

Run This Check Before You Declare a Recovery

• [ ] The state of the miss (late, rejected, partial or silent) is recorded, with the missed target named.
• [ ] Asset-level status is recorded, with confirmed progress separated from unverified reports.
• [ ] The original baseline stays visible next to the revised forecast.
• [ ] Affected teams were told what is confirmed and what is uncertain, with a next update time.
• [ ] Supported causes, disputed points and unresolved questions are documented.
• [ ] The chosen trade and its cost are written down.
• [ ] The forecast records its assumptions, dependencies and review requirements.
• [ ] Each action has an owner; each checkpoint has deliverables, criteria and a next step.
• [ ] Required contractual notices and approvals are handled by the responsible owner.
• [ ] The trigger for supplementing or replacing is written next to the plan.

Use this alongside the agreement and production records. The checklist helps expose gaps; recovery should be assessed against actual progress, resolved blockers and a credible forecast.

Keep the Recovery Plan Grounded in Evidence

A workable recovery starts with current status, an assessment of schedule impact and actions that address the actual constraints. Keep affected teams informed while you investigate. Update the forecast as evidence improves, and make any revised commitment explicit. Agreement on the facts helps coordination, but recovery still depends on available capacity, resolved dependencies and delivery against the plan.

Inherited a slipping art schedule? Send your milestone plan and current status to sales@nastyrodent.com. We usually reply within 1–2 business days.