A quality system built around
how you actually work.
There are two versions of most quality systems. The one in the documents, and the one people use to get through the day. The further apart those two get, the more findings you collect.
I build quality systems that match the second one. Sometimes that means starting from nothing, for a company moving into regulated manufacturing for the first time. More often it means taking a system that already exists and making it usable, which is harder and less glamorous and where most of the value sits. Either way I work inside your team rather than around it. I'm not there to hand you a template and leave.
28 years in life sciences across three continents
Experience with USFDA, TGA and MHRA audits
What changes when the system fits.
Procedures that describe the actual work.
Written with the people who do it, so they hold up when the person following them is tired and behind schedule.
Fewer issues that keep coming back.
Because the cause got dealt with rather than the finding.
People who use the system instead of working around it.
Adoption is where most quality systems fail, and it has almost nothing to do with how well they were designed on paper.
Less duplicated effort.
Fewer unnecessary approvals, fewer forms that nobody reads, less wastage. There's usually more of this than anyone expects.
Readiness that doesn't need a scramble.
If the system runs properly, being ready for an inspection is a state rather than a project.
More confidence from the people who audit you.
For a manufacturer that isn't abstract. Your clients audit you, and what they find determines whether they come back.
Why most systems
don't do that.
The system was built to survive an audit rather than to run a business. That's a different design brief, and it produces a different system.
Everything routes through QA, so nobody else owns anything. Quality becomes the bottleneck for every decision, and the people doing the work stop feeling responsible for it. Complexity accumulated. Every finding added a control and nothing was ever taken away. Each addition made sense at the time. Nobody has weighed the total. And the procedures were often written by people who don't do the task, describing a version of the work that doesn't exist.
What that looks like in practice.
A manufacturer I worked with had a pile of open and overdue change controls, and a long list of SOPs past their review date. Both had become a compliance issue and a regulator had cited it. The QA team couldn't get on top of either.
The cause turned out to be the change control procedure itself. It required a change control form for any change at all, including reviewing or updating an SOP. The form ran to several pages, with multiple sections and multiple approvals. For an SOP update most of those sections didn't apply, but the process was heavy enough that people put off starting one. So change controls sat incomplete and SOPs went unreviewed. I redesigned it. SOP reviews and updates no longer need the full form. They need a one-page Document Revision Record with two signatures.
Nothing was removed that the regulations required. What went was the weight around it.
You'll know some of these:
Deviations keep repeating
CAPAs close and nothing actually changes
Change control takes so long people stop raising changes
Staff have their own way of doing things and you half know about it
The same audit findings turn up every cycle
QA has to approve everything, and QA is drowning
Building new, or fixing what's there.
If you're building.
Usually a company moving from R&D into clinical manufacturing, or setting up a new facility, or preparing for the first GMP manufacture. The risk here is overbuilding. It's very easy to be sold a system designed for an organisation ten times your size, and then spend two years feeding it. I size the system to where you actually are, and build it so it can grow rather than be replaced.
If you're fixing.
The system exists. It doesn't work. Perhaps it's grown unusable, perhaps it was inherited, perhaps the company outgrew it two years ago and nobody had time to notice.
How I approach it.
I start by understanding how the business actually runs. Business process mapping, walkthroughs, time with the people doing the work rather than only with QA. Before anything gets designed.
Then I look at the system as it's used, not as it's written. Those are different documents and only one of them is real. Then I design or redesign to fit what I found. Your operations, your stage, your risk, your resources. Not a template. And I work alongside your team throughout, because a system built without them is a system they'll work around.
What you receive:
A quality system and procedures aligned to your actual operations.
Documents your people can follow, describing the work as it happens.
A quality system effectiveness assessment.
Not whether the documents exist, but whether the system is producing what it's supposed to, and where it's failing systemically.
Clear roles and responsibilities.
Often the part that lets a growing organisation plan recruitment and write job descriptions properly.
A compliance gap assessment with an action plan.
Where you stand now, and what to do about it, sequenced.
Training content built around your system.
Tailored to your company and your procedures, not generic GxP material.
Where this connects.
If you don't yet know what's wrong.
A compliance assessment tells you where you stand before you commit to anything.
If the people are the gap rather than the system.
Sometimes the procedures are fine and nobody has built the judgement to apply them.
If you need quality judgement rather than a project.
How you'd know it worked.
Whether deviations stop repeating.
How long a change takes to get through.
Whether a CAPA closing actually changes anything.
Whether the same findings come back at your next audit.
What those become depends on what you do with the system once it's built.
Proof
A quality management system for a CRO — university-based, expanding into commercial trials
An investigator-led CRO based at a university was expanding its clinical trial services to take on commercial sponsors, and wanted to offer full trial management. The scientific and technical expertise was already there. The quality systems expertise wasn't, and an independent gap assessment had identified several major gaps they needed to close.
I interviewed staff to understand how the business actually ran and what internal resource they had, reviewed the existing gap assessment, and mapped the key processes. Then coaching and brainstorming sessions with key staff, using the process maps to work through solutions together, before drafting SOPs based on what came out of those sessions and what compliance required.
They ended up with a quality management system suited to the services they were actually offering, the existing gap assessment used to close out the major findings rather than repeated, and clear roles and responsibilities that let them plan recruitment and write job descriptions.
Supplier approval, simplified — pharmaceutical manufacturer
Supplier approval was taking a long time, running through multiple forms and several departments, and generating non-compliances. Nobody had visibility of where a given supplier had got to. The staff view was that new software would solve the problem.
I mapped the process and the data, marking where steps repeated, where bottlenecks occurred, and flagging non-compliances in the process. Brainstorming sessions with stakeholders identified a more efficient, compliant process. Changing the software alone would not have solved it. The output was a set of short-term and long-term options.
A quality system built for Phase 1 — biotech CDMO
Moving out of R&D into Phase 1 clinical manufacturing, with no internal QA, a scientific team unfamiliar with regulatory and quality process, and a limited budget. I mapped the business processes, ran a gap analysis, and designed a QMS sized for where they were and able to scale. Then an implementation roadmap, and mentoring for the QA person they eventually hired.
What clients say.
“I had the pleasure of collaborating with UQM Consulting during a critical phase of our move to GMP-like operations at Southern RNA. The Quality Assurance services provided exceeded our expectations in every aspect. Antiksha demonstrated an unparalleled level of expertise and commitment to ensuring the highest standards in our processes, business and current quality framework.”
Garry Heaney, CEO, Southern RNA
- 1. A conversation.
- 2. Understanding the operation.
- 3. Findings and a roadmap.
- 4. Design and build.
- 5. Adoption.
How an
engagement runs.
1. A conversation.
Thirty minutes so I understand your situation and you can decide whether I'm the right person. I'll tell you if I'm not.
How an
engagement runs.
2. Understanding the operation.
Process mapping, walkthroughs and staff interviews. What actually happens, who owns what, where the risk sits, and what internal resource you have. I need access to your people, not just your documents.
How an
engagement runs.
3. Findings and a roadmap.
What's working, what isn't, and what to do in what order. You get a plan you could run without me.
How an
engagement runs.
4. Design and build.
Procedures, governance and documentation structure, worked through with your team rather than delivered to them. I'll need time from process owners, not only from QA.
How an
engagement runs.
5. Adoption.
Training, mentoring and reinforcement while it beds in. This is the part most projects skip, and it's the reason most quality systems fail.
Timelines depend on your size and what already exists. I'll give you a rough estimate on the call and a firm one in the proposal.
Who you'd be dealing with.
I'm Antiksha Joshi. I've spent 28 years in pharmaceutical and life sciences quality across three continents. I am Chair of Women in Pharma, ISPE Australasia Affiliate.
I also write and speak on quality systems for various knowledge sharing organisations and online publications.
I've built and rebuilt quality systems for organisations from pre-clinical startups through to established manufacturers. My background is in microbiology, and I hold a diploma in counselling, which matters more than it sounds when the hardest part of the job is getting people to use what you've built. Whoever you speak to on the call is the person who does the work.
Questions people ask.
Can you improve what we have, or does it have to be rebuilt?
Improve, most of the time. Rebuilding from scratch is rarely necessary and rarely the cheapest option. I'll tell you honestly if I think yours is beyond fixing.
How long does implementation take?
It depends on your size and what exists already. I'll give you an estimate on the call and a firm number in the proposal.
Will you work with our QA team?
Yes. I work inside existing teams rather than around them. If you have a QA person, they're usually the most useful person in the room.
Do you implement, or just advise?
Both. Some clients want a design and a roadmap they'll execute themselves. Others want me there through implementation.
Can you use work we've already had done?
Usually, yes. If you've had a gap assessment or an audit, that's a starting point rather than something to repeat. I'd rather leverage it than charge you to find the same things twice.
How much of our team's time will this take?
A meaningful amount, and I won't pretend otherwise. A system designed without your people is a system your people will work around.
We're early stage. Do we need a formal system yet?
Probably less than you've been told. What you need depends on your stage, and I'd rather tell you that on a call than sell you something you'll be feeding for two years.
What happens once it's built?
Ideally you run it. If you want ongoing support, that's a separate arrangement.
