typically everyone agrees on. As development proceeds with tangible demos along the way, the true requirements and true correct design choices are much easier to discern.
But what about the FDA?
Many of us have had the unpleasant experience in waterfall oriented medical device projects of being stuck in the requirement definition phase for years as developers and marketing people struggle with the practically impossible task of trying to come up with the perfect final and unchanging detailed requirements specifications for a product that most can only dimly picture in their heads. Similarly many of us in engineering have wasted countless hours in pointless abstract philosophical technical debates that could have been resolved faster with some quick prototyping. These discussions can become quite heated because everyone sees these paper exercises as their one and only chance to affect the direction of a project that often may last years.
Companies repeatedly bang their head against this wall because they assume that it is a requirement of the FDA. However, as the FDA clearly states in the preamble to 21 CFR 820: “It is not the intent of the FDA to apply the design control requirements to the research phase. Instead the regulation requires the establishment of procedures to ensure that whatever design is ultimately transferred to production is, in fact, a design that will translate into a device that properly performs according to its intended use and user needs. To assist FDA in applying the regulation, manufacturers should document the flow of the design process so that it is clear to the FDA investigator where research is ending and development of design is beginning.”
I suggest that the FDA’s position here is entirely reasonable. I agree that the final product transferred to manufacturing needs to be well documented. However, the mistake I believe many companies make is locking themselves into a design without an adequate research phase. Most medical device companies will have an upfront specification development phase in their standard development processes. My proposal is that this phase would be more effective it were used as a specification development and prototyping phase in which agile iterations are used to zero in on the core design and features of the project before creating the traditional software requirement and design specifications. To formalize the transition from the research/prototype phase to the formal design control phase I would have a phase review that bought off on the documentation and commented on the code developed during the phase. I would timebox this upfront phase to maybe 6-9 months for a 2 year project. The goal of this is twofold. One it serves the purpose of clarifying to FDA regulators that there will be a transition from the research phase to the formal design controls phase. Secondly it gives a time frame as to when a phase review will be held that is similar in format to that expected by traditional waterfall advocates. This can blunt any criticism of those in the company that are skeptical of agile development.
My assumption is that at the end of the research phase almost all of the code would be transferred over for use in the production product, however even if the upfront agile development process went horribly off track and waterfall oriented reviewers in a phase review wanted to reject the entire code base, I still think there is huge benefit to this upfront exercise.
Specifically some of the benefits are:
- Make specification development discussions more productive through the agile practice of prioritized feature lists (a.k.a. the product backlog).
- The agile process of alternating between requirements gathering