More and more companies are finding that building their trace matrix early, and maintaining that information throughout the development cycle, can greatly improve their development process. Early in the process, the trace matrix improves the collaboration between design and verification resulting in more efficient and effective testing. By incorporating risk and hazard artifacts into the matrix, it also helps the team to better mitigate hazards and prove their risk-based approach to the FDA.
How early in the process do you create your traceability matrix? At the beginning of a project, so you can take advantage of it throughout the development process? Or do you wait until the end, and generate it as an item on your compliance checklist?
In our recently completed 2013 State of Medical Device Development Survey we asked medical device professionals, “What are the top three pieces of information or insights you wish you had better visibility into during the design control phase?” The most common response? Risk controls!
If you look at the responses to another question we asked about how teams are managing their risk artifacts, you won’t be surprised that folks are struggling with visibility into those artifacts. Almost 90% of teams are using documents to manage risk identification, analysis, and mitigation.
Seapine’s recently completed 2013 State of Medical Device Development Survey gathered insight and feedback from more than 400 individuals working in the medical device industry, covering all organizational levels and roles within the medical device field. In addition to general questions about the way folks are developing medical devices, we drilled down into their practices and challenges in three key areas; risk control, design control, and quality control. If you’re interested in how your processes compare to our industry benchmarks, download the full report.
Specific to design control processes, we asked a few questions that are highlighted below along with response data. The first question centered around visibility into project assets. Sadly, survey results indicate most teams don’t have real-time visibility into their data, and must track down and dig through multiple documents to get that information. Not only is this time-consuming, but it often results in incomplete or outdated information being used to make decisions.
Thanks for everyone that participated in the “Beyond FDA Compliance Webinar: 5 Hidden Benefits of Your Traceability Matrix” webinar. The webinar recording is now available if you weren’t able to attend or if you would like to watch it again. Transcript from the webinar Q & A follows.
When you’re contemplating new features for a device or dealing with the need to change existing requirements, the impact on hazards and risk mitigation can often get lost in the shuffle. If adequate traceability is not maintained throughout the design control process, it can be challenging to identify what risks will be impacted if a specific requirement is added or modified.
It seems like a straightforward proposition. We have a business problem, and we start a project to address that problem. Business analysts look at the problem domain, interview users, and come up with a set of project requirements that drive a subsequent application development effort.
But what happens in larger organizations where there are multiple projects going on at the same time? Especially if the various applications work with one another in some way? It’s possible that some requirements in different projects can conflict with one another, even to the extent of one project reversing a feature required by another.
In organizations where rushing software out the door is the standard operating procedure, test managers must develop inventive ways to recruit and retain staff, find time to perform the essentials of testing, and ensure that important defects are addressed.
With all of the hubbub around Yahoo’s announcement to “ban” telecommuting, I thought it might be a good time to highlight some recent customer feedback we’ve gotten on this issue. A new initiative I’ve been leading is engaging with our customers to talk about their corporate strategies and challenges, which we’re feeding into the Seapine roadmap to make sure we’re better aligned with where our customers are heading. Of course, we’re also looking at new and better places to take our customers, that they might not have considered or even knew they would benefit from. P.S. If you want to talk with me and the rest of the corporate strategy team, we’d love to chat for 20 minutes; email me!
At what point in the process of developing a new device does your team start formally managing requirements and risk?
In talking with medical device companies, the most common answer we hear is “we don’t start worrying about that until the product is actually under design control.” That kind of time frame works great for the engineering side of the business, but often leaves marketing and product management in the lurch. The issue is that product management and marketing do the bulk of work on the front-end understanding the market need, defining a concept, and building a business case for the new product, including:
Capturing voice of the customer (VOC) feedback
Determining market/user needs and researching competitive offerings