---
title: Project Management for Regulated Product Development: Tools and Methods for Startups
description: Regulated MedTech project management combines design controls, regulatory milestones, and lean execution. Here is the toolkit that works at startup scale.
authors: Tibor Zechmeister, Felix Lenhard
category: Team Building, Operations & Scaling
primary_keyword: project management regulated product development
canonical_url: https://zechmeister-solutions.com/en/blog/project-management-regulated-product-development
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Project Management for Regulated Product Development: Tools and Methods for Startups

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **Project management for regulated product development is the discipline of running a MedTech project against three simultaneous plans — the engineering plan, the design controls plan required under EN ISO 13485:2016+A11:2021 clause 7.3, and the regulatory milestone plan that ends at a CE certificate. The toolkit that works at startup scale is deliberately small: one integrated backlog, a design controls register that mirrors clause 7.3 stages, a milestone tracker tied to MDR Article 10 obligations, and a weekly cadence that forces the three plans to stay in sync. Anything more elaborate collapses under its own weight at startup size. Anything less loses traceability.**

**By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.**

---

## TL;DR

- Project management for regulated product development is not general PM with a compliance layer bolted on. It is the integration of engineering execution, design controls under EN ISO 13485:2016+A11:2021 clause 7.3, and regulatory milestones tied to MDR Article 10 obligations, run as one project with one backlog.
- The toolkit at startup scale is small on purpose: an integrated backlog, a design controls register mirroring clause 7.3 stages, a milestone tracker tied to the regulatory roadmap, and a weekly cadence where engineering and regulatory status are reviewed together.
- Document control under EN ISO 13485:2016+A11:2021 clause 4.2 is the structural backbone of the project management system. If document control is broken, every other tracker lies.
- Regulatory milestones are gate-style events, not stretch targets. A milestone either has its evidence or it does not. Treating milestones as aspirational is the single most common cause of slipped CE mark timelines.
- The failure modes are predictable: parallel plans that diverge, templated PM tools that do not match the work, late design control entries that amount to retrospective documentation, and founders who track engineering in one tool and regulatory in another and never reconcile them.
- Felix's doubling rule applies to project plans: estimate the work honestly, then double the estimate. The companies that hit their plans are the ones that did the doubling up front, not the ones that hit their original optimistic estimate.

---

## Why regulated project management is a different discipline

A founder running a MedTech startup in Graz spent six years not shipping a device that could have shipped in 2020. The engineering kept moving. The documentation kept moving. The regulatory plan kept moving. Each of the three lived in a different place, managed by a different person, tracked on a different cadence. Every time one of the three changed, the other two fell out of alignment, and the cost of pulling them back together was higher than the cost of any single change. The project did not fail because the team was lazy. It failed because there was no single project. There were three parallel projects pretending to be one.

This is the pattern regulated project management exists to prevent. In an unregulated software startup, project management is the discipline of shipping a feature set against a business goal. In a MedTech startup, it is the discipline of shipping a feature set against a business goal while simultaneously producing the traceable evidence that the feature set was developed under design controls, documented under a controlled QMS, and certified under the correct conformity assessment route. Those are not three projects. They are one project with three output streams, and the project management system has to treat them as one.

The companies that get this right run their engineering, their design controls, and their regulatory milestones off a single backlog with a single weekly cadence. A Salzburg SaaS company Tibor worked with is the reference example — disciplined Phase 1 feasibility, a design freeze decision that was a real meeting with a real output, and a Phase 2 build where every engineering ticket either had a design controls counterpart or was explicitly marked as out of scope for the regulated product. They shipped. The companies that get it wrong run engineering in one tool, regulatory in another, and hope the two converge at audit. They almost never do.

## What makes regulated project management different

Three things separate regulated project management from general software or hardware PM, and all three have to be designed into the system from the start rather than retrofitted.

The first is **design controls as a parallel deliverable**. Every piece of engineering work in a regulated project has a corresponding design controls artefact — a design input, a design output, a verification or validation record, a design review entry. EN ISO 13485:2016+A11:2021 clause 7.3 structures these into design and development planning, inputs, outputs, review, verification, validation, transfer, and changes. The work does not exist for the auditor. It exists to make the device safe and effective. But it does have to exist in a form the auditor can read, and the only reliable way to produce that form is to capture it as the engineering work happens, not afterwards.

