Medical Device Product Development
As for any product, you must carefully plan and oversee the development of your medical device. A set of product development guidelines should be prepared early on in the development of the device, not later than when your team defines the product requirements.
The Trio of Development Constraints
When planning the path to a product release, the engineering teams should determine the Trio of development constraints regarding the product:
- What are the requirements?
- How are the requirements prioritised?
- How much effort and resources are needed to finish the product?
The output of the mentioned process is an ordered list of product requirements for the specific device.
The Project Trio
The next group of variables in medical device product development to consider is named the Project Trio:
- Scope (the number and type of requirements to be implemented);
- Schedule (the list of all project deadlines, including market-readiness);
- Cost (the proportion of human and financial resources for the project);
To arrive at the planned subset of requirements in the final product, you as the medical device developer can only change two variables of the Project Trio at a time, taking into account that the Trio is a constant. The more you optimise one variable, the less leeway you have left for the other two variables.
Guidelines aid the project manager in controlling the development process to reduce risks and negative impacts of unforeseen developments.
An organised development team usually selects a methodology for product development. The development methodology is the general process for crafting a specific product.
Especially regarding the development of medical device software, firmware or electronics your engineers can choose a strictly regulated methodology such as Waterfall, or a more adaptive system such as Agile. Each method type has its advantages and disadvantages.
The Waterfall Model is a consecutive development process where activities move steadily through pre-defined and documented project phases like water influenced by gravity.
The Waterfall phases of each project step are:
- Development and
The Project Trio in the Waterfall Method is frozen in the initial state after the team has firstly estimated the Scope and Cost, and immediately after that the Schedule – all ahead of project work.
The drawback of this method is if that changes in the ongoing project occur, you must adjust at least one of the variables to achieve the goals.
You have to document the project in advance, with all the features, functionality and interfaces. The documentation’s usefulness depends on how the initial research into the devices features and operational was thorough. With this, you can avoid most project risks and meet requirements by most deadlines, but with a caveat: there must be little change to the requirements and planned activities. Adaptation during product development is costly!
In cases of imperfect technical requirements, in less experienced engineering teams or in projects involving innovative medical devices – for which you have not enough accumulated development experience – other types of development processes are better suited.
The latter should be more readily adaptable during the project, and one popular group are based on Agile methodology.
Agile is an iterative process where self-organising teams collaborate in developing the final product. The method relies not so much on a fully documented roadmap based on priority lists of current requirements called backlogs. Your teams adjust the latter each week, depending on progress and encountered setbacks, so that the order of task importance is rearranged.
In the Agile Method, it is the project manager that sets the initial list of priorities. Ordinarily, this means that you set the Cost and Schedule in stone, and it is only the Scope that you adjust during the basic timeboxes – the “Agile Iterations”.
The Agile Method’s advantages are that you can use it when you cannot sufficiently define the medical device’s initial requirements. On the other hand, this may, in some instances, result in the Scope being so diminished at the end of the project that the product is not market viable.