Starting with a walk along the signal path
Before any document is opened, I ask to follow one item of content from the camera to the point where it leaves the building. It might be a news package, a studio segment or a recorded interview. Walking that route with someone who handles it daily tells me more in an afternoon than a week of reading diagrams would.
I carry a notebook, a pencil and a printed floor plan, nothing more. At each handover I write down who touches the material, what format it is in, what the person expects to receive and what they do when it arrives wrong. The floor plan lets me mark where people stand, because distance between desks often explains delay better than any system does.
These first notes are rough, and they are meant to be. They give the written review its backbone and they show the team that we are interested in how work really happens, not in how the manual says it should.
- A printed floor plan of the gallery, edit area and playout room
- One item of real content followed end to end
- Names of the people at every handover
Timing logs instead of opinions
Most teams tell me the slow part of their workflow is the same one: the edit, the transfer, the approval. Often they are right about the symptom and wrong about the cause. So we ask for a simple timing log over a normal working week, kept by hand if necessary.
The log has four columns: the item, the time it was ready for the next step, the time the next step began, and a short reason for any wait over a few minutes. It takes people seconds to fill in and nobody needs training. After a week the waiting time is visible as a number rather than a feeling.
What surprises people is how little of the delay sits inside the technology. Files wait for a name, an approval or a free machine far more often than they wait on a slow transfer. The log gives us evidence to point at, and it keeps the conversation calm.
A fixed set of questions at every handover
Every review uses the same short list of questions at each point where content changes hands. This keeps findings comparable between a small regional newsroom and a larger live events crew, and it stops me from chasing whatever happens to catch my interest on the day.
The questions are plain. What arrives, and in what format? How does the person know it has arrived? What do they check before passing it on? Where is it stored, and under what name? What happens when something is missing or wrong at this point?
Answers are written down in the person's own words and read back to them. If they correct me, the correction goes in the review. A workflow description that the people doing the work cannot recognise is of no use to them, however tidy it looks on the page.
- What arrives and in which format
- How arrival is confirmed
- What is checked before passing on
- Where the file is kept and how it is named
- What happens when it goes wrong
Reading the file naming and storage habits
Naming conventions say a great deal about a production. I ask for a sample listing of one week of files from the shared storage and read it the way an editor would, looking for gaps, duplicates and names that only one person could decode.
Where three versions of a graphic sit beside one another with no clear final, I know a transmission risk exists. Where every file carries a date, a programme code and a version number in the same order, the team usually has fewer late surprises, and the review can say so with confidence.
I never propose a new naming scheme in the first pass. Teams adopt a convention they helped shape far more readily than one handed to them. The review lists what exists, shows where it breaks down and suggests two or three small rules the team can agree on themselves.
Writing the review so it gets used
The written review is the product, so its form matters. We keep it to plain paragraphs, a single annotated diagram of the route from camera to transmission, and a numbered list of findings in the order the team would meet them in a working day.
Each finding states what we saw, why it matters at transmission, and one practical change with a rough indication of effort. We avoid ranking by importance on our own judgement alone; the technical director usually knows which risks the channel can live with, and we ask before ordering the list.
Diagrams are drawn by hand and then tidied, never generated from a template. The point is to show this team's route, with its odd corners, so that a new engineer on the first morning could read it and understand where to stand.
- Plain prose, no jargon unless the team already uses it
- One annotated route diagram
- Numbered findings in working-day order
What we deliberately leave out of the toolkit
We do not bring monitoring software, dashboards or any system that needs installing on a production network. Autumn is a busy period for many broadcasters, with new seasons starting, and the last thing a team needs is a consultant adding load to machines that are already carrying live material.
Paper, pencil, a spreadsheet for the timing log and a few conversations are enough to find the real problems in nearly every review we have written. Specialist tools can come later, if a finding calls for one, and the review will say so plainly.
This restraint is also a matter of trust. When the method is simple enough for anyone on the team to repeat, they can run it again themselves in six months and see whether the changes made a difference, without calling us.
A workflow review stands or falls on how carefully the route is observed and how plainly it is written up. Our tools are modest: a notebook, a floor plan, a timing log, a fixed list of questions and a readable document. Used patiently, they show where content waits, where it gets lost and what small changes would help. If you want to see how this applies to your own gallery, the contact page is the place to start.