The second is **document control as the backbone**. EN ISO 13485:2016+A11:2021 clause 4.2 requires the manufacturer to establish, document, implement, and maintain a quality management system with controlled documents and records. In a project management context, this means every artefact that matters — the design controls register, the risk management file, the technical documentation, the test reports — lives under version control with a clear approval chain. A project management system without real document control is not a regulated project management system. It is a general project tracker with compliance aspirations.

The third is **regulatory milestones as hard gates, not aspirational dates**. A regulatory milestone — design freeze, technical file ready for submission, Notified Body audit, CE certificate — either has its evidence or it does not. There is no partial credit. Engineering milestones can be negotiated; regulatory milestones cannot. Treating regulatory milestones as soft targets is the single most common cause of missed CE mark dates, because the founder discovers at week 51 of a 52-week plan that the evidence for a gate that was supposed to close at week 30 was never actually produced.

## Design controls as the backbone of the project plan

The design controls register is the single most important artefact in a regulated project management system, because it is the only place where the engineering plan and the regulatory plan meet on the same page. EN ISO 13485:2016+A11:2021 clause 7.3 defines the stages — planning, inputs, outputs, review, verification, validation, design transfer, and design changes — and the register is the structured record of every entry against every stage for every element of the device.

At startup scale, the design controls register does not need to be a bespoke eQMS. A disciplined spreadsheet with version control works, provided the discipline is real. What it needs is three columns that every entry has to fill: the design controls stage under clause 7.3, the engineering ticket or work item it corresponds to, and the regulatory milestone it feeds into. If any one of those three is blank, the entry is either incomplete or the work is not actually regulated.

The common mistake is to treat the design controls register as a documentation task that happens after the engineering. That is how the Graz pattern starts — engineering ships a prototype, the regulatory person later tries to reconstruct the design inputs from Slack messages and commit logs, the reconstruction is always incomplete, and the resulting register is effectively a work of historical fiction. The fix is to make every engineering ticket require a design controls reference before it can be closed. Not a long reference. A short one. The engineer closing the ticket writes the design input, the design output, and the verification status in the ticket itself, and the register pulls from the ticket. The discipline is at the ticket level, not at the register level.

This is the point where Tibor's rule surfaces most directly — more documentation is not more quality. The design controls register should be exactly as large as the engineering work that feeds it. If it is larger, it contains speculation or duplication. If it is smaller, engineering work is being closed without its regulatory counterpart. Both are project management failures.

## Regulatory milestone tracking

Regulatory milestones are the hard dates in the project. The milestones that matter most, in the order they occur, are: intended purpose stabilised, classification decision documented, design freeze, technical documentation internally audited, Notified Body submission, audit closed, certificate issued, post-market surveillance system live. Every one of these is a gate. Every one either has its evidence or does not.

The milestone tracker at startup scale is a single-page document with three columns per milestone: the evidence required, the owner, and the status. Status is binary — evidence is complete and approved, or it is not. A milestone that is "80 percent done" is not 80 percent done. It is not done. The discipline of binary milestone tracking is what forces the project to confront reality each week rather than accumulating a slow drift between the plan and the truth.

The most common failure mode here is optimistic milestone dating. A founder under investor pressure commits to a CE mark date that was never defensible, the milestones get back-planned from that date, and every milestone that slips compounds into the next one. Felix's doubling rule is the antidote. When a regulatory plan is built, take the honest estimate and double it. The founders who apply this rule hit their revised plans. The founders who insist on the original estimate miss theirs, usually by more than the doubling would have cost.

The milestone tracker also has to link downward to the design controls register and upward to the business plan. Downward, because a milestone like "design freeze" is meaningless without the specific design controls entries that make freezing the design possible. Upward, because a milestone like "CE certificate issued" has commercial consequences that the board needs to plan against. The weekly cadence reviews both directions in the same meeting.

## Integrating regulatory and engineering plans

The integration of the engineering plan and the regulatory plan happens in one place: a shared weekly review where both plans are reconciled against a single backlog. This meeting is the structural centrepiece of regulated project management at startup scale. Without it, the two plans drift. With it, the drift is caught while it is still small enough to correct.

The agenda for the weekly review is deliberately short. Each open regulatory milestone gets a status update — evidence complete or not, blockers named, owner confirmed. Each engineering ticket closed in the past week gets its design controls reference checked. Each engineering ticket opened in the past week gets its design controls entry scoped. Any ticket that cannot identify a design controls counterpart is either out of scope for the regulated device or incorrectly scoped, and that gets resolved in the meeting. Any design controls entry that has no engineering counterpart is either speculation or tracking work the engineering team does not know about, and that also gets resolved.

