Project Management in Medical-device Development

The project manager's role

A medical-device project manager does more than track actions, budget and dates. The role creates the organisational conditions in which specialists can make sound decisions, produce controlled evidence and expose problems early enough to act.

See MTL-218 — Product Management in Medical-device Development for the complementary role of defining and maintaining product intent.

Build one integrated development plan

A schedule assembled from independent departmental dates is not an integrated plan. Medical-device development requires explicit connections between the evolving product definition and the evidence needed to support it.

• Define lifecycle stages, work products, reviews, verification, validation, transfer and release activities.
• Identify accountable owners, contributors, approvers and interfaces for each work product.
• Connect regulatory, clinical, risk, usability, cybersecurity and quality activities to engineering decisions.
• Show supplier deliverables, lead times, controls, reviews and acceptance dependencies.
• Plan representative units, configurations, fixtures, laboratories, equipment, data and test environments.
• Include technical-documentation, submission, manufacturing, training, service and launch readiness.
• Maintain the plan as knowledge, scope, risk and regulatory strategy change.

The development plan should be controlled but usable. It may reference detailed workstream plans, provided the interfaces and governing baseline remain clear. Planning is a lifecycle activity, not a document approved once at project start.

Manage dependencies, assumptions and baselines

The most damaging project delays often begin as invisible dependencies: validation planned before user needs are stable, formal testing before the product configuration is defined, or production equipment ordered before critical design decisions are resolved.

Track assumptions separately from confirmed facts. Give each important assumption an owner, validation method and decision date. If the project schedule depends on an unconfirmed classification, supplier capability, clinical route or technical performance, the resulting schedule range should remain visible.

A baseline is more than a date. It identifies the approved set of requirements, risks, architecture, outputs or evidence against which subsequent work and change are assessed.

Use decision gates to assess readiness

A useful gate decides whether the project has sufficient maturity and controlled uncertainty to commit to the next stage. It is not a ceremonial meeting or a presentation of percentage-complete metrics.

• Define required inputs and decision criteria before the review.
• Confirm that reviewers receive the controlled material early enough to assess it.
• Include the functions competent to evaluate product, safety, regulatory, technical and commercial readiness.
• Separate evidence, assumptions, open actions and management judgement.
• Record the decision, rationale, conditions, dissenting concerns, actions and accountable owners.
• Allow proceed, conditional proceed, repeat, redirect, pause or stop outcomes.
• Control changes to the baseline and commitments created by the decision.

Contribution across the lifecycle

Project-management emphasis changes as the product matures, but integration and evidence control continue throughout.

See MTL-101 — The Medical-device Development Lifecycle for the complete lifecycle context.

Plan evidence, not merely activity

Formal verification and validation are frequent sources of late delay because the project planned test execution but not the prerequisites for valid evidence.

Reserve time for protocol review, sample manufacture, conditioning, laboratory booking, equipment qualification, investigation, corrective work, justified regression and report approval. Assuming every test passes first time is not a credible project baseline.

See MTL-106 — Verification and Validation for the underlying evidence model.

Suppliers, change and escalation

Outsourcing work does not outsource project dependencies or manufacturer responsibility. Supplier plans must connect to the same requirements, risks, interfaces, configuration and evidence system as internal work.

• Define deliverables, acceptance criteria, records, reviews, access rights and change notification in agreements.
• Include supplier lead times, dependencies, quality controls and evidence in the integrated plan.
• Escalate capability, access, intellectual-property or continuity concerns before dependency becomes lock-in.
• Assess every proposed change for effects on requirements, risks, interfaces, evidence, submissions and released product.
• Retain the original result and rationale when a failure, deviation or project decision causes rework.
• Use impact assessment to define regression and revalidation—not schedule pressure alone.

Project escalation should describe the decision needed, available evidence, uncertainty, consequences, options, recommendation and latest responsible decision date. Escalating only “red status” transfers the problem without enabling a decision.

Common misconceptions