Some Cool Cats in Medical Device Industry

You probably already know about the benefits of networking. I sometimes go through cycles where I forget about it. And when I do and thrust myself back into networking mode, I become amazed again at the benefits and opportunities gained from networking. I’m not just talking about job and project opportunities. Actually, I’m talking more about the types of people you get to meet and the things you get to learn. Being in the medical device industry, too, means that when you network, you are going to meet some really cool cats doing some really amazing things to save and sustain human life.

One of these cool cats I recently got to connect with is Tom KraMer at Kablooe Design. Okay, when you go to the Kablooe website, you are presented with this image:

Design Driven Development

It’s very catching and memorable. And then when you learn more about Kablooe through the YouTube videos and other pages on their website, you really get an opportunity to learn about an innovative company led by an innovative person. Okay, after you get done stalking Tom and Kablooe, make the effort to connect with him. He’s very active on LinkedIn and pretty accessible.

I have yet to have had an opportunity to work directly with Tom and Kablooe, yet look forward to doing so sometime in the future.

Medical Device Design Control Greenlight

What do you think of when you hear the term “green light”? I hear “go”! In the medical device world, getting the “green light” can mean a lot of things–all positive. Getting the green light from FDA means your submission is cleared, and you can go to market.

But as medical device product developers, we often have a great deal of uncertainty while in the trenches of product development. We don’t have good tools to give us the proverbial green lights we seek. We are often tasked with aggressive timelines and tight budgets, with a need to ensure all product development and Design Control documentation is current, up to date, and compliant. Pressure, pressure, pressure!

You seek tools and opportunities to communicate, collaborate, and gain efficiency. You want to know that when we document our Design Controls that the results are sound, thorough, and complete. You often create spreadsheets and organize folders on the network drive to ensure organization and traceability of all the documentation you need to generate throughout the product development process. The tools available rarely meet your needs, but you make due.

All the while, you are seeking a better way. You are seeking a smoother way. You are trying to find ways to get those wonderful green lights during product development and Design Controls.

I assure you a better way to allow you to get those green lights is available.

What If You Could Have A New Design Control Experience?

Since starting my career in the medical device industry over 15 years ago, there have been a few constants. One of these constants is that many medical device product developers loathe Design Controls. Many of the comments I’ve heard over the years have claimed that Design Controls often hamper and slow down product development. And nearly anyone who has worked with existing product development processes at a medical device company seems to cringe at least a little at the mention of “Design Controls”.

Let’s just say there are very few individuals I’ve encountered during my career who are genuinely excited about Design Control documentation, processes, forms, etc. I’ve perceived actually that there is a fair amount of “pain” felt regarding this topic.

It’s because of this pain that has led me and a small software team to find a better way. This better way is called UniDoc. Our team has had there head down for the past few months developing this tool. On April 1, we are releasing a “sandbox” to a group of early adopters who can also start to learn about the better way of documenting, collaborating, and managing Design Controls and Design History Files.

I’ve had a chance to play in this sandbox before releasing it. I’m VERY excited about how UniDoc works and the impact I know it will make in the medical device industry.

Do you want to be a part of a new Design Control experience? Contact me and let’s figure out how to make this happen.

Importance of Medical Device Design Controls – Part 2

Read part 1 of Importance of Medical Device Design Controls.

Now for part 2 . . .

If you evaluate the regulatory trends and hot topics, Design Controls usually makes it into the top five. However, the current culture of the medical device industry rarely push Design Controls to the top. Rather, topics like Complaint Handling, Corrective & Preventive Action (CAPA), and Risk Management often dominate medical device industry blogs, conferences, and hot topics. This is somewhat justified due to the focus and attention regulatory bodies across the world have paid to these other important elements. Let me take a few moments to talk a little about each of these other topics with respect to Design Controls.

Complaint Handling pertains to medical device product issues and failures. This topic has received a great deal of attention because so many companies struggle with how they handle complaints. Complaint handling processes are poor at best with supporting documentation being equally as poor. I don’t discount the importance of a sound Complaint Handling process. However, if we spent as much time on the front end during the medical device product development process to ensure the products we design are safe and effective, would complaints go away? Of course not likely. But could the occurrence rate be reduced? Perhaps. Wait, don’t we have mechanisms in place to do just that? Yes, we do. Design Controls.

