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.

Get UniDoc. Simplify Medical Device Documentation.

Do your engineers hate documentation?

Engineers don’t like documentation. Yet, we all know that documentation is an expensive, time consuming, and vital component to medical device product development.

UniDoc helps make your life better by providing a clear, easy to use single source process to navigate from the beginning of a project to capture of user needs, through a regulatory submission to gain market clearance, until a project is transferred from design and development into production, and throughout the entire lifecycle of the product.

How Does UniDoc Make My Life Better?

Do you need a single place to store engineering, regulatory, and quality documents?

UniDoc also allows users from other functional areas, such as Regulatory Affairs and Quality Assurance, real-time, up-to-date access to medical device product development documentation. The features within UniDoc help make compiling regulatory submissions and device master records that much easier and faster. Plus, all the content pertaining to your medical devices is input, managed, and maintained in a single solution–UniDoc.

UniDoc is used during product development to capture Design Control content, meeting FDA regulations and ISO 13485 requirements. UniDoc automatically compiles regulatory submissions, such as FDA 510(k) submission. UniDoc establishes a product Device Master Record.

Do you need to improve your time to market?

UniDoc provides a solution that seamlessly integrates Engineering, Product Development, Regulatory, and Quality documentation, records, and files for medical device products. The result means getting to market faster and cheaper while reducing risk.

Contact Us Today!

Are you interested in learning more?

You can read more about UniDoc. Our team is ready to implement this solution at your company now.

Click Here To Send Us A Message

You’re Late and It’s Wrong

Have you ever managed a project where you felt the project schedule was meaningless and not a concern of the team members? Lately, I have this feeling on a medical product development project I’m managing. We have plenty of things to address on this project with a handful of core team members working on various aspects. When an issue arises needing attention, we have been pretty good about meeting and discussing the issue, trying to identify the root cause. Upon the conclusion of the discussion, one team member takes responsibility for completing the task.

When asked for when the task will be done, the team member typically thinks about the effort involved and provides an estimate. I make a note of it and then record the date on the open issues / action items log. In the days ahead, I keep tabs on the task. I’m reassured that all is moving along as planned and that the due date should not be a problem.

And then the due date for the task arrives. The team member assigned to the item then shares that things have come up or something wasn’t delivered or some other excuse. I’m told that rest assured, it will only be a couple days more. Usually, that second guess for task completion happens. Unfortunately, the work effort and solution provided has seldom addressed the issue.

So frustrating!

My advice:

  • Don’t provide a due date on a task assigned to you unless you have high confidence about the effort required and your ability to complete it
  • Not providing a due date is not an option, though, for most projects. If it takes you an extra day to fully understand the scope of the task, request this extra day from your project manager rather than haphazardly provide a date on the spot.
  • Be sure you complete the task correctly addressing the issue.
  • If you are going to be late with the completion of the task, you better make sure you did the job correctly.

 

Should Have Held a Design Review

Have you ever had one of those moments during your medical device product development efforts when you said “we should have held a design review”? Unfortunately, I’ve found myself making this exact statement a couple times during the past couple weeks.

Instead, we chose to push forward. Face to face discussions, email correspondence, and phone calls with the various team members suggested things were progressing just fine. The medical device being developed has quite a few components: mechanical, electronic hardware, firmware, disposables, etc. Our product development approach has been largely divide and conquer and working in parallel. There have been a few touch points when each of the various components needed to come together for overall review and testing. However, we have pushed and pushed each of the individual efforts assuming this would be better for the aggressive project schedule.

Then came time to merge mechanical, hardware, and firmware pieces to conduct some design verification and simulated use testing. We pushed forward with this phase without getting the entire team together for a formal Design Review. And it kind of hasn’t been working out the way I would like. In fact, it has been a little bit of a mini-disaster of sorts. The device isn’t performing exactly as we had hoped. Rather than the team figuring out how to work together to resolve the issues, there has been a lot of finger pointing.

