Quality Quirks (pt 2)
- Cristina Rienton

- Aug 30
- 3 min read

Deviations
So. I've been writing about a lot of different things. I said we'd focus on different things dealing with Quality when I first started, but Life kind of got in the way, you know, how it usually does. So I had to pivot and give myself a distraction from everything, mainly just to ramble as best I could and hope that it would work. I've got some views from it, nothing big, but I really should get back on the horse and try this again. So here we go.
One of the biggest things that I've noticed after being in Quality for this long is how badly errors can affect a process. The phrase, "It's not exactly against the SOP," has been uttered so many times that it's practically burned into my brain. My main answer to this phrase and the accompanying, "what do we do?" Is simple: Document it. Now this can mean a lot of things: put a footnote, start an investigation, even the dreaded 'start a deviation.' That last one always sets people's teeth on edge. Because depending on where you work and depending on the system's in place, deviations can take the better part of a month and can hold up the batch. Many times I've had superiors who have come to me with those questions try justify why it's not a deviation. I've also had colleagues who just kind of rolled over and got to writing. There's reasons for both these reactions, but I won't lie, I kind of prefer the latter over the former. The reason being is because, a deviation is not always what you think it is.
Every time I mention that something is a deviation to my QC Team or to my Manufacturing Team (or even facilities and operations sometimes) they get this look of dread on their face. They think the world is ending because they see time 'wasted' on searching for documentation, typing every free minute they have, and a long list of reviews and approvals that can take up to a month if not more. From what I understand they may think that it means that they've messed up in some horrific way, and that this threatens the batch, and that it's a mark against them.
What they don't realize is that its not.
Things go wrong, mistakes are made, and adjustments may need to happen. We're only human, there's no way about it. A deviation is not a mark, it's documentation. Its a process. It can be an annoying and incessantly long process, but a process. The fear that they messed up and that the batch is threatened, that's what a deviation is meant to find out. More often than not what an operator did is not threatening to the batch, if anything it's a documentation error. However, if we don't write it down, if we don't explain in a place where the information can be retained and remembered later. Then we don't know for sure.
Writing the deviation clears away the fog of uncertainty that comes over after the problem or the missed notation is done. It allows for retention of information, especially if it's documented right away. It clears up confusion that may come later down the line when a reviewer is going through the batch record and finds the issue. Because they will find the issue. It is also a record of everything that was done for the batch, so that when a regulatory body looks at it later down the line they don't flag you for 'trying to hide things.'
A deviation is just a record. Its not a blemish on your career. It's not a sign that you're a bad operator. It may not even be an issue with the batch. Its clarity. It's understanding. It's documentation. Don't be scared of it.




Comments