Editorial Production Planner

What this tool does

CM8-384 shows the content pipeline as a board, finds the stage where work piles up, and measures how long a piece really takes from brief to published — including the large part of that time when nothing is happening to it at all.

Everything runs inside this single file — no account, no upload, no network request of any kind.

Not a content calendar

A content calendar answers what are we publishing and when. This answers why is nothing coming out. They are different problems and they have different tools; use this one when the calendar keeps slipping.

The one field that matters

Entered this stage on. Everything here depends on it, and it is the field people forget.

Update it whenever a piece moves. A board nobody moves shows a healthy pipeline for ever, and the tool cannot tell the difference between a piece that moved yesterday and one that has sat untouched since March.

Finding the bottleneck

Every pipeline has exactly one constraint, and it is almost always the stage holding the most pieces. Work arrives faster than that stage can clear it, so a queue forms in front of it.

In the sample it is review: four pieces with one reviewer, and everything upstream is being written faster than it can be approved. The board makes this visible in a way a list never does.

Adding capacity anywhere except the bottleneck makes things worse. More writers feeding a blocked review stage produces a bigger pile, a longer wait, and staler content — not more publishing.

Why a limit helps

Set a limit on how many pieces may sit in any one stage. It sounds like bureaucracy and it does one useful thing: when a stage is full, the person upstream has to help clear it rather than starting something new.

Four is a reasonable default for a small team. What matters is that the limit exists, because work expands to fill an unlimited queue and a long queue makes everything in it slower.

Almost all of it is waiting

This figure is startling the first time anybody calculates it. A piece taking six days of work and forty days to appear is 15% working and 85% waiting — sitting in a queue, waiting for a reviewer, waiting for a decision.

Under 10% is flagged. It is worth knowing because it changes what you do about it: if the work is only a tenth of the elapsed time, working faster cannot help. Removing the waiting can.

Cycle time, measured honestly

Anything still in production has an age, not a cycle time. Including unfinished work in an average makes the pipeline look faster than it is, because the slowest pieces have not finished yet — and the slowest pieces are the ones you most need to see.

Measure from the brief, not from when writing started. The days a briefed piece spends waiting for somebody to pick it up are real days.

Rework points at the brief

Count the times a piece has gone backwards — sent from review back to writing. Two or more is flagged.

Rework is almost never a writing problem. It is a briefing problem: nobody agreed who the piece was for, what it had to say, or what "finished" meant, so the first version was always going to be wrong. The sample has a piece on its third trip back with exactly that note.

The fix is upstream and it is cheap: agree the audience, the argument and the length before anybody writes a word.

Blocked means somebody else

Mark a piece blocked only when it is waiting on somebody outside the team — a customer approval, a legal review, photography, an interview that has not been scheduled. The tool will not accept a blocker without saying what it is, because "blocked" with no reason is how something waits three weeks.

Blocked pieces are drawn in purple on the waiting chart, separately from ones that are merely slow, because they need a different response: somebody has to go and ask.

Fixing a slow pipeline

In the order that usually works:

• Clear the bottleneck first, and nothing else. Everybody helps until the queue is down.
• Cut the number of reviewers. Two people who can approve is faster than five who must. Most review time is scheduling, not reading.
• Brief better to remove rework, which is the cheapest available improvement.
• Set a review service level — two working days, and after that it is approved.
• Start less. The most counter-intuitive and the most effective: fewer pieces in progress means each finishes sooner.

What this cannot do

• It is only as accurate as the board is current.
• It records the stage a piece is in, not the history of every stage it passed through, so it cannot tell you which stage consumed most of a finished piece's cycle time.
• Effort is an estimate, and content estimates are optimistic almost everywhere.
• It says nothing about quality. A pipeline can be made fast by publishing anything.
• The at-risk calculation assumes remaining stages take an even share of the target cycle, which is rough by design.

Printing and sharing

The Report tab prints the board, the charts and both tables with a title block you fill in. The board and the stage table together are a complete editorial meeting: where the queue is, what is stuck, and who has it.

Saving your work

The pipeline is held in this browser, on this computer, and stays there between visits. Use the backup button to write a JSON file you control.

Accuracy & disclaimer

Every date and estimate here is one you entered. The tool counts, groups and subtracts dates; it has no view on whether a piece is any good or whether a review was worth waiting for.