A peek into my Design Controls philosophy

Defining when Design Controls begin is up to you.

Okay, to a point.

Let me state this another way. You get to establish your company procedures for Design Controls, including what the “trigger” is to move you out of research (or feasibility or whatever you call pre-development) and into official product development.

Design Controls Philosophy

To illustrate part of what has formed my personal Design Controls philosophy, I need to go back in time about 12 years.

I had the title of Design Control Engineer for Cook Medical. When put into this role, I was given two broad objectives.

  1. Improve the consistency and practices for product development and Design Controls at Cook, Inc. (the flagship company).
  2. Establish a consistent framework for product development and Design Controls across Cook Medical (consisting of 11 companies spread over 4 states and 3 continents).

We made significant progress regarding the first objective very quickly. We had a team of product development engineers and technicians who were generally speaking very good about getting new products to the market.

And at that time, the company had a way. To put it in perspective, I was often challenged to establish a Design Controls process that kept official documentation compliant and minimal.

No, this is not a contradiction per se. Although, when some hear “minimal” with respect to regulations, some hear “missing”.

You can adopt a bare minimum approach to documenting Design Controls and DEFINITELY meet the intent of the regulations.

I learned a great deal in this role. Always challenging. Always challenged.

It was while tackling the second objective when my personal philosophy and approach to Design Controls really started to take shape.

The classic “research” versus “development” debate

Imagine having 15 people from almost as many companies which operated autonomously with respect to medical device product development quarantined in a room over the course of two days.

Imagine what it would be like to try and get everyone on the same page, agreeing to the same steps in the process, and having the same deliverables at the end of those two days.

Naively, going into this actual scenario at that time, I was optimistic — believing we would achieve just that.

Not surprising, this group of 15 people did not leave that room after two days with a common philosophy and approach to Design Controls and product development. As a group, we did make some significant progress towards getting on the same page.

And for me, those two days might have been the most influential on my entire approach to medical device product development.

We spent most of those couple days discussing and debating the premise of “research” versus “development”. (Note that some refer to research as “feasibility”, among other things.)

Research vs Development - a common debate

Research vs Development – a common debate

The debate centered around this line of thinking:

A project which is still in research is outside the purview of FDA. And therefore, we should keep a project in research for as long as possible. Because once we cross that line into development, then we must be diligent about documenting Design Controls.

It was fascinating to hear this largely because it blew my mind regarding Design Controls.


I mean how can you do “stuff”, call it research until you have high confidence and then flip the switch enter into development?

Yet the more I thought about it, the more the thought process made sense.

Design Controls Waterfall is wrong

Keep in mind that up until this point in time, I saw the Design Controls waterfall diagram as critically important and accurate.

Design Controls waterfall

Design Controls waterfall

This discussion around research and development, though, began to change my view.

I started to question the waterfall.

Okay, don’t mishear me. User Needs, Design Inputs, Design Outputs, Design Verification, Design Validation, and Design Reviews are DEFINITELY correct and necessary.

But maybe the fact that these things happen linearly was far from fact.

Maybe those adamant about staying in research for as long as possible were onto something.

A new way of thinking about it

Consider this:

Medical device product development is far from a linear process.

Actually, medical device product development is probably much better described using a Boehm spiral model (or any number of non-linear models).

Boehm spirla model to describe product development

Boehm spiral model to describe product development

This means establishing Design Controls may also happen in a non-linear way too.

This means that there might be some scientific validity to the classic research versus development debate.

Bottom line

You have to have a system and process in place that is rigid at times and flexible at other times.

Sounds like a total contradiction, I know.

Here’s what I mean.

Design Controls does require some hierarchy.

Design Verification can’t happen until you define Design Outputs and Design Inputs.

Design Validation can’t happen until you define User Needs.

Ensure your practices can accommodate for the hierarchy while giving your product development team some levels of freedom.


Jon Speer has been in the medical device industry for over 16 years. In 2007, Jon started Creo Quality to help medical device companies with project management, quality systems, and regulatory submissions. As a result of his experience in the medical device industry, Jon had an idea to develop a software solution to improve how companies handle Design Controls. Because of this greenlight.guru was born. You can find him on Google+Twitter, and LinkedIn


Related Posts

No Comments Yet.

add new comment