A creative project timeline template that includes the client

The short answer

Build the timeline backwards from the delivery date. List the stages, give each its working days, and put every client review in as its own item with a set number of days and a due date for notes. Add a buffer before delivery of about 10 percent of the working days, and never less than a day. Mark which stages lock which decisions. Share the timeline with the client at the kickoff and agree that late reviews move the delivery day for day.

The template

Every row is one item on the plan. Client reviews are rows too.

Fill in the working days per stage from your own past jobs, then the dates. The columns that most templates leave out are the owner (so the client rows are visibly theirs) and what each review locks.

Work backwards from delivery

Start at the bottom. Put the delivery date in row 12. Count back the buffer, then the final review, then the final production, and so on to the top. If row 1 lands before today, the plan does not fit, and you know it before you sign rather than in week three.

When it does not fit, you have four levers: cut scope, add people (usually freelancers on defined pieces), shorten the client's review days with their agreement, or move the delivery. Shortening your own working days is not a lever. It is how projects go late quietly.

Client review days

Two working days per review is a sensible default for a small client team. Allow more when:

• The client has several stakeholders who all need to see it.
• Legal or brand compliance must review.
• The review falls over a weekend, a holiday or a board meeting.

Ask at the kickoff, and put the agreed days on the timeline with a due date and time for notes ("Notes by Thursday 17:00 CET"). Agree that if notes arrive late, every date after moves by the same number of days. Then hold to it calmly, in the weekly update.

Buffers

Put the buffer before delivery, as its own row, not spread invisibly across the stages. A buffer you can see is one you can protect; padding hidden in each stage gets used up by each stage. About 10 percent of the working days is a reasonable starting point, never less than a full day, more for jobs with render farm time or many deliverables.

Do not tell the client the buffer is spare time. It is for the export that fails, the render that needs a second pass and the last typo.

Worked example: three archviz stills

That is 28 working days, of which 10 are client time. Without the client rows, the same plan looks like 18 days, and that difference is the most common reason archviz deliveries are late. For more, see the archviz project management workflow.

Worked example: a 30-second motion piece

Brief and references, 2 days. Styleframes, 4 days, then 2 days of client review. Storyboard, 3 days, then 2 days of review. Animatic with scratch audio, 3 days, then 2 days of review. Animation blocking, 6 days, then 2 days of review. Polish, 5 days, then 2 days of review. Sound and final exports, 3 days, then 1 day of final approval. Buffer, 2 days. Delivery, 1 day. About 40 working days, 13 of them waiting on the client. Project management for a motion design studio covers the stages.

Worked example: a short brand film

Pre-production with script approval, locations and crew, 10 days including a 3-day script review. Shoot, 1 to 2 days. Ingest and assembly, 2 days. Rough cut, 4 days, then 2 days of review. Fine cut, 3 days, then 2 days of review. Grade, mix and graphics, 4 days. Final review, 2 days. Buffer and deliverables, 3 days. Around 35 working days. Video production project management covers each phase.

Common mistakes

Three show up again and again. Planning from the start date forward, so the delivery date is whatever the stages add up to instead of the date the client needs. Leaving the inputs row out, so the first week of the job is spent waiting for plans, logos or footage that nobody chased. And treating the final review as a formality, with no days on the plan, when it is often the review where a new stakeholder appears with notes.

Keeping the timeline alive

A timeline is only useful if it changes when reality does. Update it whenever a review is late, a stage runs over or the client adds scope, and send the new version in the weekly update with the reason. A client who has seen the timeline move week by week is rarely surprised by the final date. One who sees it for the first time on delivery day usually is. How to schedule a CGI project covers the scheduling detail behind each stage.

Doing this in OIO

OIO is project management for small studios, and the timeline is a view of the project rather than a separate file. Each row of the template is a ticket with a start and end date, an assignee and a status, and the timeline view shows them in order, client reviews included. Drag a ticket and its dates change. The same tickets show on the kanban for day-to-day work.

The client sees their deadlines and the tickets you share in their client space. A review ticket waiting on them shows a Needs feedback marker, with one reminder email a day, which you can switch off. Freelancers work from a link to their own ticket, with its dates, without a seat. OIO has no dependency links between tickets and does not move later dates automatically; when a review is late, you move the tickets after it.

Questions