Program Management

PProgram management in medical-device development is the coordinated planning and control of a device program across its complete lifecycle. It aligns engineering, quality, regulatory, clinical, manufacturing and supply-chain workstreams with design controls, risk management and a structured Phase-Gate Process so that a safe, compliant product can reach the market on schedule.

What is program management in medical-device development?

Program management operates one level above individual project management. A project delivers a defined output, such as a completed verification campaign, software release or manufacturing process validation. A program coordinates multiple related projects and cross-functional teams toward a strategic outcome: a regulatory-cleared, manufacturable and market-ready medical device.

The program manager coordinates:

• Program scope and objectives
• Development schedules and milestones
• Budget and resource allocation
• Engineering workstreams
• Quality and regulatory activities
• Clinical and usability evidence
• Supplier and manufacturing readiness
• Risk and issue management
• Phase-gate reviews
• Design changes and their downstream effects

In a regulated environment, this coordination is not administrative overhead. Design controls under ISO 13485:2016 Clause 7.3 and the FDA Quality Management System Regulation require documented planning, assigned responsibilities and design reviews at planned stages. Program management ensures that these activities are scheduled, resourced, documented and completed at the appropriate point in development.

Why program management matters in medical-device development

A medical-device program carries risks that a typical commercial product does not. A missed design input can emerge as a field failure years later. A gap in the Design History File can delay an FDA 510(k), PMA or CE-marking submission. Weak coordination between engineering and production can result in failed process validation during design transfer.

Good program management identifies and contains these risks when changes are still relatively inexpensive. It keeps ISO 14971 risk management connected to engineering decisions instead of treating it as documentation prepared shortly before submission.

It also gives leadership a realistic view of:

• Whether development milestones are achievable
• Which evidence is still missing
• Whether technical risks threaten the launch
• Whether suppliers and manufacturing processes are ready
• Whether the selected regulatory pathway remains viable
• How proposed changes affect budget and schedule

Program management also protects audit readiness. When an FDA investigator or notified-body auditor asks for evidence that reviews occurred at the required points, the records exist because the program followed a documented plan with defined responsibilities and approvals.

How program management works

Most medical-device programs follow a phase-gate or stage-gate model. Development work is divided into phases, with each phase ending at a formal decision point. Every gate has defined entry criteria, required deliverables, responsible reviewers and exit criteria.

A typical medical-device program includes the following phases.

Concept and feasibility

The concept phase establishes the clinical or user problem the product will address and determines whether the proposed solution is technically, commercially and regulatorily feasible.

Typical activities include:

• Defining user needs
• Establishing the device’s intended use
• Identifying the intended patient population and users
• Assessing technical feasibility
• Preparing a preliminary ISO 14971 risk analysis
• Evaluating applicable standards
• Reviewing intellectual-property considerations
• Establishing an initial business case
• Identifying the probable regulatory classification and pathway

The feasibility gate should confirm that the concept is sufficiently defined and defensible before substantial resources are committed to detailed development.

Program planning

During planning, the team establishes the controlled framework under which the device will be developed.

Typical deliverables include:

• Design and development plan
• Program schedule and phase-gate structure
• Roles and responsibilities
• Resource plan
• Budget
• Quality and regulatory strategy
• Risk-management plan
• Usability-engineering plan
• Software-development plan where applicable
• Verification and validation strategy
• Supplier and manufacturing strategy
• Communication and escalation process

The schedule should be tied to deliverable readiness rather than dates alone. A gate should not pass simply because the calendar says the next phase is due to begin.

Design and development

The design-and-development phase converts approved user needs into design inputs and then into controlled design outputs.

Activities may include:

• System and product architecture
• Mechanical design
• Electronics development
• Embedded software and firmware development
• User-interface development
• Prototype construction
• Design reviews
• Supplier selection
• Risk-control implementation
• Requirements traceability
• Preliminary manufacturing planning

The risk-management file must remain current as the design evolves. New hazards, failure modes and risk controls should be reflected in requirements and verification plans rather than added retrospectively.

Verification and validation

The verification and validation (V&V) phase confirms that the device was designed correctly and meets its intended use.

Verification demonstrates that design outputs satisfy approved design inputs. Depending on the device, it may include:

• Mechanical performance testing
• Electrical-safety testing
• EMC testing
• Software verification
• Reliability and environmental testing
• Biocompatibility testing
• Packaging and transportation testing
• Dimensional inspection
• Design analysis

Validation confirms that the finished device meets user needs and intended use under actual or simulated use conditions. Validation is normally conducted using production-equivalent units and may include usability validation, clinical evaluation or device-specific performance studies.

Program management ensures that test protocols, samples, equipment, acceptance criteria, reports and traceability are ready in the required sequence.

Design transfer

Design transfer converts the approved product design into controlled production specifications, processes and inspection methods.

Typical activities include:

