# OOS in the lab: what if the root cause was onboarding? On investigation, a significant share of **OOS** (out of specification) results turn out to be analyst-driven — **human error**. And the most exposed technicians are, logically, those whose onboarding was the least complete. A rarely addressed blind spot: the **quality of onboarding** in the quality control laboratory. Error → OOS → ? The OOS investigation often stops at "analyst error." But it rarely traces back to the true source: a skill that was never acquired on arrival. Sinfony observation — pharmaceutical quality control laboratory in France. An **OOS** is an out-of-specification result. When the investigation concludes it was human error — mishandling, dilution, data entry, instrument reading — we correct the incident, re-test, and close it out. But we treat the symptom. The rarely asked question: had this technician truly been **made competent** on this technique when they arrived? We investigate the OOS, never the onboarding that made it likely. Root-cause analysis of an OOS almost always stops at the action. Yet when you map a team's actual skills, the finding is clear: **recent arrivals — temps, fixed-term hires, newly permanent staff — concentrate most of the gaps**, technique by technique. Statistically, they are the most exposed to error, and therefore to OOS. The root cause is not the individual: it's an incomplete, non-standardized onboarding path. ## Trace the thread, from OOS back to arrival. 01 ### The OOS An out-of-specification result triggers an investigation, a re-test, sometimes a held batch. 02 ### Analyst error The investigation often concludes it was human error: handling, dilution, reading, data entry. 03 ### The missing skill The task wasn't truly mastered on that specific technique — often in a recent arrival. 04 ### Onboarding An unstructured, non-standardized onboarding path with no per-technique qualification. The true root. ## Skills-based onboarding. Make a new arrival competent, technique by technique, before letting them produce a result that commits a batch. ### Map the skills A technician × technique matrix, with a clear status: not trained, trained but not autonomous, trained & autonomous. ### Qualify by technique No autonomy on an instrument without formal qualification: competence is proven, not assumed. ### 70-20-10 path Concepts via micro-learning, tutored hands-on practice, then supervised routine: the skill takes hold. ### Mentoring & double-check Support the task at the workstation until autonomy is genuinely acquired, rather than presuming it. ### Prioritize by risk Tackle the most critical techniques and the biggest OOS generators first. ### Close the loop with OOS Every analyst-driven OOS becomes an input to the training-path review, not just a CAPA. [Method ### The QC skills matrix The tool to map and drive skills development, instrument by instrument. Read the article →](/en/blog/skills-matrix-qc-laboratory/) [Training ### Blended learning 70-20-10 Build learning paths that truly anchor skills at the workstation. Read the article →](/en/blog/blended-learning-70-20-10-gmp/) [Data integrity ### The ISI rule & ALCOA The other major source of deviations in the lab: data integrity. Read the article →](/en/blog/data-integrity-alcoa-isi-rule/) ## OOS, human error & training. What is an OOS in the quality control laboratory? + An OOS (out of specification) is a test result outside the specified limits. It triggers an investigation to determine the cause — analytical, material or human — and to decide the fate of the batch. A significant share of OOS results turn out, on investigation, to be analyst-driven. Why link OOS to onboarding? + Because analyst errors are often concentrated among recent arrivals, whose competence was never truly built when they joined. Addressing the quality of onboarding — a structured path, per-technique qualification — tackles the root cause, not the symptom. How do you reduce analytical human error? + By making each technician genuinely competent before entrusting them with results that commit a batch: skills mapping, per-technique qualification, a 70-20-10 path (concepts, tutored practice, supervised routine) and prioritization by risk. Competence is proven, not assumed. How do you connect training and OOS investigations? + By making every analyst-driven OOS an input to the training-path review, not just a CAPA. This closes the improvement loop: the deviation feeds training, which prevents the next deviation. ## Fix your OOS at the root: competence. Let's structure the onboarding of your quality control technicians to reduce errors and OOS.