The meeting is not a status report to the CEO. It is a working session between the engineering lead, the QA/RA lead, and the person running the regulatory milestones. At startup scale those may be two or three people, sometimes including the founder. The output of the meeting is a reconciled backlog, an updated milestone tracker, and a short written note capturing any decision that affects the design controls register. That note is itself a controlled document under clause 4.2 — every decision that touches the regulated project lives inside document control, not outside it.

## Tooling that works for small teams

The tooling question is where most startups overcomplicate the system. The instinct is to buy a big eQMS or a regulated ALM tool at the 3-person stage because a vendor presentation made it look essential. The reality is that at 3 to 10 people the tooling that works is small, integrated, and disciplined. At 30 people the conversation changes, and by then the team has enough context to choose the right tool. Buying a large tool too early typically produces an expensive system nobody uses, and the actual work moves into spreadsheets that no one admits exist.

The minimum viable tooling stack at startup scale is four pieces. A single engineering ticket tracker that every engineering work item lives in. A design controls register with controlled versions, cross-referenced to the tickets. A milestone tracker with binary status. A document control system — which can be a structured shared drive with real version control and real approval records, provided the discipline is enforced — that holds every controlled artefact. That is the whole stack. Anything more is premature optimisation.

The test for whether the stack is working is not whether it looks impressive. The test is whether a new hire on day one can open the four tools and understand what is happening in the project without the founder translating. If the answer is no, the stack is too complicated, too fragmented, or too undocumented — and each of those failure modes has the same fix, which is subtraction.

For more on how document control and the broader QMS scale across the 3-to-30 transition, read [the MedTech startup operations playbook from 3 to 30](/blog/medtech-startup-operations-playbook-3-to-30). For the underlying methodology behind the subtraction instinct applied here, read [the Subtract to Ship framework for MDR](/blog/subtract-to-ship-framework-mdr).

## Common mistakes startups make

Five mistakes come up repeatedly in regulated project management at startup scale. Each of them is fixable early and expensive late.

**Running parallel plans that never reconcile.** Engineering in one tool, regulatory in another, and no weekly meeting where the two are reconciled. The two plans drift, and by the time the drift is noticed it is too large to repair without rework.

**Retrospective design controls.** Engineering ships, and the design controls entries get written weeks or months later by someone who was not in the original discussion. The entries are always incomplete, and the gaps are exactly what auditors find first.

**Template-driven project structures.** Buying an "MDR project template pack" and replacing the company name. The structure encodes assumptions about a different company's work, and the team ends up either ignoring the template or contorting the work to fit it. Neither produces good project management.

**Optimistic milestones that get back-planned from a board date.** A CE mark date is chosen because the board wants it, milestones are back-planned from the date, and the first slipped milestone compounds into every subsequent one. The doubling rule exists because this failure mode is almost universal.

**Document control as an afterthought.** The project runs on shared drives with no version discipline, the design controls register is a spreadsheet nobody versions, and the first internal audit finds that nobody knows which version of which document is the controlled one. Document control is the backbone of the system, not a cleanup task for later.

## The Subtract to Ship angle on regulated project management

Subtract to Ship applied to project management means the same thing it means everywhere else in this blog: before adding a process, a tool, a document, or a meeting, strip the project management system down to what is load-bearing and only add what the work actually requires. The test is whether the artefact or activity traces to a specific obligation — under MDR Article 10, under EN ISO 13485:2016+A11:2021 clauses 4.2 or 7.3, under EN ISO 14971:2019+A11:2021, or under the business model itself. If it traces to none of those, it is drag and it comes out.

At startup scale the applied discipline is this. One backlog, not three. One design controls register, not a set of parallel trackers. One weekly cadence where engineering and regulatory are reconciled, not two separate meetings. One document control system, not a shared drive and an eQMS that contradict each other. Four tools maximum at 3 to 10 people. Subtraction is the project management system, not a periodic cleanup of an accumulating system.

For the wider roadmap context that these project management practices sit inside, read [the MDR regulatory roadmap for a startup](/blog/mdr-regulatory-roadmap-startup) and [the complete MedTech startup playbook for 2027](/blog/complete-medtech-startup-playbook-2027).

## Reality Check — Where do you stand?

