Production Schedules That Survive Real Deadlines

How to build a schedule with the contingency in the right places, which dependencies actually control the date, and what to do when it slips.

Most video schedules are built by working backwards from the delivery date and allocating time to each stage until the days are used up. This produces a plan with no slack, in which every stage must go correctly for the date to hold. Since something always goes wrong, the schedule is a prediction of failure with a date attached.

The better method is to identify the critical path first: the sequence of dependencies that actually controls the end date. In most video projects this is not the edit, which is elastic, but the fixed points: the shoot day, the availability of a location or a person, the approval windows, and the render time. Everything else can move around these, and the contingency belongs against them rather than being spread evenly.

Approval windows are the dependency most often left out of the schedule entirely, and they are frequently the largest. A project with three review rounds and an organisation that takes a week to respond has three weeks of schedule that belongs to the client, not the studio. Putting those weeks in the plan explicitly, with dates, converts an invisible risk into a shared commitment.

The single named approver is the mechanism that makes those windows hold. A project with an unnamed approver discovers its stakeholders sequentially, each after work has been done. Mirzaei et al. (2025) argue that project methodologies should be customised to the specific project rather than applied uniformly, and the number of people who can say no is the factor that should most change how much process a project carries.

Contingency should be placed where the risk is rather than added at the end. A day held after the shoot for weather or a failed setup is useful; a week of slack before delivery is not, because by then the problems have already compounded. The rule that works is to place buffer immediately after each irreversible stage: after the shoot, after picture lock, after the first render.

Render and generation time are genuinely inelastic and should be treated as fixed rather than compressible. Frames take the time they take, and a difficult generated shot takes the attempts it takes. Scheduling these as though additional effort makes them faster is the most common technical planning error, and the correct response to a compressed timeline is to reduce the number of environments or shots rather than to assume the same work will happen quicker.

Parallelisation is the legitimate compression tool and it has limits. Graphics can be built while the edit is in progress. Music can be selected during production. Subtitle preparation can begin at picture lock. What cannot be parallelised is anything that depends on a locked picture, which is why picture lock is the most important date in the schedule and why moving it moves everything downstream.

For event work the schedule inverts, because the date is immovable and everything else must fit. A workable structure locks content five working days before the event, leaves two days for revisions, and reserves the final day for a technical rehearsal on the actual system. Compressing this is possible and the first thing to disappear is the rehearsal, which is the item that most reliably prevents a public failure.

When a schedule does slip, and it will, the decision should be made explicitly rather than absorbed. The options are to extend the date, reduce the scope, add capacity at cost, or accept reduced quality, and one of them is going to happen whether or not it is chosen. Naming the choice to the client, in writing, at the moment it becomes necessary, is what preserves the relationship. Absorbing the slip silently and delivering something weaker on time is the version that damages it.

The schedule should be a document both parties look at rather than a studio internal artefact. A shared plan naming every stage, the owner, the date and the dependency makes it obvious when a client review is the thing holding the project, which is a conversation that is much easier to have in advance than in retrospect.

References

Mirzaei, M., Mabin, V. J., & Zwikael, O. (2025). Customising hybrid project management methodologies. Production Planning & Control, 36(9), 1188–1205. https://doi.org/10.1080/09537287.2024.2349231