Balancing Agile Delivery and Regulated Validation at a Medical Device Manufacturer
Veltrix Medical Devices manufactures infusion pumps at three ISO 13485-certified sites and generates €540 million revenue. It wants predictive maintenance and agile product development. The €6 million programme must show results within 15 months. Forty percent of critical machines have no sensors, the operational technology network is flat and shares credentials with the enterprise network, and the manufacturing execution system is 22 years old with no vendor support. A six-month pilot on one line cut unplanned downtime by 18%, but 27% of sensor readings were unusable and maintenance planners still used spreadsheets. The vendor proposes a big-bang rollout across all sites in month nine, while the quality director insists on validation before any change. The CIO wants a cloud data platform; the plant managers want local control. Two sites have no dedicated data engineer.
1. Recommend a delivery methodology that combines agile ways of working with the validation constraints of a regulated manufacturer, and justify how it would apply to the predictive-maintenance rollout.
Read the worked answer
A pure agile approach is unsuitable because validated manufacturing changes require documented evidence, traceability, and change control; a pure waterfall approach is too slow and hides data-quality problems until late. The appropriate model is a hybrid: agile execution inside stage-gated validation. Product increments are delivered in short cycles, but each increment passes a predefined validation gate covering intended use, risk, data integrity, and change control. For predictive maintenance, the team should treat the model, sensor data pipeline, and maintenance workflow as separate increments. The first increment proves data quality on one line, the second proves a maintenance decision workflow, and the third proves scale readiness. Each increment has a definition of done that includes validation evidence, not just working software. This addresses the 27% unusable readings by making data quality a gate criterion, and it gives the quality director the assurance that no unvalidated model influences maintenance decisions. It also allows the vendor's month-nine target to be reframed as a scale decision, not a fixed deadline.
2. Design the technology and data governance needed to connect OT and IT without creating unacceptable security or operational risk.
Read the worked answer
The flat OT network with shared credentials is the dominant risk, so segmentation must precede any sensor expansion. The architecture should separate the OT demilitarized zone from the enterprise cloud platform, with brokered, authenticated data flows and least-privilege service accounts. Sensor data should land in a governed data layer with quality rules, lineage, and ownership; the 27% unusable readings show that data quality cannot be an afterthought. Governance should distinguish between model ownership, data ownership, and change authority: plant managers own operational use, the CIO owns the platform, and a joint data council owns definitions and quality thresholds. Because two sites lack data engineers, the programme should provide a central data engineering service with local domain experts rather than expecting each site to build its own capability. The cloud platform is acceptable only if data residency and vendor-support risks are resolved for the unsupported MES. A security review and a validated data-flow diagram should be mandatory gates before the second site is connected.
3. Sequence the rollout across the three sites and define go/no-go criteria that balance the 15-month result expectation with validation and capability constraints.
Read the worked answer
The rollout should be sequenced by capability and risk, not by the vendor's month-nine date. Site A, which hosted the pilot, should first close the data-quality gap and prove a validated maintenance workflow with planners using the tool instead of spreadsheets. Site B should follow only when it has network segmentation and a named local data steward; Site C should be prepared in parallel with sensor installation but not connected until the central data service can support it. The 15-month expectation should be met by demonstrating measurable downtime reduction on Site A and reusable patterns for B and C, not by claiming enterprise scale. Go/no-go criteria should include: at least 95% usable sensor readings over four weeks; validated change control for any model that triggers maintenance action; planners completing the workflow in the tool for 80% of alerts; security segmentation signed off; and a documented benefit baseline. If a criterion fails, the decision is to remediate within a bounded period, not to proceed on schedule.