Start with the problem you can describe
A workflow review is most useful when it starts from something you can point at. Late deliveries, files that arrive in the wrong format, an operator who has to copy the same clip three times: these are all concrete. A vague feeling that the process is slow is harder to work with, and it often turns out to be several smaller problems wearing one label.
Before you contact anyone, spend a week noting where time actually goes. Ask the people at the desks, not only the person who signs off the schedule. Operators usually know which handover causes the delay, because they are the ones waiting for it or fixing the result afterwards.
Write the problem in one or two plain sentences. If you cannot, the first job of a review is probably to define it, and that is worth knowing in advance. It changes what you ask for and how long you expect it to take.
- Which step costs the most time on a typical day
- Where the same material is handled more than once
- What goes wrong most often at handover
Map what actually happens, not what is written down
Most productions have a documented workflow and a real one. The document describes the intended path of a signal or a file; the real one includes the workarounds that crept in after a piece of kit was replaced or a new format arrived. A review that only reads the document will miss the point.
Sketch the real path yourself first, even roughly. Start at the camera or microphone and follow the signal through routing, recording, storage and on to delivery. Mark every place where a person has to do something by hand, because those are the places where errors and delays collect.
This sketch need not be tidy. Its value is that it shows you, and later a consultant, where the gaps between the paper version and the daily version lie. Bring it to the first conversation along with any existing diagrams.
- Signal routing from source to recording
- Where files are named, moved and stored
- Who approves material and how it is passed on
Check the edges: routing, file handling and delivery
Workflow problems tend to cluster at the edges between stages. Routing is where a feed leaves one system and enters another. File handling is where naming, folder structure and backups either hold together or quietly fall apart. Delivery is where the finished item meets the requirements of whoever receives it.
Go through each edge and ask who owns it. If the answer is nobody in particular, that is usually where trouble starts. A clear owner for each handover, even a shared one, removes a surprising number of repeated questions.
Also look at what the receiving end needs. Broadcasters, platforms and event clients each specify formats, loudness and metadata differently. Confirming those requirements early is cheaper than correcting a delivered file, and it is a straightforward item to settle before any review begins.
- Named owner for each handover
- Agreed file naming and folder structure
- Written delivery specification from the recipient
Decide who needs to be in the room
A review that involves only management produces recommendations that operators find impractical. One that involves only operators can miss budget and scheduling limits. Aim for a small group that covers both: someone who plans the work, someone who runs the desks, and someone who handles the output.
Think about availability too. People working a live schedule cannot always step away, so agree in advance when they can talk and for how long. Short sessions at the desk, while the equipment is in front of them, often give more than a meeting held elsewhere.
Be honest about who will act on the findings. If nobody has the time or authority to change a routine once it is questioned, the review will produce a tidy report and little else. Settling this now saves disappointment later.
- One planner, one operator, one person on delivery
- Short sessions held at the working position
Set limits on scope, time and change
Reviews drift when the boundaries are loose. Decide whether you want a look at one production chain or the whole operation, and be clear which parts are off limits, such as a system that is about to be replaced anyway. A narrow scope done properly is better than a wide one done thinly.
Consider how much change your team can absorb. A list of twenty improvements is of little use in the middle of a busy season. Ask for findings in order of effect and effort, so you can take the easy, valuable ones first and leave the rest for a quieter period.
With autumn schedules filling up, timing matters. Changes to routing or file handling are best made between projects, not during them. Choosing a window before you begin keeps the review from colliding with live work.
- Which chain or area is in scope
- Which systems are not to be touched
- A quiet window for any changes
Know what you will have at the end
Agree before you start what a useful result looks like. For most teams it is a clear picture of the current workflow, a short list of changes in priority order, and notes simple enough that a new operator could follow them. Anything more elaborate should justify itself.
Ask how the findings will be handed over. A written summary that people actually read beats a long document that sits in a shared folder. If equipment changes are likely, ask for them to be described in terms of what they fix, so the case for spending is easy to make internally.
Finally, decide how you will tell whether it worked. Pick one or two things you can measure without fuss, such as the time from recording to delivery or the number of files that need reworking, and note them now. A comparison a few months later will tell you more than any impression.
- A map of the current workflow
- Changes listed by effect and effort
- One or two simple measures to compare later
A workflow review pays off when the groundwork is done first: a problem you can describe, a map of what really happens, owners for each handover, the right people involved, firm limits and a clear idea of the result. If most of this checklist is settled, the review itself becomes shorter and more useful. If not, the checklist is a perfectly good place to begin.