Most QA functions on a remediation start with the same assumption: a defect is a finding against the analyst who did the work. Severity, type, root cause, owner. The owner is the analyst. The remedy is feedback, training, and if the pattern persists, a conversation with the operations lead about performance.
This works for the genuinely careless defects, of which there are always some. It does not work, at all, for the recurring ones. And the recurring ones, on every remediation I have ever worked on, are where the QA data spends most of its time.
The shape of the pattern
By week three or four of a programme, the defect log has begun to settle. The headline pass rate has stabilised somewhere below the steering committee's target. The defect mix is largely material rather than critical. And the same five or six defect types are showing up against the same eight or ten analysts, week after week.
The temptation, particularly from anyone who reads the dashboard without reading the underlying files, is to treat this as eight or ten people problems. The Programme Director asks operations to "have conversations". Operations leads have them. The defects continue. The conversations escalate. The defects, stubbornly, continue.
What the calibration meeting almost always reveals
The calibration meeting is the test. Take a single file, blind, and put it in front of five experienced reviewers. Ask them to log their findings independently. Then sit them in a room together and compare. On a remediation with a recurring defect problem, the five reviewers will disagree on whether the analyst's decision was right.
That is the moment the conversation should change. If five experienced reviewers, working from the same policy and the same training, cannot agree on whether the file is good, the analyst who produced the file in the first place is not the problem. The reviewers are not the problem either. The framework against which all of them are working has an ambiguity in it that the policy has never resolved, that the training has not surfaced, and that the team has been working around in two or three different ways for months.
Competence patterns cluster against individuals. Guidance patterns spread across them. Look at the spread before looking at the people.
What the defect data is usually pointing at
Across the programmes I have worked on, the most common things sitting upstream of a recurring defect are remarkably unglamorous. They are usually one of five things, sometimes more than one at the same time.
A policy that is silent. The procedure describes what to do in three quarters of cases and goes quiet on the rest. Analysts make a reasonable call. The reasonable call is not consistent across the team because the policy never said which call was right.
A policy that contradicts the training. The written policy says one thing. The training deck, written two years later by a different person, says a slightly different thing. The team has been operating against the training. QA has been measuring against the policy. The gap is the defect.
A system field that forces a choice the policy does not anticipate. The mandatory rating field on the case management tool has three options. The policy describes four scenarios. Analysts choose the closest option and add a note. QA reads the field, not the note, and flags the inconsistency.
An unwritten local convention. A long-tenured senior analyst has, for years, handled a particular customer type one specific way. Everyone in their team has learned to do the same. Nobody in the next team over knows about it. QA finds the inconsistency between teams and flags both.
Two operations leads training the same step differently. The training material is shared. The delivery is not. One lead emphasises one thing; another lead emphasises another. Defects fall on whichever side of the building was trained by whom.
How a QA function should respond
Slowly, on the analyst, and quickly on the framework. The language matters. A defect logged with a root cause of "guidance gap" carries no individual record against the analyst. The fix sits with the policy team, the training team and the operations leads. The QA Lead writes a calibration note, the policy is amended in writing, training is updated, the next cycle's reviews apply the clarification, and a sample of the affected cohort is re-reviewed against the new standard.
The data that comes back from that re-review is, in my experience, the single most powerful piece of evidence a QA function can put in front of a Steering Committee. The same analysts, the same files, the same QA function, producing materially different defect rates because the framework against which the work is now being assessed has been clarified. That is what fixing the guidance, rather than fixing the people, actually looks like.
Why the personnel route is so often the wrong one
Personnel actions are slow. They are distressing for the analyst, distracting for the operations lead, and they almost always solve the wrong problem. The defect persists in the next analyst who picks up the same file type, because the framework has not changed. The programme then concludes that the issue is "wider than first thought" and the cycle begins again with a different group of names.
The slower, less satisfying answer is to assume, for any defect that recurs across more than two analysts in different teams, that the framework is the problem until calibration proves otherwise. Calibration usually proves it. The fix is usually a paragraph rewritten, a system option added, a training session run, an unwritten convention surfaced and either adopted or retired. Quiet, fast, and effective. Most QA functions do not look like heroes when this happens. They should not need to.
What I would do this week, if I were you
Take your top five recurring defects from the last cycle. Look at how many distinct analysts they appear against, and how many distinct teams. If the answer is more than three analysts across more than one team, treat the defect as a framework hypothesis. Put a representative file in front of five experienced reviewers, blind. If they disagree on the call, you have your answer, and you have your fix.
Guide 007 sets out the full QA cycle, including the calibration cadence, the defect taxonomy and the way QA should report into governance. Download the full guide and use the defect taxonomy in the appendix as the starting point for your own.