insights
Introduction
Scope creep is usually treated as a failure of planning. While this can be the case, we on the Engineering team at Kapstone feel that it can be a sign that the development team is doing its job.
Project management training often frames scope creep as something to prevent: requirements that grow after kickoff, features added without budget, and schedules that slip as a result. Those consequences are real. But the cause is often not poor discipline, it is new information. New product development runs on new information.
Key Takeaways:
- Scope creep is often new information, not poor planning. In new product development, requirements grow because the team is discovering what the device actually has to do. That's the process working, not failing.
- Ask why each requirement exists. Questioning who uses the device, where, and what happens when something goes wrong surfaces hidden assumptions and legitimate new design inputs the original feature list missed.
- In a regulated program, a scope change is never only a design change. One revised user need can ripple through design inputs and the traceability matrix, the ISO 14971 risk file, verification protocols and fixtures, usability and clinical validation, biocompatibility/sterilization/packaging, and regulatory strategy.
- Find changes early, when they're cheapest. A requirement caught in a cadaver lab costs far less to address than one caught in summative validation, and far less than one found after launch.
- Name every change and give the customer options. Treat each change as a decision made with full information — its effect on design, risk, testing, schedule, and cost — and offer paths forward (absorb, phase, trade, or decline) so the customer can weigh the trade-offs.
Interested In More?
Sign up for our newsletter to stay up to date with the latest updates, news and more from Kapstone Medical.
Understanding user needs moves the scope
A customer arrives with a concept, a sketch, or a list of features. A design team that only builds to that list will rarely see scope change. It may also miss what the device needs to do.
A team that asks why each feature exists gets different answers. Who uses the device, and where? What happens before and after it is used? What does the surgeon, nurse, or patient do when something goes wrong? How is it cleaned, packaged, shipped, and stored?
These questions lead the customer to re-examine assumptions they did not know they had made.
A handle designed for one grip turns out to be used in three. A single-use component turns out to need reprocessing. A benchtop feature turns out to matter in the operating room, where the various aspects of the environment change how it is used. Each finding is a legitimate change to the design requirements and design inputs, and they should not be ignored! From a 30,000 foot view, these findings and changes look like scope creep.
A requirement found during a cadaver lab costs less to address than one found in summative validation, and far less than one found after launch.
Why change carries more weight in medical devices
In a regulated program, a change to scope is never only a change to the design. Under design controls, one new or revised user need can affect:
- Design inputs and the traceability matrix that links them to outputs
- The risk management file, including new hazards, hazardous situations, and risk controls under ISO 14971
- Verification protocols, test samples, and fixtures
- Usability and clinical validation plans
- Biocompatibility, sterilization, packaging, and shelf-life testing
- The regulatory strategy, including predicate comparison and testing expectations
Communication turns change into a decision
Scope creep becomes a problem when it happens without being named. Small additions accumulate in design reviews and email threads, each one accepted in good faith. Months later, the schedule and budget no longer match the work, and neither side can point to when that happened.
Kapstone’s approach is to treat every change as a decision the customer makes with full information. When a new need surfaces, the team should state plainly:
- What changed and why it matters to the user or patient
- Which design inputs, risk analyses, and test plans it affects
- The estimated effect on schedule and cost, including downstream testing
- What happens if the change is deferred or declined
This should happen when the change is identified, not at the next milestone. Customers rarely object to the cost of a well-understood change. They object to learning about it late.
Give the customer options, not only a change order
Reporting impact is half the job. A good design team also proposes ways forward, so the customer can weigh trade-offs instead of accepting or rejecting a single number. Typical pathways include:
- Absorb it now. Incorporate the change into the current design, with a revised schedule and cost estimate.
- Phase it. Launch with the current scope and plan the change as a follow-on design revision, with its own regulatory assessment.
- Trade it. Remove or simplify a lower-value feature to hold the schedule.
- Decline it. Document the rationale and any residual risk in the design history file.
Each option has a different effect on schedule, cost, risk, and regulatory strategy. Laying them side by side lets the customer choose based on their business priorities, funding, and market timing, which the design team does not fully control and should not assume.
Recommendation
Stop treating scope creep as something to eliminate. Treat it as something to manage. Question every requirement early, when changes are cheapest. Name each change when it appears, and state its effect on design inputs, risk, testing, schedule, and cost. Then give the customer options for how to move forward and let them decide.
A project whose scope never changed either had perfect information at kickoff, which is rare, or the team stopped asking questions, which is a risk. The goal is not to avoid scope creep. It is a device that meets its users’ needs.