And as project manager, like it or not, I own that. This is my responsibility to address.

The silver lining is that holding a Design Review still had merit. So I got the team together to discuss and review the important and critical issues. Surprise, it actually helped–A LOT! The value of having a team meet together face to face should not be underestimated. I know this. I know this. But damnit, the schedule…

Okay, no more excuses. Lesson learned (again). This time, I’ll err the other way. I’d rather have too many face to face discussions and Design Reviews versus not enough. This is especially important at key stages during the medical device product development process. Design Reviews should precede the start of major milestones. Design Reviews should also happen upon completion of these milestones. Include the entire core team in all Design Reviews, even if the particular topic seemingly has little to do with some of the resources. Project team members should always have the opportunity to gain knowledge about the project. Plus, the other added benefit to this in my experience generally speaking, is that the more opportunities team members have to interact with one another face to face, the greater the bonds and level of trust.

Start. Stop. Repeat.

The other day an issue on a medical device product development project surfaced. We had a part that was leaking during bench testing. And this was a topic that had been identified and I thought addressed and closed for quite some time. But it reared its ugly head again. I didn’t understand why so I scheduled a meeting with the engineer involved with the design and assembly of this component. I’m sure you can imagine that his first reaction was defensiveness. When someone gets so defensive so quickly, it raises a bit of a flag.

Regardless, we had leaking parts. Parts that aren’t supposed to leak. During our discussion and examination, one of the engineer’s bosses walked by and engaged in the discussion for a few moments. His parting words were “. . .  that’s product development . . .” as he tossed his hands up and shrugged his shoulders. Really? That’s the explanation for this issue?

Okay, yes I do know this is product development. And I realize that if we need something was going to be an issue, then we would plan for it and address it. So of course when we first dealt with leaking parts and addressed it, all of us on the project team assumed that this issue was complete and checked off. There are plenty of other items and tasks on this project requiring attention. When we check something off, I can’t even begin to explain how counterproductive this is. Not to mention how this impacts the project schedule.

I’m only sharing the short story of one component issue that was once checked off the list as “done” only to come back. There have been a few other components and tasks like this on this project which have had similar rebirths. Yes, the schedule suffers terribly when these situations occur. Maybe worse, though, is that the confidence of the teams members and confidence in the team members is shaken.

As project manager, I need to do my best to understand the root cause and to help resolve as quickly as possible so that the next items are not impacted. For this project, I think there are a couple of underlying offenders affecting quality of work effort:

  • Speed
  • Micromanagement
  • Communication
Speed has been hurting us since the origin of this current project team. The medical device product development efforts for this endeavor began with slightly different players than what the current team make up is. We lost a little bit of time early on in the project for a litany of reasons and have failed to recover any semblance of schedule buffer. You might also argue that the initial target for completing the project might have been overly aggressive. I won’t go into that in this post except to say product developers and suppliers in the medical device industry have grown to accustomed to long lead times; there has to be a better way (this is a whole other post topic I need to dive into soon). Without a meaningful buffer, the schedule pressure has been felt by most team members. Dates have been promised and missed so many, many times!
Because dates are missed, the startup CEO feels compelled to chime in and help manage the project from time to time. In doing so, he is very forward and direct. He has stressed time and time again dates. This added stress and pressure is felt by the team. And I don’t think it has resulted in more timely results. Actually, I think it has probably done the opposite. Tasks take longer when they are being micromanaged. People are hesitant to make decisions for fear of retribution. So tasks get to a point and wait for the CEO to make the final call.
Communication is ALWAYS a topic that can be improved within every project. Communication on this effort have varied. Some days and weeks are very good. Other times not so much. And as project manager, I need to be doing a better job driving communications among the team.
Anyway, I have just a little bit of time to reflect on the project and make tweaks. The schedule was not put on hold during my reflection period. So now is time to take actions to get our efforts back on track. Yes, this is medical device product development and there will be other things that will come up. But we have to get better as ensuring a task does not need to be repeated once we check it off our list as done.