What's Wrong With The Medtech R&D Department?

By Larry O. Blankenship, Boulder iQ

Voicing complaints about R&D departments in medical device companies is nothing new. Executives, staff members, and investors commonly ask, “What’s wrong with the R&D department? What’s taking so long? It takes them forever to get anything out!” Frustrated with continual delays, and seeing that R&D often spends most of its time supporting current device product lines, it’s not unusual for companies to look outside their organizations for innovative alternatives.

The reality is that R&D is indeed notoriously behind schedule and over budget, despite the introduction of countless tools and techniques to help organize and run such programs efficiently. In addition, R&D managers are serious, dedicated professionals. They certainly don’t intend to be late or over budget, and they generally are conscientious in estimating the resources they believe they’ll need.

So, what goes wrong? And what can be done? Here’s an overview of five common culprits in delaying or derailing device development in the R&D stage — and a solution that just may be R&D’s salvation.

1. (Dis)Similarity

Project management tools and approaches calculate the expected time and resources needed to implement a project, but they’re only as good as the data entered into them. That data often comes from comparing the current project to previous projects that appear to be similar. The problem is that the projects may not always be as similar as one assumes, and the comparative data may or may not fit accurately.

For example, a recent catheter project was to incorporate a novel profile-changing tip. The R&D team had developed many catheters before and saw this as a “similar” project. In design, though, they found that the techniques they had used for previous catheters would not work for this tip. Instead, they needed special tooling and techniques. The result: the project went over budget by 40%. If time had been designated early on to investigate and research the needs in more depth, the R&D team could have developed a realistic assessment of what was and was not “similar” and kept the project more on time and on budget.

2. No Recognition of Research Tasks

“Engineering tasks” are those that can be successfully implemented in a straightforward, predictable manner using methods known and previously applied. “Research tasks” are those that a company does not know exactly how to do at the moment and needs to figure out. Inability to recognize the difference, and thereby not accounting for the necessity of research tasks in planning and budgeting, will severely derail R&D plans.

One real-life example of an important hidden research project comes from the intravenous pump industry. Looking at an existing a standard device that used a 5 ml reciprocating syringe, a competitor decided to leapfrog the market by making a 0.5 ml pump. Their idea was that the patient could wear the device, versus having to deal with the device clamping onto an IV pole. It may have been a great idea, but to be competitive, the developer still had to demonstrate 2% accuracy and offer similar disposable pricing. In reducing the size by a factor of 10, though, the manufacturing tolerances on the syringe could no longer be met with standard molding approaches. The resulting cost increase took the device to the point where it was no longer competitive.

3. Feature Creep

Fundamental to projecting a development timeline and budget is a solid understanding of what the product is, what it does, and how it’s used. Early in the project, a product requirements document should detail all features that define these elements. Once development is underway, making any changes to that document — in effect, adding functions, or “features” — can be devastating to a planned timeline and budget.

For example, marketing may ask to add “just one more control knob on the front panel.” Once the control panel has been laid out, the circuit boards printed and parts received, this seemingly simple addition can be highly disruptive to the device development.

The point at which a feature change request is made is critical to its impact. Consider a request to add an inline injection port to a tubing set. If the tubing set has already completed eight weeks of biocompatibility testing, adding the injection port may require a complete re-test, which could mean another two months — or more — to the project timeline. Obtaining enough input up front to establish solid, unchanging product requirements and avoiding feature creep later in the program is essential to project predictability.

4. Time Distractions

Protecting project resources is an important task for an engineering manager. This includes establishing policies to keep the R&D team focused on the new product’s development, versus risking them being pulled away to deal with current devices issues. Importantly, it also means working with executive management to communicate the impact of such a diversion of resources.

To make this type of system work, some organizations have implemented a special engineering group, “manufacturing and sustaining engineering,” to address issues with devices already in production. This allows the R&D team to focus on new devices without diversion.

5. Corporate Culture

How management deals with issues and delays in R&D sets the tone for how well the department can address issues, now and in the future. It’s not uncommon for corporate executives to fire R&D managers out of frustration at delays. Those replacing them will ultimately face the same situation down the line unless the approach changes.

And, in a culture where R&D personnel fear for their jobs, they may start to inflate estimates of time and costs of project tasks to cover themselves. When such culture exists, the distrust is damaging to all parties involved.

The keys to success are to promote in-depth advanced thinking that addresses the problems described here, to work with the R&D team to plan with adequate forethought and discovery, and to execute with an eye toward predicting potential challenges and advanced preparation.

Phase 0 Solution

