When I began my medical device career, I started as a product development engineer. Part of the role included—right, wrong, or indifferent—project management. And I’ve found throughout my career and from discussions with hundreds of others in the industry that this is commonplace.
ADVERTISEMENT |
What I learned, however, a few years into my career is this: Just because you’re a product development engineer doesn’t mean you have any project management skills. I would even go so far as to state that most product development engineers are, in fact, terrible project managers.
Which poses the question: Why do so many medical device companies have product development engineers also serving as project managers?
I believe that project management should be its own discipline and function within a business. It probably should have a different organizational chart and reporting structures. During my early years of project management, I was taught, or at least learned, that this meant prolifically using Gantt charts and MS Project.
Yes, I’m guilty of drafting Gantt charts with well over 300 tasks. Yes, I’m guilty of the overuse and misuse of predecessor tasks and definitely was a bit of a “theory of constraints” disciple (thanks to The Goal). I remember being very proud of my Gantt charts, imagining and sometimes outwardly prophesying that this was our road map to project success. Did I really believe this, or did I just want it to be true? Probably the latter.
I could continue with several more examples of my project management faux pas. Let me summarize it this way: It took me longer than it should have to realize the misconceptions regarding project management.
Let me share with you seven project management tips that will help you be more successful with medical device product development.
Tip 1: Define project scope
What is a project? I think sometimes there’s a great deal of confusion between a project and a product within medical-device product development. A project defines the beginning, middle, and end of designing, developing, and launching a product. A project should have a defined beginning and a defined end.
All projects should have defined criteria and requirements. A key project requirement includes scope of work. What are you developing? What is the project’s goal? What resources will be required?
It’s also important to know what is not in the scope of work.
You and your project team should be in alignment with the product you’re developing. There should be alignment on the major milestones and deliverables. Yes, schedule and timeline are important, but not so much that they should drive the project. When defining project requirements with respect to the timeline, think more high-level (e.g., Q2 2022) vs. being too date-specific. (I share some thoughts about schedule and timeline management below.)
Tip 2: Manage product requirements
The most important aspect of any medical-device product development is 100-percent dependent on the product requirements. Think user needs and design inputs. It’s imperative to define the requirements early. Otherwise, how will you really know if you’re able to achieve project success? How will you know if your project timeline is realistic?
When defining requirements, it’s important to collaborate and review with the team. Poor requirements definitions and lack of stakeholder buy-in will directly relate to project management failure.
A common mistake that I’ve seen is the desire to fully and completely define all product requirements during the early stages of development. My advice is to be OK with iterating often throughout development. It’s also OK not to know all the answers right away. Identify any ambiguous requirements so engineering doesn’t.
There’s a point in time when making changes to requirements can be problematic. As you get later and later in the project and in development, too many big changes can become an issue that will wreck your project.
Don’t allow the requirements to frequently change drastically during development. Some change is expected, but if you’re giving the design team a new grand direction or new requirements every other week, they’re not going to make progress on the big-picture project.
Tip 3: Define regulatory strategy
One of the biggest impacts on a project relates to understanding the regulatory pathways to bring the product to market. Identify the regulatory paths and options with a regulatory advisor and the project team early on in a project.
I suggest that you also revisit this every few months or so because aspects of the regulatory landscape can change (e.g., new predicates) during the course of a project.
A key component of project management success concerns managing and mitigating uncertainty and ambiguity. Regulatory strategy and paths also can be a source of uncertainty. I’m a huge fan of the FDA presubmission.
A presubmission is a great way to get an audience with the FDA regarding your product and the potential regulatory pathways. This option is especially useful for products that have some uniqueness, or when you’re trying to get some clarity about how the FDA will view your product. Be aware, however, that the presubmission process, while helpful in mitigating uncertainty, is technically nonbinding from the FDA.
Outside the United States, the regulatory pathways are determined more by a rule-based/decision tree methodology. It’s important to understand the potential markets for your product and how the product will be classified, knowing that product classification will have a significant influence on project management.
One example, although it’s an oversimplification, is that a Class III device generally will be more complex, have more criteria to address, and take longer to bring to market.
Tip 4: Focus on tasks at hand
Project management success does require focus. Yes, being flexible, iterative, and nimble to pivot are important attributes of project teams. In order to focus, work hard to remove unneeded distractions.
For example, don’t allow every idea that an investor whispers in team members’ ears to become the new direction. It can derail the timeline and budget for the project. Take the suggestions and put them in your backlog of ideas for future evaluation, or consider initiating a research project to explore the viability of these ideas.
Tip 5: Manage budget and schedule
Remember that good project management is largely about managing and mitigating uncertainty and ambiguity. It might be tempting to craft a detailed Gantt chart that lists every single possible task you can think of as a means to manage and mitigate the project. I assure you that taking this path won’t get you to project success. In fact, taking this path will definitely stifle project progress.
A highly detailed Gantt chart might be decently accurate within the next couple of months. However, beyond that, it will be too vague and inaccurate. And you’ll be spending your time constantly updating the Gantt chart.
Don’t misunderstand me, though. There might be points in time and aspects of project management where a Gantt chart can be useful. But realize that by its nature, product development has a great deal of uncertainty and ambiguity. Here are some suggestions to consider:
• Long range: Create a road map at an executive level—perhaps a high-level Gantt chart that shows the major phases, stages, and milestones.
• Medium range: As a rule of thumb, no detailed planning that looks further out than two months, and no unit of measure finer than one week.
• Short range: Project leaders should step back. Let the teams self-organize and manage themselves how it best suits them. Trust the team to do the work.
• Daily: Focus on information needs for interdependencies, not tangible deliverables.
Plan out a high-level schedule with extra time built in for design iterations, testing failures, and supply chain delays. I assure you that just about every product development project will have all of these “issues” surface at some point during the project.
The testing phases of a project often present some of the more challenging parts of a project. Getting a good handle and understanding of the testing that’s required, as soon as you can, will be very helpful. Plan out the testing path early.
If not identified early, verification, validation, reliability, fault injection, electrical and mechanical safety, and other regulatory testing can inform requirements and cause design iterations, additional time, and increases in costs.
You must “de-risk” the testing path. Build confidence in your testing by running non-GLP (good laboratory practice) or “benchtop” studies first. In fact, my strong advice is to leverage benchtop testing as part of your product requirements definition (described above).
Consider exploring multiple paths and options for the high-risk and most uncertain items. If a potential solution to a technology issue is risky, figure out two or three ways to solve it, and pursue all of them in tandem.
Tip 6: Manage go-to-market process
One of the ultimate goals of a medical-device product development project is to “go to market” (GTM). A major element of doing so will involve the transfer of knowledge and information from development to manufacturing. You’ve probably heard the term “design transfer” or “transfer to manufacturing.”
A common mistake is to view design transfer as a milestone or finite moment in the project timeline. It’s not. Design transfer should involve a series of tasks and activities, and should begin fairly early during product development. Manufacturing stakeholders should be core members of the project team.
Be sure you understand the manufacturing resource needs and allocation. This is especially true when you work with a contract manufacturer. Are there manufacturing engineers available to write work instructions? What about technicians for product testing? Define who will manage the supply chain and how it will be done.
As you get further into the project and closer to GTM, development and manufacturing should spend quite a bit of time working closely on things like verification, validation builds, and pilot production.
Tip 7: Assess and evaluate
The objective of any medical-device product development should be about launching a product that will be successful and have a positive impact on the quality of life. How will you know that your product will succeed? When will you find out?
I suggest that you incorporate activities throughout the product development process, starting early on, that engage key opinion leaders and eventual users of your device. Use these engagements as opportunities for inflection, introspection, and validation (not to be confused with formal design validation per se). At various stages of development, you’ll be making decisions based on assumptions and data. Having actual users involved improves the credibility.
Although not every medical device warrants or requires actual clinical evidence prior to GTM, I do think there’s a lot of value in building time, budget, and resources into your project management to address this before the full product launch.
Yes, design validation, and human factors and usability testing are definitely the means to address this. Just give yourself the opportunities to learn, adjust, and react to what you learn from these activities before the full launch.
Additional resources
Do you want to learn more about project management? Here are several resources.
• Design structure matrix (DSM): Design Structure Matrix Methods and Applications, by Steven Eppinger and Tyson Browning (MIT Press, 2016).
• Distributed leadership: X-Teams: How to Build Teams that Lead, Innovate, and Succeed, by Deborah Ancona and Hendrik Bresman (Harvard Business Review Press, 2007).
• Global medical device podcast episode: “Project Management for Product Development of Medical Devices” (Oct. 2021).
• Greenlight Guru Academy course: “Introduction to Project Management for Product Development of Medical Devices.”
First published Oct. 28, 2021, on the Greenlight Guru blog.
Add new comment