Governance Belongs Inside Your QMS
Most regulated companies treat governance as something that happens after development. You build the thing, document it, review it, approve it, then you spend three to six months in what the industry calls the “tail”: verification, validation, documentation, and submission. The product is done, the team already has deadline fatigue, and the quality group is reading a design history file they’ve never seen before, trying to get comfortable enough to sign off on something they weren’t part of building.
This is a system problem. And it’s one that only leadership can change.
The Stage Gate Trap
The assumption underneath most regulated development is that you can define a product, build it, then verify and validate it in distinct, sequential phases. Quality checks happen at the gates. Documentation gets written and reviewed at the end. Approval is a ceremony you perform before submission.
The phase gate model has a certain appeal because it creates the illusion of control. At each gate, someone says, “yes, we’re ready to move forward,” and the project advances. What it doesn’t do is build quality into the product. It inspects for quality after the fact, at the point in the process where finding a problem is most expensive.
Here’s the part that surprises people who have been working in these systems for years: many of the rules enforcing this linear model aren’t regulatory requirements. They are your company’s procedures, written years ago to satisfy regulations, now treated as if they came from the FDA itself. People inside these organizations hold up the regulatory card, citing “we have to do it this way because of the regulations,” when what they mean is “this is how our Standard Operating Procedures (OPS) say to do it.” The regulation is often far less prescriptive than the process built around it. If you don’t like the rules, we have good news for you: since you made the rules, you can change them!
What Design Controls Actually Require
The FDA’s design control regulation doesn’t mandate a waterfall process. What it requires is that you are in control of your design: that design inputs are defined, that design outputs are traceable to them, and that verification and validation happen. The sequence is not specified the way most companies treat it.
AAMI TIR45, the guidance document developed jointly by industry and the FDA to address Agile methods in medical device software, makes this explicit. The FDA participants on that committee were struck by something specific: in an Agile model, design controls are embedded everywhere, not just at stage gates. Every sprint, teams are defining requirements, building to them, and verifying against them. The feedback loop is continuous. Problems surface early, when they are cheapest to fix, not at month nine when the pressure to ship has overwhelmed the pressure to get it right.
The distinction the guidance draws is worth highlighting. Design controls are not a process. They are the controls that must exist within your process. Backlog items can map to design inputs. Your Definition of Done can map to design outputs. Continuous testing is continuous verification. The question is not whether your process contains these activities. It is whether those activities happen visibly, traceably, and are documented as you go rather than reconstructed at the end.
The Quality Person Who Becomes the Blocker
There is a version of this problem that quality and regulatory professionals know well. The development project wraps up, and suddenly the quality team is the bottleneck. They are handed a massive document package and asked to review and approve everything before submission. They know nothing about this product. They were not in the sprints. They were not in the design reviews. They are reading a design history file for the first time and being asked to stake their professional judgment on it.
This is not a quality person problem. It is a system problem, and it is the predictable outcome of a process that excludes quality from development and only brings them in at the end.
What the Agile model offers is incremental involvement. Instead of producing a massive document and asking someone to review the whole thing, you review and approve elements of it as you go. By the time you reach the final aggregate approval, the quality professional is not reading the document for the first time. They are confirming that the content came together the way they expected, because they were part of how it got built. The final approval becomes a checkpoint rather than a discovery session.
What One Client Did About It
Every engagement we run in the medical device space starts the same way: an assessment of the quality management system. That assessment tells us where the work is happening versus where the QMS says it should be happening, and the gap between those two things is usually where the regulatory tail lives.
With one client, the tail was a serious problem. Verification, validation, documentation, and approvals were piling up at the end of each release cycle, extending timelines by months and straining the team’s ability to get anything out the door on schedule. The root cause was straightforward once identified: approvals happened outside the development flow entirely. Tests got run, then documented, reviewed and approved separately, in a sequence that could take weeks and had nothing to do with when the actual work happened.
The change was to move test review and approval inside the sprint. They customized Azure DevOps to capture test records automatically as tests ran, to define who was authorized to approve (with documented training required before anyone got that role), and to require that approval happen within the same sprint the code was written. No more “export, attach, email, route, and wait” cycle. The record was created by the work. The approval was part of the task. By the end of the sprint, the test was written, run, reviewed, and signed off.
The principle behind this is worth naming: “built-in quality” versus “inspected-in” quality. When you embed the governance activity into the development activity, quality becomes a property of how the work is done, not a filter applied afterward.
One other concern is worth addressing directly. When teams start treating their work management tool as part of the design history file, a common reaction is worry that auditors will be able to see it. Sorry to tell you, but they already can. Your tools do not need to be formally designated as part of the design history file for an auditor to ask to see what is in them. Trying to keep your real process hidden while presenting a separate paper trail is not a compliance strategy. Building your real process well enough that you are comfortable showing it to anyone is.
Where to Start
The QMS assessment is the right starting point, and it does not have to be a months-long undertaking. You are looking for the places where the documented process diverges from what the team is doing and then asking whether that divergence reflects a problem with the process or a problem with the documentation. Usually both.
From there, the question is which governance activities can move earlier without sacrificing the intent behind them. Test review and approval is often a good first target because the bottleneck is visible and the fix is concrete. Design input reviews, risk documentation, and software change records are all candidates once you have a working model.
The goal is not to reduce rigor. It is to stop treating a long review cycle at the end of a project as equivalent to rigor applied throughout. One of those approaches produces a well-governed product. The other produces paperwork.
Want to learn more? Reach us to us at info@agilityirl.com to discuss the value of a QMS Assessment in your organization.
This post draws on conversations from the take5IRL podcast, including:
Episode 60 (Agile in a Regulated Environment)
Episode 65 (Why Should Quality and Regulatory Care About Agile)
Episode 82 (A TAIL of Woe: Improving Medical Device Development).
Listen at agilityirl.com or wherever you get your podcasts.