Corrective Action pertains to fixing product (or process) issues. Preventive Action pertains to having some foresight to fix an issue before it happens or becomes a big deal. Okay, if we spent time up front during Design Controls, could we reduce the need for so many CAPAs? I postulate maybe.

Risk Management pertains to documenting the hazards, harms, risks of medical devices. In a nutshell (please don’t shoot me for oversimplifying), Risk Management is documenting what can go wrong when a medical device is used. Again, if we evaluate the origins of Design Control, safety and effectiveness were intended to be embedded within Design Controls all along. If fact the FDA Design Control regulation for Design Validation includes the term “risk analysis”. In recent years, though, Risk Management has been likely driven more because of our litigious society.

No, I’m not so naïve that I think Design Controls fixes all issues and makes Complaint Handling, CAPA, and Risk Management less important. Clearly, Design Controls is largely part of medical device product development. And once a product is launched into the market and manufacturing, other processes need to take over. Very valid point.

One of the necessary product lifecycle processes is Change Control. Change Control pertains to monitoring, documenting, and maintaining a medical device product throughout its lifecycle. In my way of looking at this, Change Control is a natural progression, maybe even an extension of Design Controls. Change Control is a way to ensure the medical device evolves based on clinical needs. In my opinion, the bond between Design Control and Change Control should be strong. As you likely know, the culmination of all Design Controls results in the creation of a Design History File (DHF). Many ascribe to the belief that a DHF is a snapshot in time of a medical device during the product development process. Okay, I understand that, to a point. I’ve often wondered, though, if a DHF should continually be up to date based on the current medical device design. Those in the DHF is a snapshot in time camp will point to Change Control as the continuation of the medical device design; Change Control is the “living” documentation and records. Maybe a matter of semantics.

But whenever we make changes to a medical device in production, we must assess the impact on verification and validation. Aren’t these Design Control elements? What if we had a way to maintain Design Controls as living throughout the entire product lifecycle?

I’m sharing these thoughts for a purpose. Primarily, I hope to provoke a new way for the medical device industry to think and behave. I truly believe Design Controls are the foundation of all medical devices and think it is time that we treat them as such. To do so, we need better tools and processes for documenting medical device Design Controls.

Importance of Medical Device Design Controls – Part 1

Is medical device product development really all that different than product development of other products and technologies? If you take a moment to really think about this, the answer is not all that easy to address. From one perspective, no, the medical device product development process is by and large just like any other product development process. Sure, some of the work products and deliverables and regulatory requirements are different. But overall, the process is the same (or at least it should be): establish a business case, capture user needs, define requirements, figure out how to build it, prove that it is safe, prove that it works, prove you can make it. From another perspective, yes, the medical device product development process is vastly different than other product development processes. Why? Regulations, largely. Regulations that dictate what to do and when to do it in order to prove and demonstrate that a medical device is safe and effective.

In the end, the question is really not all that relevant. Sometimes we like to brag (and other times complain) that the rules we have to follow are strict and difficult. We brag when we think about how and who the medical devices we design and develop will be used. We complain when we are up against deadlines to get tasks done. Regardless, the rules of medical device product development are somewhat defined. Yes, sometimes those of us in the medical device industry are sometimes proud that we have our own unique lexicon of terms to describe product development. We refer to these rules as “Design Controls”—mostly because the U.S. FDA has defined the medical device design control regulations (refer to FDA 21 CFR part 820.30).

We can debate if Design Controls is synonymous with medical device product development or if Design Controls are proof and objective evidence that regulations have been met during medical device product development. I’ve been part of some very heated and passionate conversations on the topic. Interestingly, the answer does not matter. Regardless of your point of view about the relationship of Design Controls and medical device product development, I suspect we all accept that Design Controls are expected behavior when it comes to medical device product development.

Briefly, Design Controls includes: Design Planning, User Needs (although not explicitly part of regulations), Design Inputs, Design Outputs, Design Verification, Design Validation, Design Changes, Design Reviews, and Design Transfer. Some also throw in Risk Management. For now, I want to leave Risk Management out of this and revisit it later. Design Controls dovetail nicely with a natural progression through a product development process. A nice linear path. Just like product development is intended to be. Or at least this is how we often describe and depict the process. Do this and then that and so on. But medical device product development is most definitely NOT a linear process.

Again, this is a concept that can elicit heated and passionate conversations.

