Using Agile Project Management To Improve Medical Device Development
By Jamme Tan,
In the early stages of developing a medical device product, you don’t know what you don’t know. A core technology is identified and it seems to be safe and effective, but will the market accept it? Will clinicians want to use it? Will patients fear it? What features will prove to be important, versus just bells and whistles?
Writing requirements during these early stages is important, but assuming they will not change and then rigidly assigning budget and schedule based on them is folly. Development is a process of incremental discovery and, therefore, change is likely to occur throughout.
For this reason, the use of agile project management practices is increasingly popular among medical device software development teams addressing the challenges posed by the rapid changes that often occur during the product development lifecycle. The agile approach enables project managers to establish more checkpoints to better refine products for their customers — patients — and important end-users, including physicians, nurses, and other hospital staff.
Are You Building The Right Product?
Design changes are to be expected throughout the medical device software development process, even if you understand your product’s market, since at times user wants and needs are different than expected. Also, changes can result from limitations in technology.
An example of a change scenario, occurring once the development phase is completed, is when early users indicate that some of the included features are not needed, and therefore, will not be used. These revelations are frustrating and costly, because these features’ development likely cost a significant amount of money and had an undesirable impact on time to market. Worse is when early users identify a significant unmet need, forcing the device to return to the development phase. This again raises development costs, delays time to market, and increases the risk that a “quick change” will result in a latent defect that will only be found later, after market entry. This is, in fact, where most software-related defects causing product warnings and recalls occur.
The use of agile project management can help avoid such scenarios, as it allows for faster feedback cycles with potential end-users. These faster feedback cycles present an opportunity to nix unneeded features or refocus efforts on new features that should be developed, based on user feedback.
Regulations, Waterfall, And Agile
FDA guidance and IEC 62304 can be read as implying sequence, which points to the “waterfall” process as the preferred development lifecycle method in many developers’ eyes. The waterfall methodology, or variations of it such as the spiral methodology, is a process that has been effectively used for decades. However, with waterfall, obtaining user feedback is only possible near the end of project, leaving little room to collect feedback to drive needed design changes throughout the development process. Because of the up-front planning inherent in waterfall, product design changes after design finalization can have an increasingly severe impact on the time and money spent to complete a project. Deviating from the plan is progressively disruptive and costly.
What this means is that stakeholders really need to consider which features are essential, and bring the most value, at a very early stage, the planning stage, of the product lifecycle — when they may not really know everything needed to make such decisions. You have a whole feature set and you plan to include all of the requirements into your first release. You are committing yourself to building out everything; when you design one feature, you design the whole system.
Say the product is released and then you discover that 80 percent of the features used come from only 20 percent of the product. This means that most of the features you spent time and money building are rarely, if ever, used. You need to ask, “What is the value of building all these features?” Therefore, waterfall presents some major challenges in medical device product development, where a process of incremental discovery is needed to help stakeholders learn what inputs are necessary to make a successful product, and issues discovered throughout development need to be incorporated back into design. These issues are more critical given the increasing uncertainty that exists in medical device projects attempting to push the frontiers of technology and innovation.
Regulators do not prescribe a specific development method.i Rather, they expect medical device manufacturers to establish and document their own development procedures,ii compliant with recognized standards (e.g., ISO 62304),iii and to demonstrate that products created using those procedures are safe and effective. Agile is a process created with change in mind; it concedes that requirements will change throughout the development process as more is learned about the system. With agile, you don’t design everything up front. You create a list of features and prioritize them. You work on the ones that are most important and allow less critical features to wait (and possibly fall off the list), which means you spend less time and money on unnecessary features.iv
Stakeholders identify all of the features they believe should be in the product, and then prioritize them based on several factors (complexity, business value, architectural need, dependencies, etc.). Because there are still many questions at the beginning of the project, properly prioritizing features allows you to work on important features, as well as the features you have stronger understanding of, and allows you to use time and resources to find answers to questions — or to challenge assumptions.
The agile approach also provides more checkpoints, allowing you to better refine what you are building for the customer, and what they are ultimately providing to the end user. Agile provides the opportunity to take what you created, give it to a client, and elicit feedback. Based on the feedback, you can determine whether you are going in the right direction. If changes are required, you give yourself the opportunity to adapt and adjust.
Additional Considerations When Applying Agile To Medical Devices:
Proper implementation of an agile process for medical device development includes sufficient consideration of these issues:
- Risk and safety — When developing medical devices, many inputs that must be taken into consideration. Identify the needs of the end user, but also understand the potential risks that the product may present to end users, and ensure that your product is sufficiently safe and effective by designing risk mitigations into your medical device. When using the agile process, you must understand how the risk management process fits in, and then integrate that approach into the project development plan.
- Architectural planning —Software design undergoes constant refinement when using an agile development process, which is to be expected, given the iterative nature of agile and the lack of a full upfront design. But with medical device development, it is advisable to make architectural considerations part of the planning process and to design a proper foundation.
- Manage your team and drive up collaboration to help avoid roadblocks — The lack of, or insufficient, collaboration between team members is a common pain point for medical device development teams. Implementing agile development techniques (e.g., daily standup meetings), even when used outside of an agile process, can facilitate and encourage collaboration between team members and, as a result, improve product quality and team efficiency.
- Early feedback — Demonstrating a working product to stakeholders, even if it is not fully feature complete, allows important feedback that can be used to improve and refine the end product. Usability studies and human factors assessments are now required by FDA and ISO processes. These are key ways to obtain some of the most valuable feedback.
- Stakeholders seeking change — The kind of flexibility that agile provides can be abused to the point where it has a negative impact on the project. Because an agile process was meant to support change, it is not uncommon for stakeholders to continually seek change (i.e., add new features to a product), which naturally extends the project cost and completion time. In other words, people like to squeeze as much as they can into a single submission. It is important to understand how to properly manage and avoid this particular pitfall.
Conclusion
There will always be unknowns at the beginning of a medical device project, and you should expect further surprises throughout. Agile helps manage projects in light of these expected changes.
Agile project management is quickly growing in popularity among medical device product development organizations because it can deliver many benefits in the development process, in particular because of its iterative nature. Agile allows medical device developers to collect feedback throughout the development process, because it provides an opportunity to elicit feedback to find out if a project is going in the right direction. In the end, this means that your product can more accurately meet the needs of patients, clinicians, and other users on the front lines, helping to save lives.
About The Author
Jamme Tan is an engineering manager at Sterling Medical Devices with over 10 years of medical device experience. A Certified SCRUM Master and Certified SCRUM Product Owner, Jamme leverages his expertise in agile development, project management, and product lifecycle management to lead a team of developers and system engineers, and to drive medical device development from the conceptual stage through final verification and maintenance support. Jamme has managed wide-ranging projects involving implantables, embedded development, web development, application development, and hospital data informatics systems. Additionally, Jamme has designed architecture for various full system medical device solutions and is experienced in risk management and DHF remediation.
Resources
- Association for the Advancement of Medical Instrumentation, pg. 28 ANSI/AAMI/IEC 62304:2006
- U.S. Food and Drug Administration, General Principles of Software Validation; Final Guidance for Industry and FDA Staff, Section 5.1
- U.S. Food and Drug Administration, The FDA Perspective on Human Factors in Medical Device Software Development
- Sterling Medical Devices, Implementing Agile Project Management Saves Time & Money