• Releasing drawings and specifications
• Finalizing the Bill of Materials
• Establishing work instructions
• Qualifying suppliers
• Developing production fixtures and test equipment
• Completing PFMEA and control plans
• Validating manufacturing processes through IQ, OQ and PQ
• Establishing incoming, in-process and final inspection
• Completing packaging and labeling controls
• Training production personnel
• Confirming production readiness

Successful transfer requires close coordination with the selected medical-device manufacturing operation. Involving manufacturing only after design freeze can expose tooling, tolerance, assembly and test problems when they are most expensive to correct.

Launch and post-market management

The launch gate confirms that the device, manufacturing system, regulatory approvals, labeling, distribution controls and post-market processes are ready for commercial release.

After launch, responsibility moves into controlled product lifecycle management. Activities may include:

• Post-market surveillance
• Complaint monitoring
• Vigilance reporting
• CAPA
• Supplier changes
• Component obsolescence
• Sustaining engineering
• Cost reduction
• Regulatory sustenance
• Field-service support
• Product retirement planning

Program management ensures that knowledge, unresolved risks and open actions are transferred to the teams responsible for sustaining the device after release.

Managing changes across the program

Change control connects all program phases. A requirement, component, supplier, software or manufacturing change can affect several previously approved deliverables.

A proposed change should therefore trigger:

1. Description and justification of the change
2. Identification of affected requirements and design outputs
3. Risk assessment
4. Regulatory-impact assessment
5. Manufacturing and supplier assessment
6. Verification and validation impact analysis
7. Documentation updates
8. Review and approval by authorized functions
9. Implementation and effectiveness confirmation

The purpose of change governance is not to prevent improvements. It makes the complete cost, schedule, safety and regulatory impact visible before a change is approved.

Software workstreams should follow IEC 62304 lifecycle controls. Cross-functional reviews, a living program-risk register, controlled traceability and schedules linked to gate criteria help keep software, hardware, quality and regulatory activities connected.

Common challenges and best practices

Treating gates as calendar events

A common failure is holding gate reviews because they appear on the schedule rather than because the required evidence is ready. Passing an incomplete gate only moves unresolved problems into a later phase where correction becomes more expensive.

Hold gates based on defined readiness and objective evidence, not the planned date alone.

Disconnected documentation

Programs struggle when the schedule, risk file, Design History File, requirements and test evidence are maintained separately by different people without controlled connections.

Documentation then drifts, and teams must reconstruct decisions before an audit or submission. Maintain traceability from user needs through design, risk controls and verification in a controlled system throughout development.

Scope creep

Late requirement additions can affect design inputs, architecture, risk analysis, verification, validation, manufacturing processes and regulatory documentation.

Strong change governance does not automatically reject scope changes. It quantifies their complete downstream impact so decision-makers understand the true cost and schedule implications.

Late involvement of quality and regulatory teams

Programs that treat Quality Assurance and Regulatory Affairs as final reviewers frequently discover that an earlier engineering decision created a regulatory problem or closed off a viable submission pathway.

Include quality and regulatory representatives from concept and feasibility onward, with genuine authority at design reviews and gate decisions.

Unrealistic schedules

Medical-device schedules sometimes assume that engineering, testing, supplier qualification and regulatory preparation can proceed independently. In reality, these activities have significant dependencies.

Build schedules around evidence flow. For example, formal verification cannot finish until requirements are approved, designs are released, test methods are ready and representative units are available.

Weak ownership

Every critical deliverable and open action needs a named owner and completion date. Collective responsibility without individual accountability often results in unresolved tasks remaining open across multiple gates.

Program-management best practices

Effective medical-device programs generally follow these principles:

• Define gate deliverables and decision authority at the beginning.
• Maintain a single integrated schedule across engineering, quality, regulatory, clinical and manufacturing activities.
• Keep risks, requirements, changes and verification evidence traceable.
• Track program risks separately from product safety risks while maintaining connections between them.
• Review the critical path regularly.
• Escalate decisions early instead of hiding schedule problems.
• Include QA/RA and manufacturing from the concept phase.
• Require objective evidence before closing actions or passing gates.
• Record decisions, rationales, owners and deadlines.
• Reassess the regulatory pathway when intended use, claims or design scope changes.
• Plan design transfer and post-market responsibilities before development is complete.

How SJML helps with program management

SJML manages programs through its end-to-end medical device design and engineering capabilities, supporting products from concept and feasibility through architecture, detailed design, verification and design transfer.

Phase-gate program management and structured change control are built into SJML’s engineering workflow. ISO 14971 risk management and IEC 62366 usability engineering are integrated into development instead of added near submission.

In-house laboratories support electrical safety, IEC 60601, EMC, reliability, environmental and endurance testing. This reduces external handoffs and allows verification activities to remain coordinated with the development schedule.

SJML’s QARA specialists work alongside engineering teams to keep device classification, regulatory strategy, technical documentation and submission evidence aligned with design decisions across Class I, II and III devices.

Frequently asked questions