1. Is your engineering plan and your regulatory plan the same plan, or are they two plans that meet occasionally?
2. Does every open engineering ticket have a named design controls counterpart, or does the design controls register exist in parallel to the engineering work?
3. When was the last time a regulatory milestone was marked "done" without its evidence being complete and approved, and who caught it?
4. Can you name the document control system that holds your controlled documents under EN ISO 13485:2016+A11:2021 clause 4.2, and could you state the current approved version of any given procedure within one minute?
5. Is there a weekly meeting where engineering and regulatory status are reconciled against one backlog, with a written output that goes into document control?
6. Did you apply the doubling rule to your current plan, or are you still working against the original optimistic estimate?
7. If a new hire joined tomorrow, could they open four tools and understand the project without the founder translating, or is the real state of the project only in the founder's head?

## Frequently Asked Questions

**What is project management for regulated product development?**
Project management for regulated product development is the discipline of running a MedTech or regulated project so that engineering execution, design controls under EN ISO 13485:2016+A11:2021 clause 7.3, and regulatory milestones tied to MDR Article 10 obligations are managed as one project with one backlog. It differs from general PM because every engineering work item has to produce a traceable design controls artefact, and every regulatory milestone is a hard gate with binary status.

**What tools do small MedTech teams actually need for project management?**
At 3 to 10 people, four pieces: an engineering ticket tracker, a design controls register mirroring clause 7.3 stages, a milestone tracker with binary status, and a real document control system that holds every controlled artefact under clause 4.2. Buying a large eQMS or regulated ALM tool at this stage usually produces an expensive system nobody uses while the real work moves into shadow spreadsheets.

**How do you integrate a design controls register with an engineering backlog?**
Make every engineering ticket require a design controls reference before it can be closed — the design input, the design output, and the verification status captured in the ticket itself. The design controls register pulls from the tickets. A weekly review reconciles the two. This keeps the regulatory artefacts in step with the engineering work rather than reconstructing them months later from memory.

**Why are regulatory milestones binary?**
Because the evidence for a milestone either exists and is approved, or it does not. There is no partial credit at a Notified Body audit. Treating regulatory milestones as soft targets produces the pattern where a milestone that was supposed to close at week 30 is discovered to be unmet at week 51, and the entire plan downstream has to be rebuilt under time pressure.

**What is the single most common project management failure at MedTech startups?**
Running the engineering plan and the regulatory plan as separate projects in separate tools with no weekly reconciliation. The two drift, the drift compounds, and the reconciliation cost at audit time is larger than the cost of having integrated the plans from week one.

## Related reading

- [How to Build a Regulatory Roadmap for Your MedTech Startup](/blog/mdr-regulatory-roadmap-startup) — the sequenced regulatory-work view that the project management system has to deliver against.
- [The Subtract to Ship Framework for MDR](/blog/subtract-to-ship-framework-mdr) — the subtraction methodology applied to every layer of the project, including PM tooling.
- [The Complete MedTech Startup Playbook for 2027](/blog/complete-medtech-startup-playbook-2027) — the end-to-end path the project management system runs inside.
- [The MedTech Startup Operations Playbook: From 3 People to 30](/blog/medtech-startup-operations-playbook-3-to-30) — how document control, training, and communication scale alongside the project management system.
- [Building a Lean QMS for MedTech Startups](/blog/lean-qms-startup) — the QMS that the design controls register and document control system live inside.
- [The Two-Phase Development Approach](/blog/two-phase-development-approach) — the time-axis discipline behind separating Phase 1 feasibility from Phase 2 MDR-compliant build.
- [The MedTech Startup Team: Key Roles You Need Before and After CE Marking](/blog/medtech-startup-team-key-roles) — the team the project management system sits on top of.
- [Document Control for Scaling MedTech Startups](/blog/document-control-scaling-medtech) — the clause 4.2 backbone in detail.
- [Management Review That Is Not Compliance Theatre](/blog/management-review-medtech-startup) — the governance forum that consumes the outputs of the project management system.
- [Preparing for Your First Internal Audit](/blog/first-internal-audit-medtech-startup) — the checkpoint where the integrity of the project management system is first tested externally.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10 (general obligations of manufacturers) including Article 10(9) (quality management system requirement). Official Journal L 117, 5.5.2017.
2. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Clause 4.2 (documentation requirements) and clause 7.3 (design and development).
3. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices.

---

*This post is part of the Team Building, Operations & Scaling category in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The project management toolkit described here is the working layer that sits underneath the operations playbook and the regulatory roadmap — read it alongside those posts, and use the Reality Check as a diagnostic for the integration of your engineering, design controls, and regulatory plans.*

---

*This post is part of the [Team Building, Operations & Scaling](https://zechmeister-solutions.com/en/blog/category/team-operations) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*