Production schedule

What a production schedule is

A production schedule is a dated list of every piece of content currently in progress. One row per piece, one column per stage, and against each stage a person, a due date and a note saying what the piece is waiting on. It is a working document, updated weekly, and it is meant to be looked at rather than admired.

It is not a calendar. A content calendar says what publishes when, and an editorial calendar does the same job for a blog. Both describe the finish line. A production schedule describes everything behind it: who is doing what by when, with the dependencies made visible, so a photograph running a week late shows up as a problem in week two rather than as a missed post in week six. Businesses that publish nothing usually own a calendar and have never had a schedule.

When you need one

You need one as soon as a piece of content passes through more than one pair of hands. Two contributors and a photographer is enough. The moment a piece has a dependency, somebody has to be able to see it, and nobody can see it inside an email thread.

The second case is a fixed date you cannot move: a shop opening, a season, a trade show, a site going live. Work backwards from that date and you find out in week one whether the plan is possible. Work forwards and you find out in the last week that it was not.

You do not need this if one person writes and publishes one post a month on their own. The deadline is the publish date, and the useful purchase is queueing the posts in advance so a holiday does not stop them. Nor do you need it if the real problem is that nothing has been decided yet, in which case the calendar comes first and this follows it.

What goes in it

• Every piece in flight. Not the ideas list. The pieces that have been committed to, each with the date it is meant to be public and the person who owns the piece as a whole.
• The stages, with an owner and a date each. Brief, draft, edit, check, approve, build, publish, or whatever your own process calls them. A stage with no name against it is the stage that will stall.
• The dependencies. What each piece needs from somewhere else before it can move: photographs, a price list, a quote from a customer, a diagram, a legal reading. Each dependency has its own date, earlier than the stage that needs it.
• The backward dates. For anything with a fixed publish date, every stage dated backwards from it, so the first missed date is visible weeks before the last one.
• The state. One short phrase per piece saying where it actually is and what it is waiting on. This is the column people read, and it is the one that stops a status meeting being needed.

What you get

The schedule itself. One shared document, one row per piece, in whatever project tool you already use or on a shared drive. It is yours, not mine, and it keeps working whether or not I am still involved.

A weekly update. Where I am running it, the rows are updated once a week on the same day, and anything that has slipped is marked before the deadline rather than after it.

The dependency list. A short separate page of the things that have to be arranged early: shoot dates, interviews, a supplier's figures, anyone's holiday. These are what actually cause late content.

A blank template. The same structure empty, so the next quarter starts from something rather than from nothing.

A worked example

An illustration, not a client. A family-run garden centre outside a Canadian city plans a spring push: twenty-four product pages, six planting guides, an email to their list every fortnight from March, and new photography of the greenhouses. Everything has to be live before the first warm weekend, and the owner has been treating that as one deadline.

The schedule breaks it into thirty-two rows and immediately shows two problems. The photography is booked for late April, but eighteen of the twenty-four product pages need pictures, so the shoot has to move to the first week of March, before the plants look their best and after a conversation about what that means. The second problem is the guides: the horticulturist who has to check them is on leave for two weeks in February, which nobody had connected to anything. Both are visible in week one. The shoot moves, the guides are drafted a fortnight earlier, and the push goes out complete rather than two-thirds complete with a promise about the rest.

How it runs

1. A half-hour call. What is committed, who is involved, and what the fixed dates are. No charge.
2. A fixed price in writing. Agreed before anything starts, whether it is a one-off build or a standing weekly job.
3. The inputs. Your plan or calendar, the list of people, and anything already half-written. If there is no plan yet, I say so on the call.
4. The build. Two to four working days for a first schedule of thirty or so pieces, including one pass to find the dependencies nobody mentioned.
5. The read-through. Half an hour going through it with the people named on it, because a date somebody has not seen is not a commitment.
6. The weekly update. Optional. Same day each week, with anything slipping flagged in writing.

What it costs

Quoted as a fixed price in CAD after the half-hour call. A one-off schedule built for a launch or a quarter is priced as a single job; running and updating it week to week is priced monthly, and at that point most businesses find it sits inside the wider pipeline service rather than standing alone. The pricing page shows the four ways I work. Whichever it is, the number is fixed in writing before anything starts.

What happens next

A finished schedule usually exposes the stage that is genuinely broken, and most often that stage is sign-off, which is handled by chasing the named approvers to a deadline. If the rows depend on freelancers, those people need briefing and chasing under contractor coordination. And if the same argument about who owns which stage keeps recurring, the underlying process needs writing down once in workflow design. None of that is assumed. The schedule is a complete piece of work on its own and it is yours to run.