Often in medical device product development, functions exist in silos. Risk, requirements, and test management functions often exist separately, on their own - different systems, different teams, different objectives. Yet, the data related to these functions are both continuously changing and highly dependent on one another. Some type of process is needed to (1) manage the effect of changes across all three systems and (2) provide evidence of a process for notified bodies if and when needed.
Siloed functions and manual processes can work for small teams working on small projects, where there is minimal data and limited people with access. For medium to large, more complex development projects, this can become very challenging and can compromise quality. With large amounts of data and a multitude of dependencies, there is a high potential for error, and the cost of quality is real. According to a McKinsey study, Capturing the value of good quality in medical devices, direct costs of poor quality average between 5 and 7 percent of revenue with indirect costs reaching $1 - $3B for a medium to large device company.
With such a high potential impact, let us make the case for process. As we have worked closely with customers, our thinking (and our technology) have evolved to embrace it.
The problem with little or no process.
If I am working in test management, I can communicate the result of a test with my colleagues in risk and requirements management in many ways - I can email them, present the data in a regular team meeting, post an update in our PM/collaboration tool, etc. What happens with that data is then out of my hands. Without a process, we cannot be sure the changes and effects have been taken into account.
An example was recently recalled of how a component was in the process of being released for production, when it was discovered that a critical requirement ‘shall have no sharp edges’ was not documented in the release criteria. This design input, one that would prevent harm to patients, was not properly considered in risk, inspection testing, or manufacturing records. This error began very early in the process and, because there were no checks and balances or trace matrix from inputs to outputs, it was never identified as missing.
Without process there is no checkpoint or accommodation for important cause and effect relationships. Consequently, when a change is made in one place, there is no guarantee that it will be made in every place that is needed across all functions - nor that the effect of the change has been considered. Starting with the first even very slight inconsistency in data, the mistakes begin to snowball creating false data and assumptions that can ultimately lead development down the wrong path. The effort of backtracking to find the origin of the mistake and fixing it can be monumental.
Process: the quality enforcer.
Process supported by an automated workflow ensures that every change and its effects are considered, analyzed, and acknowledged - and that every action is traceable. Simply put, process enforces quality by ensuring that data is clean and auditable. It also guides compliant product development by providing the step-by-step framework for supporting the appropriate industry standards and regulations like ISO 14971, 21CFR820.30, and ISO 13485.
Continuing with the above example for the ‘shall have no sharp edges’ design input, a trace matrix could have changed the experience dramatically. It would have identified early in the process the missing considerations for inspection, evaluation or risk, and process specifications. The activities used to create a trace matrix are ultimately designed to ensure that the steps in a process are followed to ensure that outputs meet inputs. Therefore (1) when changes are made in one place their effects are considered across all design control functions and (2) every action is accounted for and auditable. The project simply would not have been able to move forward without regulatory-compliant consideration of the ‘shall have no sharp edges’ design input and required risk analysis and testing.
Overcoming the “silo” mentality.
About a year ago, we were working with a client on setting up our system for the development of their new product. The company’s offerings are modular, with many components that are re-used in the different design variations. We suggested changing their (spreadsheet-based) process to a databased one, so that existing component data could be used for new products - rather than repeating risk analysis and tests each time.
The suggestion was met with skepticism. “Process changes and new processes slow us down,” was the reason. We explained that an old process in combination with a new way of work will not be very efficient - and that this inefficiency will be more of an obstacle than a support . A light switch flipped on! Rather than forcing a new way of work into an old process , they now see process improvements as a way to improve efficiency and quality, and avoid time to market delays.
Setting the right processes and consistently evaluating them in light of changing standards, regulations, and changing product development environments is critical - it is a commitment and a never ending story. But consequently, your quality and accuracy, your proof of process for notified bodies, and your efficiencies will improve dramatically.
Start small, win big.
Are you ready to start improving your product development with processes? Ready to increase accuracy, accountability, and traceability? Our suggestion is to start small. Identify a few really good processes and prove them out - show their value and convince skeptics.
If it works, think about making the commitment. Tools like our Compass SaaS solution can help by providing templated, pre-programmed workflows and unique features like trace matrices that are created with step-by-step guidance and automatically updated.