All medical devices on the market today at some point in time began as an idea to solve a clinical need. All medical devices on the market today at some point in time went through a product development process. And conceivably, within the past fifteen or so years, many medical devices likely have supporting Design Control documentation and records. Suffice it to say that Design Controls are the foundation of a medical device.

Interestingly, the topic of Design Controls is still very confusing to many within the industry. I think it is confusing because we (collectively speaking) have made it that way. We have married Design Controls to sometimes convoluted and complicated business processes. In other cases, we feel compelled and sometimes forced to follow the linear “rules” of Design Controls, that we have more rigidity than need be. When asked to think about Design Controls, many think of documents, tables, and spreadsheets. We seldom describe Design Controls for what they are: objective evidence to prove our medical devices are safe and effective. We have lost sight of the importance Design Controls truly plays in the health of the medical device industry.

Building Strategic Partnerships in Medical Device Product Development

The term partnership is strong. When I hear the word “partner”, I think of other words such as equal, support, team. This is true for medical device product development. Whether you work for a completely vertically integrated company or are a startup leverging relationships with third party suppliers, you need to build strategic partnerships to be successful with your medical device product development efforts.

I recently posed the question “What do you do to form partnerships with key suppliers?” in a LinkedIn discussion. I asked the question from the perspective of a startup. A few of the comments are shared below:

  • Supplier become part of the team as a partner that can be relied on to meet all solution needs
  • If the startup vision and supplier motivations do not complement one another, there will be issues
  • Takes time to build the relationship and above all this must be based on mutual trust

Of course there is a great deal that goes into establishing a true partnership. It’s not like you can wave a magic wand and partnerships are formed.

Keep in mind that to form solid, reliable business relationships, you have to be willing to answer “what’s in it for me”. Some may think this sounds selfish. Yes, we hear all the time about “win / win”. Sure, I guess. When you answer WIIFM, you need to try and answer the same for all the other stakeholders. And, I’ve found that it can be very helpful to have a very candid conversation with potential strategic suppliers from the very beginning. If everyone can be honest and answer the “what’s in it for me”, then we should all be more aware of the individual motivations involved in the product development efforts.

As the one comment from the LinkedIn post indicates, building strategic partnerships takes time. And trust. When trust is broken (or never established), building a partnership becomes challenging.

Keep in mind, too, that never every supplier relationship has to evolve into a strategic partnership. Sometimes you might only be interested in working with a particular supplier for a certain product or service. That’s fine too.

Medical Device Prototypes Can Mislead

Once upon a time, I was a huge proponent of prototyping medical devices as soon as possible. Today, I’m a little more hesitant. Don’t mishear me–prototypes of your medical device can certainly be extremely valuable. However, I think it is VERY important to be clear about what you hope to learn from the prototype. Equally important, it is VERY important to understand what the prototype can not do. In other words, know what decisions can be made based on the type of prototype you have.

Let me expand a little.

Several months ago, we were initiating a medical device design and development project. We had some product designs sketched and started to narrow the list down to just a few concepts. Once narrowed, the design resource offered to “grow” some 3D prototypes. Within a few days, we had 3D concepts in our hands to better evaluate some of the design ideas we had been discussing a viewing on screen. Having the prototypes in hand was helpful. We were able to better evaluate features and aspects of the product design. We were able to play around with component interfaces and get a feel for how the user would interact with the device. We made a few tweaks but soon, we decided to proceed with cutting steel for injection mold tooling.

Tooling was to take ~10 weeks. We made progress on other parts of the product design while we patiently waited for those first articles. When the tooling was completed, first articles were provided soon after. We were all anxious to evaluate these parts. When we did, the design presented to us via concept sketches and 3D prototypes did not seem to translate into injection molded parts. What happened? Why not? The design resource offered that the prototypes might not have been an ideal representation of the injection mold parts. They also stated that they could make a few minor modifications to fix some of the design concerns. Another round of prototypes and another round of discussions.

Why was this round of 3D prototypes any different? I guess we trusted that the designers would make the design right.

Several more weeks were necessary to modify the tools. And eventually another round of first articles. Which once again, failed to hit the mark we needed with the product design. Frustrated began to mount. And I kind of scratched my head. What went wrong? Why were the prototypes so bad at representing the product design?

Then it hit me. Medical device prototypes are not the end all be all. Prototypes have limitations. You have to understand what the 3D prototype can and can not do for your design efforts. I learned that SLA-type of prototypes is not a real approximation of what you might expect from injection mold tooling.

