This blog series is jointly based on the expertise of Randy Armstrong, Chief Technology Officer at Velentium, and Jama Software’s experience working with developers of Class II and III medical devices. To download our joint whitepaper on this subject, click here.
Yes, a cultural shift to an eagerness for reviews is imperative to success. But even if everyone is on board, a methodical approach is needed to execute the process.
Use the following six “right” attributes as a framework for planning and implementing a successful Design Review process.
1. The Right Time
The purpose of the review process is, as mentioned, to identify defects. And it’s important to find the right time in the development process to conduct the reviews.
Review too early and it’s wasting time because there are too many missing elements that will still have to be reviewed later.
Review too late and it’s likely things will be missed or teams will end up reworking defects that should have been caught sooner.
2. The Right Scope
If too many things are being reviewed at once, it’s possible that the reviewer won’t be able to give attention to each item at the right level of detail. If the items are low risk, this might be sufficient. However, high-risk deliverables require undivided attention to find a blind spot.
The project manager or systems engineer should distinguish low- and high-risk items prior to reviews, and plan resources accordingly.
3. The Right Participants
One of the biggest challenges of reviews is getting the right reviewer for the job.
A reviewer must be independent of the project, yet qualified for the materials they are reviewing.
By being an outside observer, they are not simply motivated to “rubber stamp” the material just to keep things moving. Likewise, an unqualified person would not know enough about the material to read between the lines and uncover blind spots.
It’s also important to remember that both sides of the equation benefit from the review process. Presenters get their material reviewed, which is of course their goal. But the process is also valuable for the reviewer. It’s an opportunity for cross-pollination of knowledge and experience. The teams can mentor one another and have the favor returned in future projects.
4. The Right Criteria
A review is not the time for opinions.
They are not conducted according to whether the reviewer likes or dislikes the style of a product or its development. Specific criteria must be laid out so the review is conducted based on the objectives of the material.
It’s the job of the systems engineer or product manager to call out in the project plan any specific criteria that must be met for that set of deliverables. And it’s important not to go overboard – the criteria should be the minimum set of things the reviewer needs to look for.
If there are no specific criteria outlined, a generic list of acceptance criteria should be followed:
• Is it complete?
• Is it necessary?
• Is it feasible?
• Is it consistent?
• Is it detailed?
• Is it verifiable?
• Is it traceable?
5. The Right Records
Missing review documentation could have serious ramifications. If a lawsuit is brought up against the company, there is no proof to dispute claims.
Furthermore, it can be damaging from a compliance perspective. A Federal Drug Administration (FDA) audit could result in a warning letter stating that design controls aren’t being followed. This can shut an operation down, delaying approval, shipping, or selling of a device.
Documentation not only proves a review took place, it’s an efficient way to have the list of what was found and corrected. This provides a great deal of understanding about how designs evolved.
Reviews can also be the genesis of future product enhancements. An idea may come up that isn’t right for the current generation but can be logged in a recommended improvements database.
“If a review is not recorded, it may as well never have happened.”
Randy Armstrong, Chief Technology Officer, Velentium
6. The Right Collaborative Infrastructure
Developing medical devices requires open lines of communication. Having the right development technology in place allows teams to make sure the right participants are included at the right time, and that they have the right level of information, thus reducing the number of late-stage changes and delays.
Having built-in traceability within a development solution also gives a clear view of where the review deliverables fit into the overall project. This shows what materials are high-risk versus low-risk so the scope can be adjusted accordingly.
When specific acceptance criteria can be noted in the system along with the materials, the reviewer understands exactly what to review against. And no extraneous documents means no version control issues.
Additionally, when all reviews are recorded within a centralized system and you have the ability to easily export as needed, fewer questions arise when it comes time for audits and regulatory approvals. The right collaborative technology eliminates many burdens of the review process and instills a positive culture of reviews.
In our next and final post of the series, we’ll share two important tips: one for driving a review-positive attitude throughout your organization, and the other for equipping it to conduct reviews effectively and efficiently.
