Production Workflow Management: Making It Obvious Who Is Stuck and Where
Published:
Last Updated:
Category:
Published:
Last Updated:
Category:
Authors: Shusaku Yosa
Someone asks how a project is going and you cannot answer. The day before the deadline you discover that review has been sitting untouched for a week. Any team without functioning production workflow management will recognise this.
The problem is not that people are careless. It is that nothing makes a stalled item visible. This article covers the fundamentals and then goes down to the level of stage design, showing how to build a system that continuously answers the question: who is stuck, and where?
Production workflow management is the practice of defining the stages a piece of work passes through from concept to publication, then tracking which item sits at which stage and who owns the next action.
The goal is not hitting deadlines as such. It is detecting slippage the moment it occurs, while you still have options. The range of available responses is completely different when a delay surfaces three days out versus on the day itself.
Schedule management is about the plan: what finishes by when. Workflow management is about live state: how far along you are against that plan, and where things are stalling.
Calendars and Gantt charts are good at describing plans but poor at detecting blockages. They tell you a date has passed; they do not express why something is stuck or whose desk it is sitting on.
Teams where this runs well share one characteristic: anyone can answer these three questions within five seconds.
If a single "in progress" status covers writing, graphics production, and revisions, the status column tells you nothing. Items sit at "in progress" for three weeks. Split it too finely and nobody updates it, so five to seven stages is the workable range.
The single most important piece of information is who needs to act next. Most tracking sheets record only the producer, so during a review wait the owner field still shows the writer and the reviewer who actually holds the work is invisible.
Without a record of when the status last changed, you cannot detect stagnation. "In review" alone does not distinguish between something submitted yesterday and something abandoned two weeks ago.
When "I will get it back to you today" is buried in a chat thread, the tracker goes stale. The moment people cannot tell whether the current state lives in the tracker or in a conversation, workflow management has stopped functioning.
You do not need an elaborate system. Keep these three populated and you can always answer who is stuck and where.
The person who must act next to move the item forward. Crucially, this is a separate field from the producer. During review it holds the reviewer; while waiting on assets it holds whoever supplies them; during sign-off it holds the approver.
Which step the item is at. Use a predefined set of options based on the stage design below. Leaving it as free text breaks both filtering and reporting.
The date the item entered its current stage. Calculate elapsed days from it and stalled work surfaces as a number. In practice this is the highest-leverage field: the same status means something entirely different at two days than at twelve.
These three, plus item name, deadline, and producer, give you a six-field minimum viable tracker.
Map the stages your work actually passes through. Write down the real flow, not the idealised one. If rework loops and multiple review rounds happen in practice, include them.
Stage names alone get interpreted differently by different people. Does "writing complete" mean a first draft exists, or that the writer has self-reviewed it? Define in one line what must be true to advance, and put it somewhere everyone can see.
Stages with fuzzy exit criteria always become where work piles up. Most items stuck at "in review" are stuck because nobody specified what the reviewer is meant to check.
Make it a rule which person the ball transfers to on entering each stage. Enforce "when you move it to in review, change the owner field to the reviewer" and the status column alone tells you where accountability sits.
Define how many days each stage should normally take. Only with that baseline can you judge a delay objectively. Without it you are left with "this feels slow", which means you miss the moment to raise it.
Make items past their standard lead time visible at a glance. Conditional formatting that colours the row in a spreadsheet, or a saved overdue filter in a project management tool, is entirely sufficient. The point is not relying on someone eyeballing it.
Reading every item aloud from the top is a waste of a meeting. Work only from the stagnation filter, and for each item confirm two things: what it is waiting on, and by when it will move. That meeting finishes in 10 to 15 minutes.
Here is a stage design with exit criteria and standard lead times, using article production as the example. Adjust to your own reality.
That totals 11 to 14 working days. Record actuals against this baseline and it becomes clear which stage is chronically overrunning.
When revisions require another review round, you can either send the stage backwards or keep it moving. The better option is to leave the stage where it is and count the number of rework cycles instead. Moving the stage back resets the elapsed counter and hides the real extent of the delay. Any item exceeding two rework cycles is a signal that alignment at the outline stage was insufficient.
By far the most frequent form of stagnation. Reviewers usually hold other responsibilities, and review is easy to defer. Three countermeasures:
Graphics, data, case study permissions, expert verification: anything dependent on people outside your team. Identify required assets at kickoff and issue the requests in parallel with writing, and this stagnation largely disappears. Requesting them only after writing is finished adds the entire wait to your lead time.
With three or more approvers in series, even two days each adds up to six. Request approvals that can run in parallel simultaneously, and agree a threshold below which minor changes are reported after the fact rather than pre-approved. If you can reduce the number of approval steps outright, that is the most effective fix available.
A workflow manager who chases people for updates and enters them on their behalf becomes the bottleneck. Status changes belong to each owner; the manager concentrates on clearing blockages.
There is no need to ban progress updates in chat, but whoever posts one also updates the tracker. Once "check the tracker and you will know" stops being true, people stop checking it.
In a culture where reporting a delay is treated negatively, people simply stop updating status. Establishing across the team that visibility exists for early problem detection, not individual evaluation, is the foundation everything else rests on.
Leave stages that no longer match reality in place and updating becomes an empty ritual. Once a quarter, compare standard lead times against actuals and correct any stage that is chronically off.
Easy to adopt, and stagnation highlighting is straightforward to implement with conditional formatting. Works well up to roughly 20 items a month. The weaknesses are the absence of notifications and having to enter status change dates by hand.
Lay the stages out as kanban columns and you can see visually which stage is accumulating work. Owner-change notifications and deadline alerts come as standard, which suits workflow management well.
Status and owner attach to the draft article itself, so there is no duplicate tracking between a sheet and the real artifact. When everything you produce lives in the CMS as content, this is the lowest-overhead option.
The criteria are monthly item volume and the number of people involved. Beyond roughly 20 items a month and three contributors, moving to a tool with notifications and automatic rollups starts to pay off substantially.
Five to seven is the practical range. At three or fewer you cannot locate the blockage; beyond ten the update overhead breaks the process. Design at seven and consolidate any stages that go unused.
It works even at two or three people. The fewer the people, the more items each person carries in parallel, and the harder it becomes to track what is stalled from memory. A stripped-down six-field version still detects stagnation reliably.
Either share the tracker itself, or have an internal coordinator update status on their behalf. What matters is that while work sits with an external party, the ball holder reads "external partner" and the stagnation counter keeps running. Once external stages fall outside measurement, you can no longer locate the source of a delay.
Almost always either too many fields or no fixed update moment. Cut back to six fields and dedicate the first five minutes of the weekly meeting to everyone updating together. Add fields back only once the habit has formed.
The purpose of production workflow management is not eliminating delays. It is finding them early. The key points:
Start by writing out the stages your work actually passes through, exactly as they are. Making the real flow visible rather than the intended one is the first step in production workflow management.
A 6-step guide to building a content calendar. Covers the four reasons calendars stop being used, which fields to track,...
A clear explanation of whether you can use Android apps on an iPhone and why they don't run directly. Covers realistic a...
A clear explanation of what viral means: the mechanism by which information spreads chain-like through word of mouth and...
