3 Simple Tips to Better Project Management

Have you ever worked on a project where the due date was given to you at the start of the project? I’ve had plenty.

Have you ever been assigned a task and told when it needs to be done? Yes, this has happened to me too. Sometimes I’m told the task needs to be done right away. Other times, though, the assigner doesn’t provide a due date.

You see a lot of people are practicing project management without the discipline, experience, knowledge, etc. of project management. Because of this, I thought I would share 3 simple tips for better project management. These tips can apply whether you are the project manager assigning the tasks or are the recipient of an assigned task.

  1. Project tasks are a negotiation. Yes, I know your boss told you when it needs to be done. And I’m not saying he is wrong. I’m simply saying this. When someone assigns a task to you with a given due date, do NOT blindly accept it without asking a few questions. Try to understand how critical the task is, what are the prerequisites, who else is involved, and so on. Evaluate your own abilities and what else is on your plate. If the due date can be achieved, then do your best to make it happen. If the due date is not practical, make this known as soon as possible, ideally when the task is assigned, and provide a suggestion for when you can complete the task.
  2. Communicate when things go off course. Don’t hide it or try to correct it before anyone notices. Yes, delivering bad news is not anyone’s idea of fun. But if your task is off target in some way, you MUST let the task assigner know as soon as possible. Doing so is important for a number a reasons. For one, your task is probably related to a few others in a project.
  3. Stick to your commitments. When you tell someone a date of when you will have something done, you need to follow through and do it. Plain and simple. Don’t make excuses for why you didn’t get it done. Make it happen.

Okay, this might not be “simple” tips to implement right away. But these 3 tips will improve your ability to get tasks done.

Lack Of Planning On Your Part

Should not constitute an emergency on my part.

I’m guessing you have heard this saying a time or two as well.

But based on the actions of a couple of our clients, I’m guessing this saying has little meaning. Let me share a brief example.

A medical device company has several products on the market in the U.S. and many other parts of the world. They are actively pursuing getting their products cleared all across the world. The company relies on distributors in the specific countries to take care of getting products registered. The company has no in-house regulatory or quality resources and has relied on us to serve in this capacity as a very part-time basis.

And when I say very part-time basis, I mean that we help with regulatory issues somewhat after the fact. Let me explain. Company works with in-country resource to register products, unbeknownst to us. In-country resource has an issue with information provided or needs additional documentation and needs a response within a couple days. Company contacts us in a rush with the emergency to help address deficiencies.

This scenario has happened half a dozen times. Each time, we have communicated the need for the company to be more transparent with us, to let us know what products and where they plan to register. However, there is NO regulatory strategy. There is NO business strategy. The company might argue differently. To paraphrase what the company would say is their strategy: To get products registered in every country in the world and sell, sell, sell.

I can ramble on and on. Let me get to the point.

Lack of planning on your part should not constitute an emergency on my part. Develop a vision and strategy to support it. You should have a plan based on the strategy and communicate this plan to your team and resources. When actions are required, keep your team and resources informed, tweak the plan, and course adjust.

Medical Device Project Updates Buried in Emails

How many email messages do you get a day? I’m guessing your inbox is probably very similar to mine. I’m also guessing there is a very good chance that you have multiple email addresses. Are you good about email management? I used to think I was very good about this. However, the volume of emails these days is just crazy. I could literally spend the next few days just getting caught up on emails.

And I would totally make the current situation worse. Because how would I improve my current email backup? Likely respond with a follow up email message.


What’s worse than death by email? It’s getting updates on medical device projects via email. I try to flag, sort, and organize messages by project–and thankfully I have a ton of help with this task. Even following this method does not help.

I wish there was a better way to communicate project updates in some other, more efficient way other than email.

