Fixed submission date, unstable requirements: choosing and defending a life cycle
Halden Medical is developing firmware for a Class II diagnostic device. The regulatory submission date is fixed at month 14 by contract with the distributor; notified body review takes a further six months. The approved plan is a single V-model release at month 14 with a design freeze at month 11. At month 8, formative usability testing with 12 clinicians shows that three of nine core workflows need redesign; 27 change requests are open; the requirements specification has been revised six times. The project manager proposes three incremental releases, each verified and validated, with the technical file built alongside. The regulatory lead objects: 'Auditors expect a frozen design. Iterations mean uncontrolled change and will fail the review.' Separately, the imaging module supplier has a 20-week lead time and can start only once its interface specification is final, and two key clinical reviewers are available only until month 12.
1. Does ISO 21502 require a predictive life cycle here? Explain how the life cycle and delivery approach should be selected.
Read the worked answer
No. ISO 21502 does not prescribe a single life cycle. It treats the project life cycle as the sequence of phases from start to closure, with decision points at phase boundaries, and expects the organisation to tailor the approach to the project's characteristics: degree of requirements uncertainty, complexity, criticality, contractual and regulatory constraints, stakeholder availability and the nature of the deliverables. Predictive, iterative, incremental, agile and hybrid approaches are all available, and a hybrid is often the honest answer.
The regulatory lead's premise - that compliance requires one waterfall release - is not a requirement of ISO 21502. What the regulator actually needs is a planned, documented and traceable development path. Incremental development is acceptable to notified bodies when it is planned in advance, each increment is baselined, verified and validated, and change is controlled.
The real constraints here are different and must be designed around: the imaging supplier's 20-week lead time (interface specification must freeze early, independent of the software increments) and the loss of clinical reviewers after month 12 (requirements decisions must be pulled forward).
2. Recommend a delivery approach that satisfies both the clinical uncertainty and the audit position. Justify each element.
Read the worked answer
Recommendation: incremental delivery inside a gated, documented life cycle.
- Three increments, each formally baselined and closed with verification and validation records, versioned requirements, traceability and design history file entries. This gives the auditor evidence per increment rather than one unverifiable final release.
- Change control board with defined thresholds: every change request gets an impact assessment on scope, schedule, risk, verification effort and regulatory impact before approval. Iteration does not mean uncontrolled change; uncontrolled change is what fails audits.
- Design freeze at increment boundaries for the released configuration, with the technical file assembled incrementally so the submission package is not manufactured in a panic at month 13.
- Early interface freeze with the imaging supplier: an interface control document signed by month 9 so the 20-week lead runs in parallel with software increments rather than after them.
- Front-load clinical decisions before month 12, using structured usability sessions to close the three redesigned workflows.
Justification: the approach converts uncertainty into a sequence of contained, documented decisions while protecting the fixed external date and the supplier lead time. The plan and the rationale for the approach should be recorded in the project management plan and shared with the notified body before execution, so the review scope matches what was built.
3. The sponsor asks what evidence would convince the regulator. Identify the governance and information elements that must exist.
Read the worked answer
Evidence the audit will look for:
- The chosen approach documented and approved before execution, including criteria for each increment and for the design freeze.
- Traceability from user needs to requirements to design to verification and validation results, maintained per increment.
- Configuration management of released baselines, with version history and the authority that approved each change.
- Complete change records: request, impact assessment, decision, decision-maker, implementation and re-verification.
- Risk file entries for the incremental approach itself (e.g. integration risk between increments) with responses.
- Records of clinical input and of usability findings, including the three redesigns, showing the decisions were made and why.
Governance point: the sponsor must approve the change of approach and its consequences (re-planning, resourcing of verification effort per increment, early supplier commitment) rather than delegating it to the project manager. The submission strategy and the delivery strategy must be consistent with each other; if they diverge, the regulator sees a plan the project did not follow, which is a worse finding than a hybrid plan properly executed.