A Realistic Delivery Schedule for Design Work

Almost every late design delivery follows the same script. The estimate was made in working days, the deadline was agreed as a calendar date, and nobody converted between the two until the last week. Then a public holiday appears, a review round takes four days instead of one, and a project that looked comfortable is suddenly a week behind.

A realistic schedule is not a more optimistic estimate. It is a short planning routine that accounts for the calendar, the review loop and the parts of the work that no estimate captures. This guide shows that routine with a small worked example. The arithmetic is simple enough to do by hand; the point is to do it deliberately.

Start from the deliverable, not from the hours

The first step is to write down what “delivered” means in concrete terms. “The website design” is not a deliverable. “Five page layouts in a shared file, plus exported images in the agreed sizes, plus one round of text corrections after review” is a deliverable. The difference matters because the second version reveals work that the first one hides: exporting images, packaging source files, and a review pass all consume days.

For each deliverable, list the work stages that must happen in order:

1. Inputs received and checked. The brief, the source files, the copy, the brand assets. A schedule that starts before the inputs are actually usable is a schedule built on an assumption.
2. First draft. The bulk of creative work.
3. Review. Waiting for feedback is part of the elapsed time, even though it is not part of your working time.
4. Revisions. Usually one included round, sometimes two. Decide the number before the project starts.
5. Finalisation. Packaging, exporting, naming files, sending the handoff.

Only stages 2 and 4 are mostly your own working time. Stage 1 depends on the client, stage 3 depends on the client, and stage 5 is always underestimated.

Convert everything into two columns

A workable schedule is a table with two columns: working days and calendar dates. Fill in the working days first, then convert them to dates, not the other way round.

Here is the working-day calculation that trips people up. If today is Monday and the estimate is 10 working days, the work finishes at the end of the second Friday — provided no public holidays fall inside those two weeks. Ten calendar days would have finished the following Wednesday and quietly skipped a weekend of work that was never planned in the first place.

Two tools make the conversion less error-prone:

• The days between dates calculator gives the elapsed and inclusive number of days between two dates, which is exactly what you need to check “is this still two weeks away?”.
• The add or subtract days calculator answers the forward question: “delivery is promised in 15 working days — what date is that?”.

Neither tool knows your calendar. Public holidays, your own days off and the client’s availability still have to be applied by hand. But doing the arithmetic in seconds makes it much more likely that you will actually re-check the schedule when something moves.

Count the review loop explicitly

The most common planning error is not a bad estimate of creative work. It is treating review as instant. Realistically, a review round looks like this:

• You send the draft on Monday afternoon.
• The client reads it on Wednesday.
• Feedback arrives across two messages on Wednesday and Thursday.
• You clarify one open question on Thursday afternoon and receive the answer on Friday.
• Revisions happen the following Monday.

That is a full working week between “draft sent” and “revisions started”, and it is completely normal. Build it into the plan as elapsed calendar time, then subtract it from the working days you promised.

For a project with two review rounds, the elapsed time can be half the calendar duration even when the working time is only a few days. The schedule has to show both numbers or it will be wrong in a way that looks like bad luck.

Decide what the buffer covers

Buffer is not a vague safety margin. Give it a job so it can be reasoned about:

• Input buffer. Time for late source files, missing logos or copy that arrives in the wrong format. This one protects the start date.
• Review buffer. Absorbs a late or fragmented feedback round. This protects the middle.
• Handoff buffer. Covers exports, re-exports after a last-minute colour change, and packaging. This protects the delivery date.

A common starting point is one to two working days per buffer on a small project, or around 20 percent of the estimated working time on a larger one. The right number depends on the client and the complexity of the approval chain, but writing the buffer down as a named line item changes the conversation: it stops being padding and becomes part of the plan.

Use a worked example

A one-page layout plus three social variations for a new client:

Stage	Working days	Calendar impact
Wait for final copy and logo files	0 working, 3 elapsed	Start delayed by 3 days
Set up document and build layout	3	—
Build three social variations	2	—
First review round	0 working, 5 elapsed	Often the longest single item
Revisions	2	—
Second review round	0 working, 3 elapsed	—
Final exports and handoff	1	—
Buffers (inputs, review, handoff)	2	—

The working total is 10 days. The elapsed total is at least 18 calendar days before weekends are considered. Promising “about two weeks” is therefore optimistic, and promising “two weeks of work” without a date is ambiguous. A schedule that states both — 10 working days, delivery on a specific date three weeks out, with the review rounds shown explicitly — is the honest version.

This is also where the work hours calculator earns its place. If a project is quoted as “about a day and a half” of work, converting the estimate into hours and checking it against the actual working time you have available that week is a useful sanity check. A plan that assumes eight uninterrupted hours a day is a plan that ignores email, calls and the rest of your projects.

Re-plan when something moves, not afterwards

A delivery schedule is a living document for exactly as long as the project is running. When a review round slips by three days, re-run the conversion the same day and tell the client the new date in the same message. That single habit prevents most deadline conflicts: the client sees the date move while there is still time to make a decision, instead of discovering it at the end.

Two rules keep re-planning honest:

1. Change the date, never the scope silently. If the date cannot move, the scope has to shrink. Decide which one changes and write it down.
2. Keep the review rounds visible. A revised schedule that hides the second review round is not a revision, it is a new optimistic guess.

A short checklist before you promise a date

1. Deliverable defined as a concrete list, including exports and packaging.
2. Inputs listed, with the date each input must arrive.
3. Work estimated in working days, per stage.
4. Review rounds counted as elapsed calendar days, with a realistic response time.
5. Buffers named and sized, not assumed.
6. Working days converted to a calendar date, with weekends and public holidays checked.
7. The delivery date stated together with the assumptions behind it: number of review rounds, what counts as a revision, and when the clock starts.

None of that is complicated, and all of it takes about fifteen minutes. It is also the difference between a date you can keep and a date you apologise for.