When you get prototypes for your next project, take a few moments to truly understand what these prototypes can tell you. What exactly can you learn? More importantly, do not fall into the trap that a 3D prototype can answer all your design questions. It’s a tough trap to avoid. The proliferation of 3D CAD tools and easy access to affordable 3D printers has allowed the rapid proliferation of prototypes. Sometimes we have a tendency to make 3D prototypes just because we can and it’s cool. Rather, we should be striving for effective prototyping.

I was once told that if a picture is worth a thousand words, then a prototype is worth a thousand pictures. No truer words have ever been said. But if you do not fully understand what the prototype can teach you about your product, it doesn’t matter if the prototype is worth one million pictures.

Startup Medical Device Project Lessons Learned

From time to time, I like to share some lessons learned from current projects. We are in the middle of product development for a medical device startup project and have plenty of recent lessons learned to share.

In no particular order—

Dates Are Wrong

We all know this. Yet there is also a compelling need to drive towards completion of tasks. Does having a due date help or hurt? I can find plenty of people to support either argument. I don’t like dates anymore than the next person. But at the same time, my opinion is that without a target date for completing a task, a task could linger.

Of course if you are surrounding with people who are checklist oriented, accountable, and driven towards getting things done, dates probably don’t matter all that much.

However, I have rarely been involved with any initiative of any kind where all people involved were wired in this fashion. Because of this, dates are a necessary evil.

A trick as a project manager is to figure out each person’s buffer. I often refer to this as a “fudge factor” (I know this term was ingrained in my brain somewhere along the way; I just can’t remember when or where). What I mean by this is in my experience, when prompted to provide a date, most people will give you a best case scenario response. The challenge is to figure out how far off their best case is from reality. You won’t learn this initially. You will have to let the person give you false information a time or two first to establish their particular fudge factor.

Hierarchy & Order Are Important

What I mean by this is that it is important to have a process in place and to follow the process. I think this is especially true when startups are mostly virtual and rely heavily on suppliers. Some suppliers may have process in place. Others may not. To complicate it further, each supplier might have a slightly different process too. In all cases, it is important to establish at the beginning what process will be followed. It is important to outline and identify the specific deliverables, along with when each of these deliverables is to be accomplished.

Scope Creep Will Happen

Despite your best efforts, scope creep will happen on every project. To expect that you can clearly and completely articulate, communicate, and establish a scope of work at the beginning of a project and that this will not change as the project progresses is unrealistic.

Rather than resist scope creep, figure out how you can manage it. The most challenging scope creep issues pertain to the expectation that the budget and timeline won’t change. Scope creep, more than likely, will affect both budget and timeline. When a scope change is suggested, take a moment to evaluate what this means to the project and communicate this to the stakeholders.

Double Check Always

You would think I would have learned after the first few times a resource told me a task was done only to find out otherwise that I would have started double checking sooner. I mean, come on, I’m working with adults, right? When someone tells me they got something done, I should expect that it is done. Yes, that statement is true. However, it’s also true that people don’t always complete what they say they’ve done. I think this is because the person expects they will get the task done before you actually find out.

I now will do my best to always double check and to get objective evidence that a task is done.

Have a Back Up Plan Brewing

You never know when you will need a back up plan. I can tell you from experience numerous times on this project that developing a back up plan after it’s already needed is not fun. Yes, I want to trust all the resources I’m working with. However, this project has taught me that I always need to have a back plan in the works, just in case.


Being Thrown Under the Bus

I’ve worked on enough medical device product development projects to tell you there is rarely a dull moment. Throw a startup into the mix, and it gets even more interesting. One of our current medical device startup projects is establishing the new definition of interesting. Not so much because of the device technology. But more about the steps involved to get their product to market.

In full disclosure, I do get paid by the startup and am likely to exhibit a slight bias towards their point of view. However, in an effort to be as objective as possible, some of the things I’m about to share in this post are just examples of poor business practices.

For the past couple months, the product development project team has been tasked with finalizing the product design in order to begin the transfer to manufacturing process. The project team is comprised of members from the startup, hardware / software, mechanical, and contract manufacturing. The CM has been largely responsible for mechanical design. Parts of the product have progressed quicker than others. Some parts of the design have had multiple iterations and still were not right.

