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\u2019t intend to be late or over budget, and they generally are conscientious in estimating the resources they believe they\u2019ll need.<\/p>\n\n\n\n
So, what goes wrong? And what can be done? Here\u2019s an overview of five common culprits in delaying or derailing device development in the R&D stage \u2014 and a solution that just may be R&D\u2019s salvation.<\/p>\n\n\n\n
1. (Dis)Similarity<\/h2>\n\n\n\n
Project management tools and approaches calculate the expected time and resources needed to implement a project, but they\u2019re 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.<\/p>\n\n\n\n
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 \u201csimilar\u201d 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 \u201csimilar\u201d and kept the project more on time and on budget.<\/p>\n\n\n\n
2. No Recognition of Research Tasks<\/h2>\n\n\n\n
\u201cEngineering tasks\u201d are those that can be successfully implemented in a straightforward, predictable manner using methods known and previously applied. \u201cResearch tasks\u201d 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
3. Feature Creep<\/h2>\n\n\n\n
Fundamental to projecting a development timeline and budget is a solid understanding of what the product is, what it does, and how it\u2019s 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 \u2014 in effect, adding functions, or \u201cfeatures\u201d \u2014 can be devastating to a planned timeline and budget.<\/p>\n\n\n\n
For example, marketing may ask to add \u201cjust one more control knob on the front panel.\u201d 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.<\/p>\n\n\n\n
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 \u2014 or more \u2014 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.<\/p>\n\n\n\n
4. Time Distractions<\/h2>\n\n\n\n
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\u2019s 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.<\/p>\n\n\n\n
To make this type of system work, some organizations have implemented a special engineering group, \u201cmanufacturing and sustaining engineering,\u201d to address issues with devices already in production. This allows the R&D team to focus on new devices without diversion.<\/p>\n\n\n\n
5. Corporate Culture<\/h2>\n\n\n\n
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\u2019s 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Phase 0 Solution<\/h2>\n\n\n\n
\u201cSolution\u201d 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\u2019s called Phase 0.<\/p>\n\n\n\n
Simply, put, Phase 0 is a phase that comes before<\/em> the typical five product development phases most medical device companies use. Those five defined phases align with the required design controls of the FDA\u2019s Quality System Regulation.<\/p>\n\n\n\n Generally, each of these phases must be completed, then accepted by quality assurance, before the next phase begins, thus creating a \u201cgate\u201d 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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\u2019s much easier and cheaper to cancel a project after Phase 0, before it really gets started.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Phase 0 is not trivial \u2014 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: \u201cWe didn\u2019t plan to fail, we failed to plan.\u201d<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n From there, it\u2019s back to the engineering and research task list for updates and appropriate inclusion in the project plan. With the Phase 0 results, the plan \u2014 in whatever form it takes \u2014 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.\u201d<\/p>\n\n\n\n Please find the complete article here<\/strong><\/a>.<\/p>\n\n\n\n For further information please get in touch with us:<\/p>\n\n\n\n\n
Phase 0 Tasks<\/h2>\n\n\n\n
<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.medsyscon.com\/wp-content\/uploads\/2020\/02\/Logo_MedSysCon_Medizintechnik_4C-1024x254.jpg\"){kind=logo}
<\/figure>\n","protected":false},"excerpt":{"rendered":"