“Solution” may be an overused buzzword. But in this scenario, the good news is that there really is a solution to the R&D problems described. It’s called Phase 0.

Simply, put, Phase 0 is a phase that comes before the typical five product development phases most medical device companies use. Those five defined phases align with the required design controls of the FDA’s Quality System Regulation.

• Phase 1: User Needs
• Phase 2: Design Input
• Phase 3: Design Process
• Phase 4: Design Output
• Phase 5: Verification and Validation

Generally, each of these phases must be completed, then accepted by quality assurance, before the next phase begins, thus creating a “gate” of review and approval between each phase. While this phase-gate approach is easily auditable to show compliance with the Quality System Regulation, it is also inherently inefficient from a project flow perspective.

For example, the IFU is typically part of Phase 3 or 4, which take place when the design is largely complete. If a problem in the user interface comes up, it may require modifications to Phase 1 and Phase 2, which means going backward, not forward. Or, consider Phase 5, where verification and validation test protocols are written. The design team may not have been aware of the rigors of the testing or required test points, forcing some level of redesign.

Enter Phase 0. It involves preparatory work to determine if a device development project can even gain authorization. In fact, a main purpose of Phase 0 is to cancel development projects before they get off the ground.

Killing a project can be one of the toughest jobs for R&D managers (and company leadership). Beyond the fact that projects and devices can become so personal, no one wants to cancel a project after years of development and investment of millions of dollars. Phase 0, executed objectively, in line with sound business decisions, can eliminate emotional and subjective attachments to projects. The bottom line is that it’s much easier and cheaper to cancel a project after Phase 0, before it really gets started.

A Phase 0 document clearly states that the work is preliminary investigation and research that may or may not be used as the basis for initiating a formal device development project. It therefore is not subject to FDA design controls.

Phase 0 is not trivial — or short. It typically takes several months. Yet we have seen, over and over again, for more than a decade of implementing Phase 0 with clients, that it is a wise investment. Phase 0 activities are designed to uncover the unknowns, take question marks out of equations, and eliminate the age-old adage plaguing medical device companies: “We didn’t plan to fail, we failed to plan.”

Phase 0 Tasks

Since Phase 0 is not subject to design controls, a company can define the activities and deliverables in a way that best serves its needs and device attributes. Many device firms work with a product development consulting firm that has hard and fast experience in the implementation of Phase 0. Whether you go this route or do it yourself, tasks usually begin with concentrated focus on defining the users, their attributes and training, and their needs in function, environment, and process. Well-organized brainstorming sessions, which include knowledgeable people outside the primary device development team, bring in objective ideas and perspectives.

From there, the R&D team can perform an initial written feasibility assessment of the top concepts, with a list of likely engineering and research tasks. Moving forward with the top two or three concepts, the team can update the device requirements document, and, for each concept, create sketches/illustrations and generate an IFU and a perceived workflow diagram.

A prime concept will emerge from user input (following ISO 62366 Usability Engineering for a Formative Usability Study). R&D can take that concept to a demonstration level, create the IFU and workflow diagram for it, and finalize based on additional user feedback.

From there, it’s back to the engineering and research task list for updates and appropriate inclusion in the project plan. With the Phase 0 results, the plan — in whatever form it takes — should have buy-in from the R&D team and other corporate decision-makers. And if the project does move forward, good documentation of all Phase 0 investigations, research, tests, and activities will greatly streamline the formal design control project phases.

Identify What You Need To Know

The answer to “What’s wrong with the R&D department” is a complex one, and certainly one that goes much further than R&D. Predicting, anticipating, and preparing the design, with incorporation of user needs as early as possible, can go a long way toward making R&D as productive as possible. Introduction of a Phase 0 will help identify what you don’t know but need to know. In the long run, it will save the company – and the R&D department – time and money in the introduction of new devices that predictably meet customer needs.

About The Author:

Larry Blankenship is a director of Boulder iQ and has more than 30 years of experience in medical device product development, manufacturing, regulatory affairs, strategic management, and funding. He has helped multiple start-up companies in the industry get products to market, working in management positions in divisions of Eli Lilly, Pfizer, and the Battelle Memorial Institute. Blankenship is a member of the advisory board at Colorado State University’s School of Biomedical Engineering and of the Constituency Committee at the University of Colorado Denver Department of Bioengineering. He serves as a healthcare industry advisor to Blackstone Entrepreneur Network of Colorado and is a former director of the Colorado BioScience Association. He can be reached at larry.blankenship@boulderiq.com or on LinkedIn.