Avoiding the 7 Deadly Sins of Medical Device DevelopmentAvoiding the 7 Deadly Sins of Medical Device Development
Trivia Tuesday: Do you know the seven deadly sins of medical device development and how to avoid them?
January 28, 2025

Way back in 2001, MD+DI published an article detailing what the author considered to be The Seven Deadly Sins of Medical Device Development. The author reviewed dozens of device development programs to reveal seven types of problems that often contribute to project failure. Despite the article being nearly 24 years old, these "deadly sins" still hold true for medical device developers today.
Launching a project too soon
Inadequate project leadership
Underestimating lead times
Trying to do everything in parallel
Saving the hardest tasks for last
Changing requirements
Giving engineers free reign (and cleaning up afterward)
The article cites several simple guidelines for avoiding most medical device development pitfalls:
Select an experienced project leader and empower them to succeed.
Create a culture where tough questions are encouraged.
Tackle the most difficult tasks first. Flesh out any technological, marketing, or manufacturing risks.
Develop a stable set of specifications before beginning formal design efforts.
Develop a project plan with realistic lead times and resource requirements.
Build design control tasks into the project plan.
Involve manufacturing and quality assurance in the project from the start.
Now, let's dig into these pitfalls and solutions a bit further.
Launching a project too soon
Projects launched before the proposed product has been rigorously analyzed and evaluated begin their lives on a weak foundation. As a result, resources and time can be lost when an insurmountable obstacle appears later on in the process. The original article also lists the most common flaws that medical device companies frequently overlook at the beginning of a project.
Poorly defined specifications
Insurmountable technical hurdles
Intellectual property problems
Unacceptable manufacturing costs.
Poor financial return
Inadequate project leadership
Following a flawed decision-making process. Most medical device development projects consist of a series of investigations, analyses, and decisions. Critical to the success of a project is a decision-making process that is defined at the start and remains consistent throughout the life of the project. Without a consistent and well-defined decision-making process, decisions tend to be made, reversed, and reversed again later in the project, often without any new information as justification. The most successful projects encourage a team-oriented decision-making process but provide for a single, strong leader as the ultimate decision-maker. As an additional preventative measure, each decision should be documented in the design history file—along with a brief rationale—so that if the issue comes up again, it can be quickly and definitively addressed.
Making frequent managerial changes. Few things can undermine a program more profoundly than an ineffective manager. Proper mechanisms should be in place within a company to permit such a problem to be quickly recognized and remedied. Too often, however, companies overreact to poor leadership by changing managers too readily. When afflicted by this unfortunate manager-of-the-month syndrome, projects suffer from the inefficiencies of redefining development strategies and shuffling priorities and resources. As a result, project team members become disenchanted, and productivity suffers.
Lacking the authority to get the job done. While charisma and strength of personality play significant roles in a manager's success, they must also possess the authority to request and elicit cooperation from each product development team member and to quickly marshal other in-house and outside resources as needs arise. Furthermore, an authoritative manager must be free to wield influence and break rules (within reason) in order to complete tasks on time. Such authority can only come from upper-level management, such as a CEO or vice president of R&D, and should be visibly granted at the project's inception and reinforced throughout its duration.
Underestimating lead times
It may seem obvious, but the single most devastating mistake made in a time-critical medical device development program is to underestimate necessary lead times. Here are five examples of areas where lead-time estimation errors can occur:
Lead times for ordinary parts
Custom part fabrication
Safety and EMC testing
Product validation
Product transfer (misjudging the amount of time and effort needed to transfer a product from R&D to manufacturing, for example)
Trying to do everything in parallel
In an effort to accelerate development programs, medical device companies have learned to devise project plans with multiple parallel pathways. This type of planning can get out of hand, however, when the plans encompass everything from basic research and animal testing to software validation and fixture design. Parallel planning is attractive on paper, but it often falls short of expectations in practice. The following problems present challenges to parallel planning efforts:
Resource overloading
Unmanageable interdependencies
Premature regulatory and patent filings
Saving the hardest tasks for last
Often, medical device companies find themselves under significant pressure to show progress in a development project soon after it is launched. Because of this pressure, they sometimes put off dealing with the most difficult or riskiest engineering challenges until much later in the project. For example:
The trade show effect. Major trade shows and scientific conferences are prime venues for new product introductions, but their timing can sometimes lead to undue haste. Because marketing departments are often anxious to generate customer enthusiasm for a new product at such events, they may feel tempted to launch the product prematurely. In one case, a company developed a novel ambulatory pH-monitoring system and chose to launch it at a major conference in the fall, though quite a few significant design problems remained unsolved. To meet a pending trade show deadline, the engineering team stopped working on the more critical problems associated with the product to focus exclusively on making working models for the show. While the models were compelling enough to elicit purchasing interest from early adopters, the company needed an additional six months to work through the tough problems it had sidestepped. Consequently, interest in the product waned, and the company's relaunch at the next major conference the following spring was relatively lackluster.
Management by milestones (such as milestone-based funding from investors). These schemes are intended to align the interests of investors with those of entrepreneurs by granting incremental funds as certain predetermined milestones are met. Commonly cited milestones include "working prototype complete," "patent application filed," and "successful animal trials performed." Unfortunately, these circumstances can tempt a company to focus entirely on achieving its milestones to qualify for each round of financing, thereby putting off the most difficult technical challenges for last. Take, for example, the startup firm that was developing a novel eyeglass lens manufacturing process. The company raised more than $6 million by completing milestones set by its investor group. These milestones included the development of engineering prototypes, the completion of a marketing plan, the establishment of an advisory board, the hiring of a sales force, and the construction of a manufacturing facility. Unfortunately, when the product went through its final validation, the underlying process was deemed inadequate to support the required accuracy and cost targets. In the end, the company folded.
Design first; ask questions later. It is typical for early-stage companies to function in constant money-raising mode, with potential investors parading through their facilities to inspect the technology at any given time. In this type of atmosphere, it's unpopular for company insiders to raise any questions about the viability or marketability of the product or technology, for fear of scaring off investors. At the same time, however, project teams need to show significant continued progress, such as the development of working models or preclinical prototypes. As a result, the development effort may appear to progress smoothly on the surface while, underneath, there may be a growing unspoken anxiety about the underlying technology. Unless a major breakthrough occurs, product development stalls when the shortcomings of the technology surface and investor expectations clash with reality.
Changing requirements
According to our original 2001 article, it is crucial to the success of a project and to all involved to carefully develop a set of viable product requirements, and then to adhere to them as closely as possible throughout the project. Unfortunately, doing so isn't always practical, especially when projects are planned with many interdependent tasks happening at the same time. Some of the most common factors that lead to changes in requirements include the following:
Changes in basic science. Whenever basic science tasks are planned in parallel with development tasks, the potential for crisis is likely. Take, for example, a company that developed an iontophoretic, transdermal drug-delivery system. A preliminary analysis revealed the desired drug-transfer rate was possible based on certain assumptions about ionic current flow. In conjunction with experiments to confirm the drug-transfer rate, engineering efforts to design the control electronics and electrodes were set in motion. To the disappointment of those involved, the drug experiments revealed that the desired rate of transfer could only be achieved with costly changes in the carrier solution and the drive electronics. Consequently, the product requirements were significantly revised and most of the initial engineering efforts had to be scrapped.
Unexpected preclinical test results. When medical devices are at last put to use on animal subjects or patients, test results are often disappointing or otherwise surprising. Inevitably, if the project survives in spite of such results, product requirements must be modified. Unless preclinical testing is performed before significant engineering has taken place, changing the requirements at this stage can have wide-ranging consequences.
New market information. As a product development project nears completion, control of the project often shifts from engineering to marketing. When this shift occurs, marketing personnel begin bringing models and prototypes into clinical environments for simulated-use evaluation. During this process of disclosure and evaluation, new customer preferences, logistical constraints, and competitive activities may be discovered. These types of market revelations can seriously impact product requirements and can frustrate members of the technical staff, who may rightfully question why such issues weren't uncovered at the beginning of the program. Therefore, early and intimate collaboration between engineers, marketing executives, and customers in an actual clinical environment is crucial to timely project success. After an initial specification is approved by the group, product improvement ideas should be logged in a separate section of the design history file for incorporation into future versions of the product.
Revising the company vision. As if insurmountable technological hurdles and uncontrollable external events aren't challenging enough on their own, some companies further cripple themselves by periodically changing their fundamental corporate direction. This type of change is sometimes a direct consequence of the manager-of-the-month syndrome described earlier, or it can result from an indecisive CEO who is hesitant to pick a single direction and stick to it. One startup company, for instance, changed its vision three times within its first year of operation. The ramifications of these vacillations are great: projects are started, refocused, and started again. In addition, highly qualified personnel may leave to pursue opportunities with more clearly defined projects and a better chance of bringing products to market quickly.
Giving engineers free rein (and cleaning up afterward)
Creative technical people are rarely enamored of the rigors of disciplined project management and document control. Unfortunately, an uncontrolled development phase can result in nonconforming design history files and additional delays and expense on the back end of a project. The following items and tasks are most frequently ignored when the creative process runs unchecked and unsupervised:
Formal requirements documents. Neglecting to draft and release formal requirements documents prior to performing design tasks is a commonly taken shortcut. Engineers are often heard saying, "Design it first, then write the spec." To a certain extent, this order of events makes sense, though it violates all basic design control guidelines and leads to an unacceptable design history file. As a compromise, product development programs should plan for a concept development phase in order to settle any design uncertainties and to lay the foundation for a stable requirements document.
Human factors analysis. Engineering-driven projects tend to de-emphasize the need for human factors analysis during a project's evolution. Not infrequently, an industrial designer is brought in late in a project, after many decisions affecting human factors and ergonomics have already been finalized.
Up-front risk and failure analysis. Sometimes engineers put off formal risk analysis and failure modes and effects analysis until after a design is completed. Unfortunately, this tendency may cause an engineering group to suffer through a redesign effort if significant unmitigated hazards are discovered at the end of the design phase. To conform with design control guidelines, a formal set of analyses should be conducted before design efforts begin. The analyses then function as a roadmap for the engineering team and help team members make critical decisions that affect safety and performance.
Adequate verification. Failure to conduct timely verification steps or perform design reviews after each design phase not only violates design control guidelines, but also circumvents the check-and-balance benefits that are fundamental to any quality system. A well-planned project breaks up the overall design into manageable chunks, each with its own verification step and design review. Engineers familiar with this type of chunk-by-chunk process learn to recognize that it isn't so different from what they normally do to verify that each design piece actually works. Performing verification tests after each design phase simply formalizes the process and documents the results.
Quality and manufacturing involvement. Keeping the quality and manufacturing groups out of the development process seems to be a natural, albeit unfortunate, cultural tendency in most companies, according to our original article. This tendency not only breeds ill will between departments, it can also create a serious delay in the product release schedule.
About the Author
You May Also Like