Main Reasons for Design Control and Risk Management Failures (Part 2)

This is the second part of a series of posts that will address the main reasons design control and risk management failures. 

First, let’s highlight Jon Speer’s article.  In summary his 8 reasons for DC and RM process fails are:

1.       Poorly defined Product Development Process – Jon states that, “A medical device product development process needs to establish the major stages, deliverables, and milestones from project initiation through market launch. Design controls and product risk management should be integrated within that development process.  However, medtech companies commonly err in one direction or another during product development, making the process too detailed and overly burdensome, or too vague (or maybe, not defined at all).” In other words, too detailed and you risk the process being too burdensome or too vague and then the process is not helpful.  The PDP needs to be right sized to the products it serves.  I would add here it needs to work in the culture of your organization, resourcing levels and approaches and with the established QMS.  The output of the design process is an input to your QMS and will need to work with it.

2.       Poor understanding of user needs – Jon states that, “it is common to go full speed ahead once the prototype seems to be sufficient and satisfactory, even though the end user’s needs may not be fully understood.”  In addition, as engineers we are naturally inclined to build something so work steers to prototyping and if anything is documented it will be engineering requirements not user needs.  The natural tendency is to describe the prototype that may or may not achieve what the customer needs.  Customers hire our products to do jobs and enable them to accomplish end states.  It is paramount we first understand what those jobs and end states are before we go solve the problem.  The problem needs definition before it’s solved or we may be solving the wrong problem or one that does not exist.  This is the biggest cause of developed products that do not sell as expected.  The problem was not well understood or defined.  We end up with a technical solution looking for a problem, not a solved problem.

3.       Too Little Time Spent Defining Design Inputs — Jon states that, “Often, there is a rush to get through the design inputs stage so that additional prototypes can be built, tested, etc. I get it. Just about every product development project I have ever worked on had the target completion date defined before the project ever officially began, so getting everything done sometimes seemed to take precedence.”  I agree here FDA state it is not uncommon to spend 30% of your time in the design input stage.  I would add to that the following, getting things done must go hand in hand with doing the right thing.  As mentioned above solving the right problems for our customers is crucial and needs to be front and center at every stage of the development process.

4.       Starting Risk Management Too Late — Jon states that, “Many medical device product developers engage in formal product risk management activities way too late in the process. The right time to start documenting risk management activities is when you are defining user needs and design inputs, so that identified risks can guide those requirements, as well as improve your ability to manage design verification and validation.”  If we are to design out risks and design in safety risk management must start early and continue throughout the entire lifecycle of a device.  Completing risk deliverables as a paper exercise is wasteful and will not help drive inherent safe design.

5.       Poor Design Reviews — Jon states that, “Design reviews are important opportunities, conducted at appropriate stages throughout product development, to assess progress with respect to overall product design and development.  Design reviews should be constructive and introspective, and design control activities should be included and reviewed. Design review attendees should vary, depending on the design review’s focus during a particular development stage.”  I would add here that the design review must absolutely focus on are we meeting user needs, do we have the right requirements and are we appropriately addressing risks through design controls and our product development process at the given stage.  I will also point to the fact that the right resources must be present at the right time to adequately challenge the design in question and deliver a solution that addresses the customer’s problem effectively.

I will address Jon's reasons 6 through 8 and my additional reasons in the upcoming part 3 of the series.  Let me note that the drivers of issues I will add have already reared their ugly head in the first 5 reasons.  But that is a topic for our future post.  In general, you can begin to see how design control, risk management and the quality management system are interconnected and a decision in one impact all others.