The tools and methods behind our workflow reviews

Starting with a handover map

Every workflow review we carry out begins with a plain sheet of paper, or its screen equivalent. We list each point where material changes hands: camera card to ingest, ingest to editor, editor to reviewer, reviewer to the person who prepares the delivery file. Each handover gets a line, and each line gets the name of the person responsible, the format of the material and the way it moves. This sounds basic, but most teams have never seen their own process drawn this way. People know their own step well and the neighbouring step vaguely. The map makes the gaps visible, and it gives us a shared document to discuss with producers and engineers rather than a series of opinions.

We keep the map deliberately low-tech. No specialist software is needed, and the team can correct it in the room as we talk. Once it is agreed, it becomes the reference for everything else in the review, and it is the page most clients keep pinned near the edit desks afterwards.

• One line per handover, with a named owner
• Format and transfer method noted at each step
• Corrected by the team in the room, not by us alone

Timing a real piece of material

A map shows the route; a stopwatch shows the cost. We ask the team to take one real item, a short feature or a segment from a recent show, and follow it from the first card offload to the delivered file while we record the time spent at each stage and, more importantly, the time spent waiting between stages. Waiting is where the hours usually hide. A clip may be ready for review at ten in the morning and not opened until mid-afternoon because nobody was told it had arrived. Those gaps rarely appear in anyone's estimate of how long the work takes, yet they often outweigh the editing itself.

We repeat the exercise with a second item if the first turns out to be unusual. One run can mislead, since a rushed item behaves differently from a routine one. Two runs, taken on different days, give a more honest picture of how the process behaves under ordinary pressure, and that is the picture we write up.

• Active time and waiting time recorded separately
• Two items followed where the first is unrepresentative

Naming and folder conventions

Much of the friction we find comes down to how files are named and where they are kept. When three editors each use their own habit, finding the right version costs minutes every time, and a wrong version reaching the reviewer costs far more. We look at what the team already does and aim to keep the parts that work. We rarely propose a grand new scheme. A short, written convention covering project, date, version and status is usually enough, provided everyone has agreed to it and it is written where people will see it. The test is whether a colleague who was not on the shoot could locate the final cut without asking anyone.

We also check how the convention behaves at the edges: footage from a second location, material supplied by an outside contributor, and archive items pulled back in months later. A scheme that survives those cases is worth adopting; one that only works for the tidy example is not.

Review and approval routes

Review is the step most likely to loop. A cut goes out, comments come back by several routes at once, and someone has to reconcile them. We trace how comments reach the editor today and count how many separate channels carry them, because every extra channel is another place for a note to be lost. Often the fix is procedural rather than technical. Agreeing who gives final sign-off, in what form comments are collected and by when removes a surprising amount of rework. Where a team already uses a shared review tool, we look at how it is used rather than suggesting a replacement.

We also look at what happens after approval. A locked picture that is quietly changed again, or a sound mix that is not matched to the final cut, undoes the work of the whole chain. Making the lock point explicit, and recording who may reopen it, is a small step that protects everything downstream.

• One route for comments, collected in one form
• A named person with final sign-off
• An explicit lock point after approval

Checking delivery against specification

The last stage is delivery, and it is where small errors become expensive. Broadcasters and venues each publish technical requirements for loudness, frame rate, file wrapper and metadata. We read the specification the team actually delivers to and compare it, item by item, with what leaves the building. As a sound engineer I pay particular attention to audio: channel layout, loudness measurement and how stems are labelled. A programme that passes the picture checks can still be returned because of a mislabelled track, and a return means a second pass through the whole chain.

Where we find mismatches, we suggest a short pre-delivery checklist that the person preparing the file works through every time. It does not need to be long. A page of ten honest questions, answered before the file is sent, catches most of what would otherwise come back as a rejection.

Writing it up so the team can use it

The output of a review is a short written report, not a presentation deck. It contains the agreed handover map, the timings we recorded, the points where work waits, and a small number of changes ranked by how much effort they need and how much time they are likely to give back. We try to keep recommendations modest and specific. Moving one approval step earlier, or merging two handovers into one, is easier to carry out than a wholesale rebuild, and a team that sees a first change work is more willing to try the next.

Where useful, we return after a few weeks to repeat the timing exercise on a fresh item. Comparing the new figures with the old ones is the fairest way to judge whether a change helped, and it keeps the conversation tied to what happened on real material rather than to what we hoped would happen.

• Handover map, timings and ranked changes in one document
• A repeat timing run to check what actually changed

None of this relies on exotic equipment. A handover map, a stopwatch, a clear naming convention, a single review route and a delivery checklist cover most of what we use, and they work because the whole team can see and maintain them. If your own process feels slower than it should, start by drawing the handovers and timing one real item.