Which has been very trying for the startup. This has been especially true with respect to the mechanical design. 3D prototypes were provided quite some time ago and really worked well. Based on these 3D prototypes, the startup signed off on the design and tooling was initiated. When the first articles arrived a few months later, the product design was not as sound as the 3D prototypes. So the mechanical design needed to be tweaked. Another round or two of prototypes to hone in on a design. Tweaking meant modifying tooling. And several more weeks.

Thankfully, the other parts of the product design were able to progress closer towards production readiness.

Tooling was modified and revised parts were provided. However, the performance of the design still did not meet expectations. Going into this round of revisions, the startup had low confidence in this resource. After receiving the next round of parts, confidence was gone. The CM said they would make a few more “minor” tweaks and could get the design nailed. They committed to having a solid working prototype within a week. When that day came, the startup and I were present for the unveiling. However, the prototype was not ready. The CM was still making the prototype as we talked.

I left frustrated, although this result was not unexpected. The CM realized there was quite a bit of work. They asked that we come back a few days later, stating that they had a solution that would “blow my socks off”. Yes, they finally seemed to have the fix. Blow my socks off? Not so much. But prior to moving forward, we needed to know how much the tooling modifications were going to cost.

Another week of waiting for this. And when received, the costs and lead times were ridiculously long. Receiving this news was not settling well with the startup. Then the CM provided a list of all the outstanding charges for the project. Most of these fees were known and agreeable. But there were quite a few items that were surprises and had never been communicated by the CM.

Receiving this communication was the last straw. The startup communicated that they would be ending the relationship with the CM. That prompted another email message listing yet additional fees and charges.

Did I mention that I let the CM know several months ago that the startup was not happy with the relationship and actively searching for other options, just in case?

After some back and forth via email and phone, it’s clear that CM and startup are not in 100% agreement about the outstanding charges. Interestingly, though, startup and CM do agree about a good percentage of charges and materials associated with these fees. Logically, startup (and I) believed that we could settle up on these items, with startup taking possession of the materials. CM has a different point of view. Their stance so far has been “all or none”. Keep in mind that startup has loaned some materials, flat out purchased other materials, and issued purchase orders for others. Yet CM will not release this stuff.

Instead startup has been waiting for nearly two weeks to have a meeting with CM to discuss everything.

This meeting should finally happen later this week.

Another interesting tidbit pertains to some of the messages and jabs that have been thrown in emails. CM has suggested startup and I need to communicate with one another to get on the same page. Startup and I talk almost daily. I assure you and the CM, we are on the same page. CM has also said that the extra charges that were “surprises” should not be because these are items they have discussed with me. I feel a being thrown under the bus moment. Ever since startup said they are ending the relationship with CM, it has felt like stalling. It’s my opinion that the resources at the CM should take some of their own advice in order to get on the same page.

Projects Lose Hours All the Time

Project management is fascinating and intriguing to me. Yes, I know that may seem a bit strange. How do projects get done? What motivates teams and individuals to accomplish tasks? What can you predict will happen?. How repeatable is the overall process? How do you improve product development efficiency? How do you measure product development efficiency?

As a systems kind of guy, I sometimes see the world in front of me laid out as a giant flowchart. I see steps for individual processes and decision points. I’m constantly searching for ways to gain efficiency as I scan the process over in my head. What can be improved next on the project? How can this learning be carried forward to the next project? Does this learning even apply to future projects?

So many questions to better manage projects. Interestingly, in my experience, however, there is so much time lost in every single project that is not measured and never accounted for. Hours upon hours are lost and accepted as just the way projects happen. The project stakeholders often are furious about things taking too long. And as a project manager, I constantly seek ways to gain momentum. Ways to save hours here and there. When I take a moment while in a project to evaluate the state of things, I can always find hours and hours that were lost. Hours that can’t come back.

It can be frustrating. Frustrating because projects have so many opportunities to gain efficiency. Yet, despite this, we can’t seem to figure out where the time is lost and where we can gain time. Part of the problem is, we don’t effectively measure these things. We don’t take the time to actually find ways to do it better the next time.

How can we change this with product development? How can we gain lost hours and improve our overall efficiency?

Project Schedules Are Wrong

