By Bruna Morais Schiekofer and Iliana Paspaleva (ERNI Germany)
In the product development of medical devices, there are strict requirements for planning, traceability, risk management and verification. For example, the norms IEC 62304 and ISO 13485 set some of these requirements. However, structural misalignment between project management and quality assurance remains common across organisations. Systematic divergence in priorities, accountability, metrics, tools and incentives directly impacts product quality, compliance, efficiency and safety.
Why quality assurance should be part of early project stages
Most MedTech quality problems do not arise during testing; they are introduced earlier in the software development lifecycle (SDLC) and then propagate into later phases.
The core phases of SDLC include planning, requirements engineering, design, development, verification and validation (V&V), deployment and maintenance.
Phase-by-phase risks in the software development lifecycle
Throughout the SDLC, different problems can arise in each phase. In the planning phase, estimation is crucial but difficult. Giving accurate time and effort estimates so early is fundamentally uncertain. In the requirements phase, it is often unclear whether all requirements are known and properly specified. Many requirements are refined or added later. During design, stakeholders frequently request many features, which can lead to overcomplicated solutions that must be cut back later for time or resource reasons. In development, it is important to establish standards and core technical decisions early, so the basics are implemented correctly. During verification and validation, gaps in strategy or failure to cover the V-model can let defects and the resulting compliance issues slip through. Finally, rollback or contingency plans are needed, and the ongoing maintenance and post-market activities shouldn’t be underestimated.
Planning phase
The planning phase is where the tone is set for the whole medical device project. It is decisive for medical device software because early decisions determine the regulatory pathway, risk posture, development effort, verification scope, and the evidence needed to demonstrate safety and effectiveness. This phase is crucial – most problems that derail projects are created here. A lot of estimation happens early, and if those calculations aren’t grounded in established procedures and reliable data, estimates can be either too pessimistic or overconfident. At the same time, consider the regulatory evidence and get input from clinical, regulatory, quality and technical experts. Accurate estimation matters not only for ISO 14971 risk management but also for validation and verification.
Define scope and project objectives
The planning phase is more than defining schedule and budget, it is the time to turn clinical needs, regulatory requirements and patient safety priorities into a clear, practical plan the team can follow. Begin with a crystal-clear definition of what is being built, the intended use, the targeted user group and the clinical context. Decide on the device classification early, because that choice defines how much documentation, testing and clinical evidence regulators expect.
Capture these essentials in a project charter that spells out purpose, stakeholders, success criteria, major milestones and constraints. Keep that document up to date so scope changes don’t occur unnoticed.
Integrate risk management from day one
Risk management must be integrated from day one. Build an initial risk plan aligned with ISO 14971. Define who the risk owner is, what the acceptance criteria are, and how mitigations will be tracked. Link each significant risk to requirements and design decisions, so mitigations are traceable and visible. Intentional trade-offs are always easier to handle than surprises that show up at the end.
Architectural choices should favour simplicity, modularity, and testability. Simpler designs are easier to validate and easier to support in the field. Check licences, plan supplier assessments, and be explicit about what suppliers must deliver and how their work will be verified. Contracts need clauses for audit access, change control, and who’s responsible if defects arise.
Build realistic plans and capable teams
Estimate realistically and always include buffers. Use historical data where possible, and break work into smaller milestones. Set an early working minimum viable product followed by iterations to add features and harden the solution. Allow extra budget for regulatory reviews and supplier delays. Put together a cross-functional team: regulatory, quality, clinical expertise, usability specialists, architects, engineers and operations. In case of known resource bottlenecks, consider support from external experts.
Finally, treat the project plan as a living document under change control. Schedule phase-gate reviews, internal audits and ongoing risk reviews. Plan post-market activities from the start, like complaint handling, vigilance reporting, maintenance and update processes, so the device can be supported safely over its lifetime. Small, deliberate investments in realistic planning, integrated risk thinking, supplier governance and cybersecurity pay off: fewer surprises, stronger regulatory submissions, and ultimately a safer, more reliable product in the hands of clinicians and patients.
Requirements engineering and management
Structured traceability from the beginning enables verifiable test coverage and reliable compliance evidence. In the MedTech context, late traceability creation introduces delayed verification and audit readiness. Requirements, risks, design, implementation, test cases, and defects must remain consistently connected throughout the lifecycle.
Design for testability
Testability must also be considered during the earliest architecture and design decisions. During defect management, systems with hard-to-isolate components make root cause analysis more difficult and lead to slow regression cycles and fragile test automation. The effective use of AI-driven development and testing approaches also depends on well-defined system architectures and clearly structured requirements.
Strengthen configuration management
Configuration management also begins during the initial stages of SDLC. QA cannot verify a system that does not have its requirements consistently controlled. Version control, baseline management, and environment consistency ensure stable builds, reproducible defects, and reliable verification activities.
Build an integrated toolchain
A topic that connects all these areas is environment and toolchain strategy. Toolchain decisions directly affect the feasibility of automation, integrity of traceability, and the effectiveness of configuration management. Disconnected tools create manual processes, weakening traceability and reducing integration efficiency. In addition, unstable environments decrease testing reliability and duplicate effort across teams.
When traceability, environment strategy, testability, and configuration management are treated as late-stage concerns, QA teams are forced into reactive verification efforts with increased compliance risk, operational inefficiencies, and reduced confidence in release quality.
To reduce these risks, organisations should:
- Define the traceability strategy at the beginning of the project, using integrated ALM and toolchain solutions to automate the generation of reports
- Establish clear relationships between requirements, risks, design elements, test cases and defects
- Maintain traceability continuously instead of reconstructing it before audits
- Include QA in architecture and design discussions from the beginning
- Design systems with modularity, logging and stable interfaces to improve testability
- Encourage close collaboration between developers and testers during feature refinement and implementation activities
- Use version control consistently across all artefacts while defining controlled baselines for code, environments, test data, and documentation
- Align releases, build results with configuration and requirements records
- Prioritise interoperability between requirements tools, test management systems, CI/CD pipelines and defect tracking platforms
Conclusion
Most of the quality and testing issues in MedTech originate from earlier development phases and accumulate throughout the SDLC. QA, including testing, is the first area where systemic weaknesses and failures become more visible. This puts the wellbeing of the team at risk, as the testing team is viewed not as a partner but as an enemy or obstacle to the project’s progress. Sustainable quality can only be achieved when project management, the development and QA team operate aligned with their responsibilities and collaborate on realistic planning sessions from the earliest stages of the SDLC.
