We get called in after failures.
Sometimes the call comes quickly – a shutdown, a contamination event, something that can’t be ignored. Sometimes it comes months later, after the third or fourth time the same thing has happened and someone has finally decided it’s not a coincidence.
The conversation usually starts the same way.
Or the clamp. Or the fitting. Or the seal. The specific component varies. The diagnosis almost never does.
And almost always, they’re wrong.
I don’t say that to be difficult. I say it because it matters.
If you replace the gasket and the gasket wasn’t the problem, you’ve spent money and time – and you’ve reset the clock on the next failure. Nothing has changed except the date.
The component gets blamed because it’s the thing that visibly failed. It’s tangible. It’s replaceable. Replacing it feels like solving the problem – and it looks like solving the problem to anyone who’s watching.
But a gasket that’s been over-torqued will fail. A gasket installed in the wrong sequence will fail. A gasket that’s the right spec for the design but the wrong choice for how that connection is actually being used will fail. Every single time. The gasket did exactly what physics told it to do. The system failed it.
In twenty years, I’ve been involved in hundreds of failure investigations. The root cause is almost never the component. It’s almost always one of three things.
Sometimes it’s a combination of all three. But in two decades of failure analysis, I can count on one hand the times I’ve walked away thinking the component was genuinely at fault.
Sites that handle this well have figured out something that sounds simple but is surprisingly hard to implement.
They treat every failure as a system question, not a component question.
Not “what failed?” but “why did it fail – and what does that tell us about how we’re operating?”
The second question is harder. It takes longer to answer. It sometimes leads somewhere uncomfortable. But it’s the only question that actually prevents the next failure.
If you’re seeing recurring connection failures on your sites, resist the instinct to look at the component first.
Look at the procedure. Look at the training record. Look at what actually happened on the floor versus what the documentation says should have happened.
The component will tell you where the failure was.
The system will tell you why.
The most expensive failure isn’t the one that shuts you down. It’s the one that keeps happening – at low enough cost that nobody stops to ask the real question.
Ask the right question.
Then fix the right thing.
PTL – helping pharma and bioprocessing teams get to the real answer for over twenty years.
Talk to our team