As a project manager, I have a love / hate relationship with project schedules. Yes, it’s true that nearly every project I’ve ever worked on had a due date assigned to me before we even started the project. And as a project manager, I hate this. Because in those circumstances, I have to craft a project schedule that gives the assigned due date as a feasible option. You could argue that I’m doing myself a disservice and setting false expectations by taking this approach. This practice could give the stakeholder an incorrect assumption about the ability to actually achieve the due date assigned. Perhaps. And at the same time, not providing a project schedule with this approach also gives the impression that the due date assigned is not a possibility.

Let me expand by discussing an ongoing medical device product development project. This project started in December 2012. Prior to starting the project, I met a few times with the startup CEO. In previous discussions with others, he concluded that his device idea could be launched into the market within 6 months of starting product development. I asked several questions and advised the startup that 6 months was not realistic; a FDA submission would be involved and that alone could easily take 6 months. As a counter, I suggested that his project would likely take around 18 months. He challenged that notion, craftily talking me through the phases. I knew what he was doing and played along. At the conclusion, the startup CEO decided the project should take about 12 months. Realistically, 12 months was actually possible.

Possible, but not likely. I highlighted a few of the unknowns. It didn’t matter. We started in December 2012 with the CEO expecting to be ready for market launch by December 2013.

It’s February 2014, and we have not had market release yet. We are still a few months out but getting there. There have been lots of twists and turns along the way–all in the spirit of this is how product development goes. And of course if we had the foresight that an issue would happen, we would obviously address, mitigate, and prevent the occurrence.

Project schedules are perpetually changing and always wrong. Always. A project effort of any size with more than one team member is chock full of numerous variables and unknowns. So are project schedules really necessary? A potentially interesting question. One that was recently posed to me by project team members on another product development project.

I have been screaming for visibility and commitments on when project tasks would be completed. One of the first major issues on this project is a lack of centralized project management. Yes, it’s a startup and theoretically, each of the team members is motivated to get the job done. However, having no one assigned to project management is starting to become an issue, in my opinion from my perspective. I recently challenged the other team members to provide a target date of when a few of the major milestones would be completed. The project team members pushed back hard. Their main argument is that there are three major factors involved in their product development efforts: quality, speed, and cost. They pushed and told me to pick two. If I want it fast, then the quality would suffer.

But I wasn’t necessarily asking for speed. I was simply asking for a target–a schedule. More pushing with a response that they could not commit to any meaningful, realistic schedule. They cited some case studies from a large company who has been through product development thousands of times over the past 50 years. Okay, I understand that providing me a schedule means the dates will be wrong. However, telling me you have no idea of when I could expect a task is also wrong.

What is the happy medium?

The Lies of Medical Device Product Development

The lies of medical device product development. There are many. Here are a few to consider.

Have you ever had a project resource tell you that a task would be done by a certain date only for it not to happen?

Have you ever had a vendor tell you a price for a product or service only to find out it is actually more expensive after you have already committed to them?

Has a vendor ever offered you “free services” in order to help you out of a jam and to get your business only to find out about all their hidden fees later?

Medical device product development is full of unknowns and uncertainty. Maybe it’s a little harsh to refer to these situations as “lies”. And yes, I am guilty of many of these offenses. Not that I ever intended for them to be untrue. But it’s happened before and am sure it will again.

So how do we remove the lies from medical device product development? Is it possible?


Hang In There – Project Management Lessons from the Trenches

I saw red the other day during a disagreement with a supplier we are working with on a product development project. It happened during a discussion about a design issue for a medical device product. Without going into too much depth, the supplier has been tasked with fixing a design flaw in the device. A couple months ago, the supplier had quite a few more tasks assigned to them as well. But as the project manager, I observed the supplier not being able to manage the volume of tasks. I decided to take most of the tasks away from the supplier and added them to our plate instead. Not a big deal. In fact in probably made the most sense for the client any way. Doing so allowed the supplier to have a single major task: fix the design flaw.

It’s been nearly six weeks. The design flaw remains. Each week seems to be a replay from the week before. From my perspective and the perspective of the client, the supplier has made marginal progress at best. Confidence in this supplier declined more and more with each passing day. Last week, the client and I discussed a strategy. One tactic was to have an “all hands on deck” brainstorming session with the supplier. Another tactic was to find alternative suppliers just in case.

We held the all hands discussion. Some good ideas came out of the discussion. The supplier provided a schedule as to when prototypes would be in hand to evaluate whether the concept had merit. As this date approached, the supplier backpedaled and pushed the date out. My patience has been wearing thin for a while. With each delay and day that pass, the depth of discussions I have been engaging with alternative resources has increased. Finally, the supplier set a time for the client and I to visit to review the prototypes.

