Steve Maylish, Chief Commercial Officer, Fusion Biotec05.02.22
Outsourcing contract engineering is complicated. It gets more difficult the more the project is undefined or the schedule is accelerated. If the goal is to keep costs low or develop a device on a fixed budget, how does this work best? Alternatively, if the goal is to get it right the first time for both the design and U.S. Food and Drug Administration (FDA) submission, how does one keep from over designing? Will an ISO 13485-certified firm guarantee a good quality outcome? Is there such a thing as too much quality, too soon? How does one keep design efforts on track and not allow it to get out of control? When is the fit between client and outsourcer just right?
Let’s address the undefined project first: At the very least, the outsourced engineering firm should know the type of device they are being asked to develop and have some related experience with the technology. This could be bullet points in an email, marketing requirements, or a product requirements document. The less information provided to the engineering firm, the less accurate the quote.
Many contract engineering firms will help clients through an ideation phase or product requirements definition. If the device is very undefined, start with a firm offering an up-front ideation process or hire them to help with FDA Design Inputs. This will provide more clarity for the estimate and design team. It can also be used to engage another engineering firm, if needed.
If the product envisioned is fairly defined but has high technical risks, a feasibility phase to eliminate those risks may be the best next step. It makes no sense to start a full-fledged design effort before knowing if it’s feasible. A high-risk feasibility effort should be a gating factor if it’s part of the overall project.
Contract engineering firms can help clients through feasibility but the effort can be hard to estimate due to the work’s research nature. On the other hand, the necessary research work might be beyond the design group’s skill set, as in chemistry development.
An engineering firm must know the project’s scope to estimate properly. What information is available today on the project, how far down the road do they go, and when do they stop? As an example: start with a feasibility design, create Design Inputs (following FDA Design Controls), provide industrial design, provide design and development, build a number of prototypes, complete FDA verification and validation, and stop with a technical file (Design History File) for FDA 510(k) submission. However, starting from a working prototype and stopping at a pilot build is a completely different effort. Detailing what must be done and sending the same information to bidders is the only way to make a fair comparison of their estimates.
For instruments, a build of three to five units for agency testing is common. For disposables, a build of 200 devices for sample verification can be common and testing is very different. How many devices are needed for clinical trials should be answered up front. It’s important to remember any prototypes or sample units built in this process must be “essentially equivalent” to the design submitted to the FDA and built under a quality system (ISO 13485 is nice to have, but not absolutely required).
How about an accelerated project schedule? Typically, there are three main concerns in a development project: quality, budget, and speed. As a rule, when concentrating on two, the third will suffer. For medical devices, sacrificing quality is rarely an option and as startups obtain funding, sources will rightfully prioritize time to market. An accelerated design usually results in more costs; larger companies often have the luxury of time.
These costs come from expediting orders and the resulting cost of shipping (almost everything is ordered overnight), paying extra for services, accepting reduced team efficiency for speed, ordering more parts than needed at risk, and working tasks in parallel to find out potential problems as soon as possible. These are just some of the reasons accelerated project costs can get out of control.
One way to rein cost in for an accelerated project is to find a smart engineering firm with relevant experience and pre-developed technology. Keep in mind pre-developed technology may come with inherent tradeoffs between speed and ownership. It’s best to go into a development project with eyes wide open and knowing the technology tradeoffs.
Ask the engineering firm how licensing works on their pre-developed technology. Speed-to-market employing someone else’s technology typically includes a non-exclusive license not transferrable to other products and unable to be sub-licensed. If all of the device’s intellectual property must be owned, engineering firms may sell rights to the client. For pre-developed technology, it's important to know if a license agreement and/or ownership is available and on what terms. This subject should be addressed before starting a project. Keep in mind that contract manufacturers only need software images to download an instrument, not source code.
There are always tradeoffs during design and development—some are obvious and some aren’t so obvious. Some can be completely missed like: “better” being the enemy of “good enough,” unknowingly sacrificing team productivity for “increased” control, or fixing a development estimate when requirements are undefined. Fixing an estimate ignores the fluid nature of design, the discovery process, undefined requirements, and inevitable modifications.
If the main goal is to keep costs low or develop a device on a fixed budget, watch out for some common pitfalls. Hiring a team of independent engineering consultants to save costs on a complex instrument can often result in a disjointed design. Device design should start from the system level, then filter down to individual engineering disciplines. Ground-up approaches with too many disconnected experts often end in technology mismatches, missing or misaligned documentation, a system approach that doesn’t make sense, or a final product that doesn’t meet requirements or doesn’t accommodate future changes. Hiring a professional project manager/system engineer can be incredibly beneficial here.
Fixed-price projects are often a common pitfall. Agreeing on a development price without a strict set of requirements and the ability to change the “fixed” price transfers development risk to the engineering firm. Working together, sharing project responsibilities, and building trust better facilitates a successful project. Fixed-price projects establish conflicting goals from the start. Scope changes become points of contention and these projects often experience death by a thousand cuts. Often, the planned savings don’t materialize. It’s better to set up a not-to-exceed purchase order and reevaluate the project as costs approach the limit.
To better control development costs, manage the project away from alternative design paths (ideas that defocus the team) and keep the team focused on forward progress. To control final product cost, manage project design decisions based on the desired cost of goods. Consider financial incentives for coming under budget.
If an elegant, robust design at a reasonable cost is the main objective, there can be different methodologies depending upon your goals. While research and development are joined at the hip, they are very different disciplines. Research should be completed before development. If there are still some areas of technical risk in the project, these should be addressed first before moving on with the full development project.
Design experience is essential when a new product is being developed. Systems engineering experience provides the basis for a good design. Experience with design for manufacturing (DFM) can smooth the manufacturing transfer process. Experience in designing and submitting medical products for approval provides a better FDA submission package.
In the area of project focus, it’s easy for a design team to get defocused or move toward an exploratory direction for all the right reasons. It takes experienced project managers to lead the team and keep them focused on value-added progress.
An experienced team can circumvent much of the learning curve and avoid pitfalls to keep costs lower. Experienced teams, however, can also over-emphasize quality in the development process. ISO 13485 certification ensures an engineering firm knows how to build a technical file or Design History File for FDA submission. It doesn’t indicate whether they will over-design a device just to be on the safe side. A common pitfall to avoid is quality taking a lead role over good design. This shows up in fear-based decisions, over analysis, or abandoning common sense or pragmatic solutions and efforts to make the design more complicated than necessary.
It's not wrong to play it safe, address every concern, ensure alternative methods are exhausted, fully test subsystems, perform FMEAs and simulations, complete verification and validation, have the client and user validate the product, and the like. It’s wrong to ignore the law of diminishing returns and design a product out of context. Some larger firms can miss this point—there’s a balance to be struck here.
Recently, a contract manufacturing firm during one of our design transfers told us they wanted to spray conductive coating inside the enclosure just to be safe. Another company called concerning service technicians to upgrade software in about 300 of their medical devices. “And by the way, do they have ISO 13485 certification?” I said, do they really need ISO 13485 certification to load a new version of your software?
In summary, there is a bit of a “Goldilocks” predicament. How do you pick the engineering team that is “just right?” Part of the answer is based on the particular requirements. Remember, overengineering can be as detrimental as under engineering. Look for an experienced, pragmatic, and flexible leadership team. Engineering teams should be able to work with ambiguous conditions and be creative, but also have a good working knowledge of requirements and how to follow FDA Design Controls. These traits should not be mutually exclusive. Engineering should be pragmatic; quality management should manage quality, not engineering. Project management should understand system design, quality regulations, and how to lead a successful project.
Steve Maylish is chief commercial officer at Fusion Biotec, a product development company in Orange, Calif., with ISO 13485 certification. He has over 35 years of experience in the medical device industry in such areas as marketing, sales, service, operations, product development, and manufacturing.
Let’s address the undefined project first: At the very least, the outsourced engineering firm should know the type of device they are being asked to develop and have some related experience with the technology. This could be bullet points in an email, marketing requirements, or a product requirements document. The less information provided to the engineering firm, the less accurate the quote.
Many contract engineering firms will help clients through an ideation phase or product requirements definition. If the device is very undefined, start with a firm offering an up-front ideation process or hire them to help with FDA Design Inputs. This will provide more clarity for the estimate and design team. It can also be used to engage another engineering firm, if needed.
If the product envisioned is fairly defined but has high technical risks, a feasibility phase to eliminate those risks may be the best next step. It makes no sense to start a full-fledged design effort before knowing if it’s feasible. A high-risk feasibility effort should be a gating factor if it’s part of the overall project.
Contract engineering firms can help clients through feasibility but the effort can be hard to estimate due to the work’s research nature. On the other hand, the necessary research work might be beyond the design group’s skill set, as in chemistry development.
An engineering firm must know the project’s scope to estimate properly. What information is available today on the project, how far down the road do they go, and when do they stop? As an example: start with a feasibility design, create Design Inputs (following FDA Design Controls), provide industrial design, provide design and development, build a number of prototypes, complete FDA verification and validation, and stop with a technical file (Design History File) for FDA 510(k) submission. However, starting from a working prototype and stopping at a pilot build is a completely different effort. Detailing what must be done and sending the same information to bidders is the only way to make a fair comparison of their estimates.
For instruments, a build of three to five units for agency testing is common. For disposables, a build of 200 devices for sample verification can be common and testing is very different. How many devices are needed for clinical trials should be answered up front. It’s important to remember any prototypes or sample units built in this process must be “essentially equivalent” to the design submitted to the FDA and built under a quality system (ISO 13485 is nice to have, but not absolutely required).
How about an accelerated project schedule? Typically, there are three main concerns in a development project: quality, budget, and speed. As a rule, when concentrating on two, the third will suffer. For medical devices, sacrificing quality is rarely an option and as startups obtain funding, sources will rightfully prioritize time to market. An accelerated design usually results in more costs; larger companies often have the luxury of time.
These costs come from expediting orders and the resulting cost of shipping (almost everything is ordered overnight), paying extra for services, accepting reduced team efficiency for speed, ordering more parts than needed at risk, and working tasks in parallel to find out potential problems as soon as possible. These are just some of the reasons accelerated project costs can get out of control.
One way to rein cost in for an accelerated project is to find a smart engineering firm with relevant experience and pre-developed technology. Keep in mind pre-developed technology may come with inherent tradeoffs between speed and ownership. It’s best to go into a development project with eyes wide open and knowing the technology tradeoffs.
Ask the engineering firm how licensing works on their pre-developed technology. Speed-to-market employing someone else’s technology typically includes a non-exclusive license not transferrable to other products and unable to be sub-licensed. If all of the device’s intellectual property must be owned, engineering firms may sell rights to the client. For pre-developed technology, it's important to know if a license agreement and/or ownership is available and on what terms. This subject should be addressed before starting a project. Keep in mind that contract manufacturers only need software images to download an instrument, not source code.
There are always tradeoffs during design and development—some are obvious and some aren’t so obvious. Some can be completely missed like: “better” being the enemy of “good enough,” unknowingly sacrificing team productivity for “increased” control, or fixing a development estimate when requirements are undefined. Fixing an estimate ignores the fluid nature of design, the discovery process, undefined requirements, and inevitable modifications.
If the main goal is to keep costs low or develop a device on a fixed budget, watch out for some common pitfalls. Hiring a team of independent engineering consultants to save costs on a complex instrument can often result in a disjointed design. Device design should start from the system level, then filter down to individual engineering disciplines. Ground-up approaches with too many disconnected experts often end in technology mismatches, missing or misaligned documentation, a system approach that doesn’t make sense, or a final product that doesn’t meet requirements or doesn’t accommodate future changes. Hiring a professional project manager/system engineer can be incredibly beneficial here.
Fixed-price projects are often a common pitfall. Agreeing on a development price without a strict set of requirements and the ability to change the “fixed” price transfers development risk to the engineering firm. Working together, sharing project responsibilities, and building trust better facilitates a successful project. Fixed-price projects establish conflicting goals from the start. Scope changes become points of contention and these projects often experience death by a thousand cuts. Often, the planned savings don’t materialize. It’s better to set up a not-to-exceed purchase order and reevaluate the project as costs approach the limit.
To better control development costs, manage the project away from alternative design paths (ideas that defocus the team) and keep the team focused on forward progress. To control final product cost, manage project design decisions based on the desired cost of goods. Consider financial incentives for coming under budget.
If an elegant, robust design at a reasonable cost is the main objective, there can be different methodologies depending upon your goals. While research and development are joined at the hip, they are very different disciplines. Research should be completed before development. If there are still some areas of technical risk in the project, these should be addressed first before moving on with the full development project.
Design experience is essential when a new product is being developed. Systems engineering experience provides the basis for a good design. Experience with design for manufacturing (DFM) can smooth the manufacturing transfer process. Experience in designing and submitting medical products for approval provides a better FDA submission package.
In the area of project focus, it’s easy for a design team to get defocused or move toward an exploratory direction for all the right reasons. It takes experienced project managers to lead the team and keep them focused on value-added progress.
An experienced team can circumvent much of the learning curve and avoid pitfalls to keep costs lower. Experienced teams, however, can also over-emphasize quality in the development process. ISO 13485 certification ensures an engineering firm knows how to build a technical file or Design History File for FDA submission. It doesn’t indicate whether they will over-design a device just to be on the safe side. A common pitfall to avoid is quality taking a lead role over good design. This shows up in fear-based decisions, over analysis, or abandoning common sense or pragmatic solutions and efforts to make the design more complicated than necessary.
It's not wrong to play it safe, address every concern, ensure alternative methods are exhausted, fully test subsystems, perform FMEAs and simulations, complete verification and validation, have the client and user validate the product, and the like. It’s wrong to ignore the law of diminishing returns and design a product out of context. Some larger firms can miss this point—there’s a balance to be struck here.
Recently, a contract manufacturing firm during one of our design transfers told us they wanted to spray conductive coating inside the enclosure just to be safe. Another company called concerning service technicians to upgrade software in about 300 of their medical devices. “And by the way, do they have ISO 13485 certification?” I said, do they really need ISO 13485 certification to load a new version of your software?
In summary, there is a bit of a “Goldilocks” predicament. How do you pick the engineering team that is “just right?” Part of the answer is based on the particular requirements. Remember, overengineering can be as detrimental as under engineering. Look for an experienced, pragmatic, and flexible leadership team. Engineering teams should be able to work with ambiguous conditions and be creative, but also have a good working knowledge of requirements and how to follow FDA Design Controls. These traits should not be mutually exclusive. Engineering should be pragmatic; quality management should manage quality, not engineering. Project management should understand system design, quality regulations, and how to lead a successful project.
Steve Maylish is chief commercial officer at Fusion Biotec, a product development company in Orange, Calif., with ISO 13485 certification. He has over 35 years of experience in the medical device industry in such areas as marketing, sales, service, operations, product development, and manufacturing.
