Video production schedule: dependency math, slack and slippage tracking

A video production schedule is not the plan you agreed at kickoff. It is a dated dependency graph: every gate has a due date, every due date has a gate that cannot start without it, and the whole thing is re-derived whenever one date moves. The plan answers "what are we making". The schedule answers "which day does the client's review window open, and what breaks if it opens two days late".

If you are still deciding stages, shot lists and the shoot-day sign-off gate, that is video production planning, and it comes first. This article starts after the plan exists — when the dates start moving.

Four durations you need per deliverable

For each deliverable — one video, one cut, one client — you need four numbers. Only two of them are yours.

• Shoot or asset block. Working days until the footage, audio and graphics are all in hand. If the shoot belongs to someone else, this is a dependency, not a duration you get to estimate.
• Edit window. Working days from "all assets in hand" to "internal cut ready". Take this number from your last three comparable projects, not from how long you think it should take.
• Review round. The client's turnaround, in working days. You do not control it. If it is not written into the agreement, your schedule is a wish.
• Delivery. Final pass, export, upload, and the client's own publishing step if they own it.

Write all four in working days and be explicit about which days count. A "3-day review" that starts Friday afternoon is not three working days; it is five calendar days. Most schedule slippage is not slow editing. It is a duration counted in the wrong unit.

Dependency math: the longest path, and where parallel work is real

List the gates in order and ask one question of each: what cannot start until this finishes? Chain the answers and you get the longest path — the shortest possible time from today to delivery if nothing goes wrong.

Anything not on that chain is parallel work, and it has one property people forget: finishing it early does not move the delivery date. Finding the music in two days instead of four, while the rough cut takes five, changes nothing. Only shortening a gate on the longest path shortens the project.

Parallel work is also fake when the same person owns both branches. If one editor is cutting the rough cut and the social teaser at the same time, those are not parallel tasks — they are a queue, and the real duration is the sum. Check the owner of every branch before you claim a saving.

Two branches are worth running in parallel on most edits: music search and clearance, which is slow, blocking and partly outside your control; and packaging — thumbnail, title, description — which can be drafted while the client reviews round two.

Slack: the gap between the longest path and the hard deadline

Slack is the deadline minus the longest path, both in working days. A client who needs the file in four calendar weeks gives you 20 working days. If your longest path is 16.5, round it up to 17 and you have 3 days of slack.

Slack is not a buffer to spend. It is the amount of lateness you can absorb before the deadline becomes mathematically unreachable, and it should trigger action at a threshold rather than at zero. A workable rule: when slack drops below two working days, tell the client the risk in writing the same day. When it reaches zero, the conversation is about moving the date or cutting scope — not about working faster.

Slack against a hard deadline

Work out how many working days of lateness a project can absorb before the client deadline becomes unreachable.

Slack is the deadline minus the longest dependency path. A negative result means the deadline cannot be met with the current durations.

Assumptions: Illustrative planning inputs. Durations must come from your own past projects, and the result excludes public holidays, resource conflicts and days when the same person owns two parallel branches.

Worked example: Longest path (working days): 17 days; Deadline from today (working days): 20 days. Schedule slack: 3 working days.

Worked example: a four-week edit, gate by gate

Ten-minute branded documentary, one editor, one client. Durations are illustrative; swap in your own last three projects.

Longest path: 16.5 working days. Deadline: 20 working days. Slack: 3.5, which you plan against as 3.

Now move one date. Client review round one takes five working days instead of three — a two-day slip, straight off the slack, leaving 1.5. Round two then takes three days instead of two, leaving 0.5. Nothing has gone badly wrong. The edit is on time, the client answered both rounds, and the project is now one sick day from missing.

That is the point of doing the arithmetic before the work. The failure is invisible on the board, because no single card is late.

Tracking slippage without losing the baseline

A schedule that only shows current dates cannot tell you whether it is drifting. Keep two dates per gate: the baseline you committed to, and the current expectation. When a date moves, change the current date and leave the baseline alone.

On a board that is one due date field per card, plus the original date in a custom field or the card description. One card per gate is usually the right grain — ingest, rough cut, internal review, client round one, revision, client round two, final pass, delivery. Roughly eight cards for a four-week edit, each with an owner and a due date.

Two habits make the baseline survive a real week:

• Write the reason on the card when you move a date. "Client review, 2 days late, notes didn't arrive until Thursday" is what turns a slipping schedule into a conversation you can have early. A changed date with no reason is indistinguishable from a mistake.
• Never move a downstream date silently. If round one slips two days, either the delivery date moves or something upstream gets compressed. Both are decisions. Neither should be an accident.

Boards do not do this arithmetic for you — there is no dependency engine that recalculates a project when one card moves. You do the math and store the result as dates. That is a genuine tradeoff: more manual work, but a schedule anyone can read by opening the board.

Catching drift early: overdue triggers, calendar events and a 15-minute review

An overdue alert tells you a gate is late. It does not tell you a project is drifting, because drift is a sum, and nothing sums your slack automatically. Split the job: automations catch individual late gates, and a short weekly review catches the sum.

On a kloudboard board, automations run "when X happens, do Y" and open from the board's menu. The Templates tab has two ready-made ones that fit a production schedule: Ping the assignee when a card is overdue and Follow up on blocked cards. Both rely on the overdue trigger, which is checked hourly and fires once per due date — so a due date pushed out and back in can produce a second alert, and a card due today has not fired yet. Treat it as a nudge, not a guarantee.

Stage-entry triggers are the more useful signal here. When a card enters Client review, an automation can notify the assignees, post the review window as a comment, or create the follow-up task due the day the client's turnaround expires. You approve the automation before it saves, and AI steps inside an automation spend AI credits like any other generation.

If you connect Google Calendar, delivery dates and review windows can sit on a shared calendar as well as on the card, which helps when the client — not your team — is the party who has to act. Integrations lists what is currently available.

Then the weekly review, same slot every week, three questions:

1. Which gates are due in the next five working days, and is the owner still the right person?
2. Which dates moved since last week, and what is the total slip in working days?
3. Recompute slack per active project. Anything under two working days gets a message today.

That is the whole meeting. For the wider view of stalled and at-risk work across clients, creative project tracking covers the filtered views; for the version of these dates you send to the client, see the client-facing project timeline.

Start with the project you have open right now. Write down its eight gates, put a working-day duration against each, and add them up. If the total is larger than the deadline, you have found the problem while there is still time to have the conversation.