When I arrived for the meeting, the lead engineer at the supplier was still tinkering with the prototype. It wasn’t right. I sat there patiently. The client was aggravated. The engineer assured us he could make tweaks here and there. He just needed five more minutes. Ten minutes after this statement, it was very clear that the prototype would be ready another day. We left.

The results of this meeting made it clear to me that I was going to have to engage another resource to fix this design flaw. I requested CAD source files from the supplier. They said no. I called the supplier to understand why not. I was told that the client does not own the source files and has not paid for these. CAD would not be provided. Keep in mind I did share with the supplier last week that we had to consider looking for other resources due to the project delays encountered. The request for the CAD data was a clear signal to the supplier.

He got defensive. He said the classic line that “. . . this is how product development goes . . . ” That line is total bull shit and a cop out. Especially since I have been doing my best to give the supplier a single task focus and not burden them with other tasks. The supplier also then chastised me for working with a couple resources he connected me to for the project, stating I was stealing resources he brought to the project. His tone was condescending. I did my best to keep my cool. The supplier then told me to “hang in there”. Are you kidding me?!

If you know me, you know I’m very much a “silver lining” kind of guy. I’m trying to find the silver linings from this experience. I have a few:

  • When working on a product development project, ensure that resources are compensated for their time. Do not work with suppliers who choose to not charge for the time for their resources and instead roll the costs into tooling and eventual manufacturing.
  • I’ve yet to find a contract manufacturer who can handle product design. I’m sure there are exceptions but so far in my experience product design and contract manufacturing are conflicting skill sets. And for that matter conflicting areas of interest.
  • Micr0-managing resources on product development projects is necessary until the resource proves otherwise.
  • All project resources lie about when they will have stuff done–myself included. Okay, maybe “lie” is a little harsh. Yes, I know when a resource provides a date when something will be done that more times then not, this is the intent. But I also know it’s wrong.
  • A project manager needs to have direct lines of communication with all resources working on a project. It does not work to communicate via a middle person.
  • Despite what the client wants and how pushy they might be, I need to stick to my experience and convictions about how to navigate through a project. For example, if the project is a product development project, we must finalize the design first before even thinking about manufacturing.
  • When resources screw up, they probably won’t admit it. Instead, they will probably make every attempt to cover their tracks to fix the mistake before you find out. If you find out before it’s fixed, they will probably blame someone and something else.

Contingency Planning for Medical Device Product Development

Never underestimate the importance of a solid medical device product development project plan. But even the best of plans should be revisited throughout the product development process and adjusted according to the ever changing project landscape. Sometimes, though, we are very good about planning early on in the efforts but forget about the need to update.

I’m up to my eye balls in one of these medical device projects right now. Every minute of every working day, and even several minutes of non-working days, can easily be consumed with going from one fire to the next to try and address product development issues and concerns. Lately, I do feel very much like the good ol’ project manager firefighter. Grab a hose and spray towards the latest and greatest fire. Trouble is, I don’t feel like we have enough firefighters and/or hoses to go around. It also sometimes seems like we have a few fire starters on the team. I don’t think the project fires are being set on purpose. I think, though, it is an outcome of a lot of angst.

Okay, yes, you need to understand something about medical device product development (and product development of any kind, really). Product development really equates to a lot of uncertainty. If we know about an issue, we can plan for, prevent, and address the issue ahead of time. Product development definitely can have more than a few “gotchas” that if not properly prepared can wreak more than a little havoc.

So how do you combat this?

Plan. Do. Plan. Do. Yes, this can seem like a never-ending cycle. But that’s kind of the point, right? At the start of a medical device product development project, is it really possible for me to plan all the details of design transfer? Probably not. My planning efforts should coincide with those project phases, milestones, tasks, and activities nearest to the schedule. I can speculate about future phases of development–which probably is somewhat worthwhile. Spending too much time planning too much detail about phases way downstream, though, is probably a bit of a wasted effort. So much is going to happen that will make those future plans obsolete. As you prepare to exit one phase and enter the next, a revised project plan should help communicate this transition to the project team.