I don’t keep track of how many hours I spend per day sifting through emails to get project updates. But I’m guessing it’s easily 10+ hours. That’s significant! I’m losing one work day per week keeping caught up. It’s actually probably worse than that. I’m actually losing time during evenings and weekends. :(

Imagine if everyone on your project team also is dealing with similar time losses just trying to find and respond to emails regarding project issues. The hours lost by your medical device team can become pretty significant pretty quickly. It is very realistic that a project of any size is losing the equivalent of a full time resource per week (4 team members losing 10 hours each = 40 hours).

If you could recover 40 hours per week on your project team, what could you do with this extra time?

What choices do you have? How can you flip this time loss issue around in your favor?

Product Development Wastes Time

The content of this post is geared towards product development, regardless of industry. Note, however, nearly all of my product development experience is in the medical device industry.

Every product development project has a ton of wasted time! Do you agree?

Time spent going to meetings. Time spent going through emails. Time spent trying to collaborate with other team members on important project documents.

I could peel back more layers of product development to find more areas where there is product development wasted time. But, if you just look at the time spent in meetings, going through emails, and updating documents, I suspect you could “find” quite a bit of time that you have lost.

Think back for a moment to a recent product development project. How efficient was the team? How efficient were you? Are there a few areas you can think of that sucked a ton of your time? What were these things?

Chances are, everyone on your team also lost at least a similar amount of time. Multiply your time lost by the number of team members. I’m guessing your estimate is easily measured in the 100s of hours if your project was at least a year long.

What if you could have this time back? What if everyone on your project could also recover their time too? How valuable would this be?

Imagine recovering a few hundred hours of time . . .

I recently took a few minutes to evaluate where I lost some time on a recent project. The number I came up with was over 200 hours during the course of one year. That translates to over 4.5 hours LOST per week. What could I have done with a that extra time? I might have been able to take on another small project. Or spent more time with business development. Or maybe even just taking a little bit of time off to do whatever.

My point is this. Every product development project has a TON of wasted time. There are all kinds of reasons. I contend that one way to recover this time is to use better tools for project specific documentation, communication, and collaboration. Not only will these better tools save you time, they can also help ensure consistency and provide a platform for the entire team to use simultaneously while capturing project specific information in one, central location.

If you are part of a company, chances are there are multiple product development projects ongoing at any given time. These better tools can also be used as the hub for all product development projects. And keep in mind, that if you use these tools, your organization can recover 100s of hours per team member per year. By doing so, you can take on at least one more product development project per year.

What would that be worth?

Being Better at Delegation

Do you do a good job at delegating tasks to others on your team?  I’m learning I might not be as good at delegating as I once thought. Because of this, I decided to refresh myself on the rules of delegation.

Here are a couple articles I found useful:

The 12 Rules of Successful Delegation

Delegating Authority Skills, Tasks and the Process of Effective Delegation

A couple of the rules that resonate:

  • Delegation is a two-way street
  • Make sure you consider ability and training needs
  • State the required outcomes and results

Yes, reading these articles highlights that I need to improve my delegation skills. And to be a successful project manager, effective delegation is a must have.

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.


Communication Is So Vital

I know I’ve talked about the importance of communication with projects many times before. If you search the CQ blog for communication, you will get quite a few hits.

Communication can make or break a project. Simple to say. So hard to practice.

Merriam-Webster offers one definition of communication as:

the act or process of using words, sounds, signs, or behaviors to express or exchange information or to express your ideas, thoughts, feelings, etc., to someone else

I strive to be a good communicator in all aspects of my life. I often fall short. Communication, especially project related communication, is fascinating to me these days. As a project manager, I feel responsible for leading and driving communication to ensure tasks and responsibilities are understood and progress is being made. When something falls through the cracks, a task is misunderstood, or a miscommunication occurs, I feel somewhat responsible for this.

The trouble and enigma surrounding communication is that it involves more than one person. Just because I feel like I have done a good job “communicating” a message is NOT good enough. The person receiving the message need to verify receipt of the communication. And if more than two people are involved, effective communication becomes even more challenging.

Couple this with all the ways used to communicate these days: face to face, verbal, email, text, body language, and so on. If you work with a team, there is a very good chance that team members have different methods of communication they prefer. As a project manager, I have to do my best to figure this out quickly. I also have to keep in mind that a person’s preferred method of communication could also change.

Work in a project environment, there is a high tendency to rely too heavily on emails for communication. Emails alone are not good enough. Personally, I prefer live communications–face to face and verbal. Lately, I attempt to communicate live first and follow-up with text and/or email messages. I try to hit multiple communication formats with each team member, to help ensure the intended message is being delivered and received appropriately.

Despite this, I still have so much room to improve my communication style and technique.

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?

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.

You Should Have a Back Up Plan for the Back Up Plan

A few days ago, I powered on my laptop to start the day. I stepped away to grab some coffee while the computer went through its startup sequence. When I returned to my desk, I noticed the lights were on but the screen was dark. I did some trouble shooting, including connecting the laptop to an external monitor. The computer seemed to be okay. The screen not so much.

I did an internet search on a second computer and found out that I probably had a dead screen. I called the technical support for my computer manufacturer. They said I would need to send it in and it might take up to 10 days. Ugh. I decided to check out the big name computer repair resource. Same story. But I needed my laptop. As a stop gap, I at least needed to retrieve the files off the hard drive. It had been a while since I last backed up my hard drive. Shame on me. I wasn’t very prepared.

I bought a device to attach to my hard drive and headed home. I watched a YouTube video on removing a hard drive from my computer, which was way easier than I imagined. And before too long, I had extracted files from the hard drive and installed on flash drives and an external hard drive.

I then took my computer to the local computer repair shop. Thankfully, the repair was made within a couple days and at a reasonable cost. Plus, I gained a valuable lesson through the experience. Back up my files early and often.

But the lesson is more useful if I apply this philosophy and approach to other aspects of life. Especially for business. In fact, there is a current project right now where having a back up plan is proving very necessary.

The reality is that I don’t want to have a back up plan. And at the same time, past performance is the best indicator of future results. Taking this into consideration and not wanting to go through the experience of not being prepared, we are actively engaged in evaluating contingency solutions to support product development and manufacturing needs for a startup client. Yes, we hope that the current resources will be able to solve the design dilemmas and be able to transfer the design into production. However, I cannot go to the bank with this just yet. Too much is at stake for the startup. Frankly, too much is at stake for Creo Quality too.

So, we are developing a back up plan. And a back up plan for the back up plan. Sometimes it just makes good sense.

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.

You Can’t Use My Supplier

We’ve been working with a startup medical device company on a product development project. The device contains quite a few components, including a custom printed circuit board and several electronic components that plug into the PCB. We worked with the hardware engineer closely on the first revision of the PCBs. He recommended a manufacturing resource for turnkey PCBs. These boards were pretty good. We’ve gotten a lot of mileage, testing, etc. out of these units.

We’ve continued with development efforts with testing, identifying tweaks and refinements to the product. We have also been working very closely with the eventual contract manufacturer. The CM has been gearing up for pilot production, identifying a possible source to manufacture PCBs. The hardware engineer has identified some changes that need to be made. Changes which need to be verified before going to full or even pilot production.

So, as project manager, I thought it would make good sense to work closely with the PCB resource identified by the contract manufacturer. An introduction was made, and I began to coordinate a second development run of PCBs. I began to establish a relationship with PCB source, indicating that when the time is right, I (via the startup) would be ordering the second revision PCBs.

Apparently, as I did so, it ruffled the feathers of the CM. They got the impression that I was trying to steal their PCB supplier. Are you kidding me? The CM said that THEY needed to be the one ordering the second revision development boards. And that I needed to go through them because the PCB resource is their supplier. I got lectured by the CM–twice–about this. I explained that the PCB was not production ready and still in development. That me coordinating the build and order of the second revision boards was very much like the role I played on the first revision boards.

Somehow, though, it seems as though the CM failed to understand the similarities. And instead felt defensive and threatened. They conveyed to me that they have done the work to identify and secure the PCB supplier. Keep in mind, I have known this same supplier for several years.

Oh, and then I learned from another development resource I identified that the CM has contacted them for some additional work on other projects. Did I pitch a fit about the contract manufacturer using my supplier? Nope. Because this is what we should do. Help one another.

Rant over. For now.

The Ability to Zig Zag Through Medical Device Product Development

If you have been a part of medical device product development, there is a good chance you are somewhat familiar with the image below:

Most refer to this as the FDA Design Control waterfall diagram (the origin is actually Health Canada) and is referenced in FDA Design Control Guidance document.

Since starting my career as a product development engineer for a medical device company and my first exposure to this image, I have been fascinated by it. In many respects, the image is pretty good at showing the progression of Design Controls during product development. Many interpret and infer that Design Controls = Product Development. There is definitely a dependent relationship of sorts. Design Controls are generally part–albeit a huge part–of medical device product development. Many companies have implemented a phase approach to product development. Often times these phases coincide with the Design Control diagram shown above.

What I continue to find interesting about medical device product development and Design Controls is that we continue to express this process as a linear progression. Yes, when I write procedures for product development and Design Controls, I use phases to describe the process. But do phases really make sense?

Let’s use the image above to evaluate a little more. I interpret that in order to establish Design Inputs, I first need to establish User Needs (and so on). By a strict interpretation, you cannot finalize Design Inputs until you have first finalized User Needs.

Is this how medical device product development works in your organization? I speculate that the answer is no.

In practice, you likely have a fuzzy list of User Needs. The list is rarely complete before you start to define Design Inputs. In fact, you might even begin creating Design Outputs before you have even officially finalized the list of all User Needs.

Doesn’t it make more sense to get as much as of your medical device to Design Verification and Design Validation as quickly as possible? I speculate yes.

This type of approach is more logical but complicated by a few things, including:

  • Your procedures dictate product development phases
  • Your organization may require you to complete one phase before proceeding to the next
  • You likely do not have good tools in place to allow you to effectively manage this type of approach

But what if you did have a tool that would allow you to manage the more natural way of product development? What if you have a software solution to capture all Design Controls which provided clear, easy to follow linkage for each element in one place? Do you think this tool exists? In my experience and research, not really. At least not until now.

This is why Creo Quality is launching UniDoc. UniDoc is the collaborative way to manage design history for all your medical device projects.

It’s time to use a tool to help you manage your Design Controls and product development efforts in a more logical, efficient way. Contact us to put UniDoc in place at your company.