Ask a delivery lead and a QA lead how the same project is going and you can get two honest answers that do not match. Delivery says, “We are on track. Most of it is done.” QA says, “We have barely seen any of it, and what we have seen has problems.”
Nobody is lying. They are reading different clocks, and they usually compare notes at the end, the most expensive moment to find out.
Where the disconnect lies
They count different things. Delivery counts items finished. QA cares how much effort is left. On a recent large batch, 39% of the videos were done by 19 October but only 26% of the footage. The short ones went out first. The dashboard said “ahead”. The work said “not quite”. It is a bit like announcing that you are nearly done with doing the dishes because every teaspoon is clean.
Review starts after annotation ends. Early videos waited a median of six days for QC. By then, anything wrong in them had been repeated across more work.
The rules move. Hold times, targets and the order of work changed several times, some overnight. Reviewers were marking an exam while someone edited the syllabus.
Reviewers do not always agree with each other. On a similar mix of work, QC fixes per video ranged from 1.4 to 4.8 between reviewers. Delivery cannot plan around that, and annotators cannot learn from it.
What closes the gap
It is not another meeting. It is one schedule and a few shared numbers.
Start review on day one. Once reports were checked as they arrived and reviewers looked only at flagged lines, the median wait fell from six days to under four hours.
Let machines catch the mechanical errors. Our automatic checks flagged 12,272 lines, and reviewers fixed 74% of them. Show those flags to the annotator before they mark an item done, so reviewers can spend their time on judgment.
Set the rules once, and calibrate on them. Agree hold times, targets and order of work before the first item goes out, and change them only at the start of a day, with a note on what they affect. Have every reviewer check the same small set first, so they agree on the standard.
Close the redo loop. Redos took a median of 48 hours to come back, and most of the notes named timing faults an automatic check could have caught at submission. A redo that waits two days is less a correction than a time capsule. Put it at the top of the queue, with a deadline.
Give both teams the same three numbers. Work left, measured in effort and not item count. How long finished work waits for review. How old the oldest redo is. Then the only thing left to argue about is what to do next.
When QA finds something that moves the date
Running on the same clock does not mean running at the same pace. Sometimes review turns up a loophole in the rules or an error pattern nobody saw coming, and the date has to move. That is not the schedule failing. That is QA doing its job. The trap is letting every finding become a stop sign, which turns QA into the person standing in the doorway with their arms folded.
Size it before you raise it. “There is a problem” stops a project. “There is a problem in about this much of the batch, and this is what it costs if it ships as it is” lets delivery decide. A small, targeted sample will tell you how wide it runs, in hours and not days.
Sort findings by what they do to the date. Some mean stop, because the client cannot use the work. Most mean fix going forward and rework the affected part later. A few only improve the next batch. Say which one it is.
Give dates as ranges with a trigger. “Done between these two dates, unless review finds a rule problem, in which case we will tell you within a day.” It is a more honest answer to “Then when can this be done?” than a single date that will not survive the week.
Agree who decides, and how fast, then tell the client early. A finding nobody owns turns into a delay. Say what was found, what it affects and what you propose. Bad news goes down better with a plan attached.
Quality is part of delivery
Quality is not a checkpoint at the end of delivery. It belongs inside the orchestration of delivery, from end to end. At the start, QA helps set the rules, the targets and the order of work. While the work moves, it reads the same numbers as delivery and flags drift while it is still cheap to fix. At handover, it sits in the decision to ship, fix going forward or hold. After that, what review learned goes into the next batch.
Run like that, QA and delivery do not take turns. They work from one plan. QA that arrives only at the end can say one thing, which is stop. QA that runs through the whole thing can say adjust now, and that is why the date mostly holds.
A project is only as late as its slowest unchecked step. Put that step on the same clock as everything else.
Want QA and delivery running on one schedule?
Talk to Our Team