Managing your medical device product development project can be a daunting task. There are regulations and paperwork to manage, along with expectations such as deadlines or goals for getting the device to market.

I sat down recently to chat with Peter Sebelius about our thoughts on project management best practices for medical device product development. Sebelius is the founder of Gantus.com, where he helps medical device companies with quality assurance, risk management and project management. He is a certified project manager and member of joint working groups on ISO 13485 and ISO 14971. He has vast industry experience and extensive knowledge of medical device standards.

Here are some of the common traps that Sebelius has often found medical device companies falling into:

Thinking that regulation prevents lean development

There often seems to be a perceived conflict between using lean or agile development methodology and complying with FDA and ISO regulations.

The answer from Sebelius is that you definitely can operate this way, but many companies are struggling with it.

Companies have a perception that they need to have as many documents as possible, and this simply isn’t true. They have challenges with the “monster” that they consider the (FDA 21 CFR 820 and ISO 13485) regulations to be.

In my years in the industry, I’ve witnessed a number of changes. Back when I first started, design controls were new and it quickly became apparent that development was far from a “straight line” process, which the waterfall diagram might imply. The question is always, “What can I take from start to finish as quickly as possible, especially when I’ve been given deadlines already?”

You obviously have to work with the regulations, and there are some good tips for doing so.

Thinking that you need controls from the get-go

Sebelius has a stance that may appear controversial to some: Don’t have controls – at least not at first.

One mistake that companies make is to try to apply all design control principles too early. They’re trying to set up the project along with all specifications and have them approved without really knowing what the product is going to be like.

A more logical way is to understand and be able to use feasibility studies that are not under design controls first. It’s a more appropriate way of organizing work so that you’re not adding confusion early on. Be clear about the purpose of design controls. It’s not the intention to finish the product in two weeks but to produce a device that is safe and effective. You can develop that “gut feeling” about when to turn on design controls, working on a “not too early and not too late” basis.

When should you “turn on” those design controls? People have an image of design controls as being restrictive, perhaps suggesting you can’t be innovative and creative. The design controls should be a framework, used as a tool to help capture the essence of the device and prove that it is safe and effective. We suggest that you begin design controls when you formalize your project and have the first real, effective version of your device.

Not using the design control documents effectively

Sebelius points out that another reason design controls are a challenging area is that people are worried about not having everything defined. It’s OK to use “TBDs” and update as you go along. Otherwise, what happens is that you’re always waiting for more details, which you probably won’t have until you’ve got a final version. It’s a good “placeholder” to remind you to go back and define it as you evolve your design, too.

Another common mistake made by medical device companies is doing all the work but not documenting it until they have a “perfect” product. This is really just using design controls as a checkbox activity without getting real value. The right way to look at all those documents is that they have positive impact. They force you to think through things well, which is a good way to avoid running into problems. People sometimes wait to sign all the documents, especially if their approval system is difficult. If you have an aversion to putting your signature to the document, this is usually a symptom that your document control procedures are bad. It’s not intended to be difficult if something needs changing.

Separating design controls and project management

What’s the difference between design controls and project management? Design controls don’t require you to consider financial aspects. Design controls are best practices on how to run product development. At least 90% are things that make perfect sense for product development projects. (We admit, there are some things that will have you scratching your head).

Design controls and product development really don’t need to be kept separate (which is a popular opinion). All of the elements in design controls you’ll find in project management – albeit maybe with slightly different names. You can make a reference to budget in your design and development plan to make it transparent, although auditors may not ask to see it.

Not knowing enough about quality management and regulatory affairs

Know the rules so that you know how to work within them and try to avoid push-back from regulatory or quality management. This is a valuable competence so you know what’s “good enough.”

Confusing product development with engineering

We see a couple of common misconceptions at companies. “Because you’re a good engineer, you’ll make a great project manager.” Secondly, “Product development is an engineering issue, not an enterprise-wide issue.”

There’s a saying that we’ve heard repeated a number of times: “The more complex the project, the less you need an engineer to manage it.” Sometimes the engineering skillset doesn’t lend itself well to product development/project management. You need someone who is good at the project management part (who may or may not be an engineer).

Requiring too many signatures

Get the document controls right. A common mistake is to have far too many signatures on documents. This is a control entirely chosen by the company. Information needs to be available to management, but you should determine exactly who is necessary to review and approve. How long does it take to get those eight different signatures? How many actually read and reviewed the document? Having one person with final responsibility helps to get a good decision and ensure that documents have actually been read thoroughly.

Final thoughts

In summary, don’t get bogged down too early by design controls or onerous approval requirements but know the right moment to “switch on” your design controls. Use the regulations and controls as a useful framework for checking your device, and start documenting early. If you’re treating design controls as a checkbox requirement, you’re missing the point and their potential usefulness.