Communicate. Communicate. Communicate. If I had a dollar for every time I’ve talked about the importance of communication with respect to product development, I’d have exactly $1.25M by now. If I had to pay a dollar for every time I’ve dropped the ball in some way with respect to effective project communication, I would have lost $2.5M. It’s so easy to talk about the necessity of good, effective project communication. It’s way harder to actually deliver. As a project manager you should assume one thing when it comes to project communication with each team member: you cannot provide too many details. Also, don’t worry if you think you already said something before. It really doesn’t hurt to repeat information. You also may have to pull information from each team member; don’t expect them to come to you ever.

Have contingencies ready. Always. I don’t care how great your project team is and how much experience they have, as a project manager you have to be a realist, maybe even a bit of a pessimist–at least when it comes to project planning and schedule. You have to learn on the fly what each team member is capable of and likely to achieve when it comes to tasks and assignments. You have to learn who can handle a large list of tasks and work independently and who has to be micro-managed and handle one task at a time. You have to expect that mistakes will happen. You have to expect that assumptions will be proven wrong. You have to be ready with contingency after contingency throughout development. When something doesn’t work, figure out other ways to solve problems. But before pulling the trigger on any contingency plan, be sure to weigh pros and cons with stakeholders. And definitely communicate contingencies to project team members, even if this may mean some uncomfortable conversations.

Is Spreadsheet for Design Control Traceability a Best Practice?

What tools are you using to ensure traceability of your medical device Design Controls? How do you show that your Design Outputs meet your Design Inputs? How do you link Design Verification? How do you show that you Validate your User Needs?

Demonstrating traceability of your Design Control activities is not only important–it’s necessary.

A best practice I’ve observed is the creation of a wonderful spreadsheet to show traceability. Each column represents a different Design Control element–User Needs, Design Inputs, Design Outputs, Design Verification, and Design Validation. Showing how one links to the other is the purpose.

Yes, I’m a fan of spreadsheets. I often dream about them.  Yes, I’ve used spreadsheets for Design Control traceability countless times.

Despite this, I think using a spreadsheet for Design Control traceability does have some shortcomings.

  • Spreadsheets are not really collaborative. Okay, you certainly can share a spreadsheet with your team on a network drive or some cloud-based file sharing application. Doing so helps, but you usually lose some of the control in doing so. You often lack an audit trail of who made changes and exactly what was changed.
  • Spreadsheet traceability typically requires redundant data entry. Chances are you are going to copy and paste content from other documentation to populate the traceability. Copy / paste has shortcomings. What happens if you discover some piece of content requires a change? Now you have to go back to all the places where that piece of content is and update it everywhere.
  • Spreadsheet traceability is a snapshot in time. It’s not “living”. It’s hard to keep current and up to date. Typically, someone has to own the spreadsheet and takes responsibility for keeping it updated. At least until the project launches into production. Then the spreadsheet traceability is buried in the DHF and archived.
  • Not everyone on your team is fluent in “spreadsheet”. Yes, I’m a fan. You might be too. But often times, a project with any size can result in a very unwieldy and hard to follow spreadsheet.
  • Spreadsheet traceability does not cover all Design Control elements.

Yes, the beloved spreadsheet has been a best practice for demonstrating Design Control traceability. A new best practice is emerging, however.


UnDoc leverages the strengths of the spreadsheet. The ability to show linkage of User Needs, Design Inputs, Design Outputs, Design Verification, and Design Validation. UniDoc organizes this content is a simpler fashion. Content is broken into smaller, easier to follow “chunks”.

UniDoc is collaborative. Your team has access to your medical device product development project in the software. Team members have the ability to add content. And you have a complete audit trail of who made an update, when the update was made, and what the update was. All team members can access simultaneously. No need to check a document in and out. Plus, your team members don’t necessarily have to be fluent in spreadsheet. If they want to add User Needs, for example, they can do so in UniDoc, whether in the User Need data entry space or within the traceability table. Once the content is added once, it doesn’t need to be copied and pasted throughout. One time. Plus, the traceability is constructed as content is added.

Content within UniDoc is current and not a snapshot in time.

UniDoc also covers the other Design Control elements not addressed by your current spreadsheet. Design Planning. Design Reviews. Design Changes. Design Transfer. Design Histor File. All contained within UniDoc.

So while I agree your spreadsheet is likely very good for Design Control traceability, I believe that UniDoc builds upon this and provides a more thorough Design Control solution for all your medical device projects.

This is why we designed it.

We are rolling UniDoc out. Do you want to be part of this?