Engineering Precision in Medical Device Project Management

Engineering Precision in Medical Device Project Management
Medical Device Project Management Operations are responsible for ensuring that unnecessary delays, and the resulting costs, are avoided. Optimizing the project plan, budget, and improving work efficiency – that’s the real-life story. Every new project should begin with a well-structured plan, something that stakeholders fully understand. People of PMO also make sure that all resources are allocated efficiently, preventing the waste of both team potential and materials. I decided to talk with Kamil Bobrowski – Consonance Head of PMO to find out where the drill is.

 

In medical device project management: what do you do on a daily basis as a Head of PMO?

Hi Kamil, thank you for sharing your time and expertise.

Hi, thank you for the opportunity. I focus on ensuring that the project we are working on stays on schedule and follows the guidelines. I also work to make the process easier on our side, particularly for engineers, by making sure they have everything they need to do their job. On the other hand, I try to stay as close to the client as possible, keeping the parties informed about the progress, gathering feedback, and, if possible, implementing changes in the development process based on external input.

How do you optimize the project execution to ensure that everyone knows what they are doing and how?

This is where Consonance’s approach comes into play, which is to start every project with a technical feasibility study. This allows us to identify from the very beginning what areas we need to cover and what challenges are associated with each of them. We try to plan as thoroughly as possible in advance so as not to be surprised halfway through the project by something that turns out to be completely different from what we assumed, for example, regulations requiring specific operational parameters of the device.

By first understanding what the device is for and how it will be used, we know what regulatory requirements need to be met. This preparation helps us avoid, figuratively speaking, wringing our hands in the middle of the project because we hadn’t considered something.

Does it happen that unexpected problems arise in such cases?

This happens quite often, especially when the client who comes to us has never worked on a medical device before. They start picking apart the work, doing it in a standard Agile way, using sprints, adding functionalities we are building. Suddenly, they reach a point where something kind of works, but not in the way the standards require. It turns out that what has been built can’t be used as a medical device.

Agile methodology doesn’t necessarily work well with medical device project management. Could you explain why?

I would compare it to constructing a building. Once you have built six floors of a ten-story building, it is difficult to change the requirements and suddenly move the balconies to the other side. It’s the same here – when we design a PCB (Printed Circuit Board) with specific functionalities, we can’t introduce changes quickly and easily as in software, where Agile is frequently used. We often have to redesign the entire PCB, use different components, and change the software. That is why we work more in the Waterfall model, with slightly longer stages. During each stage, there are no changes to the requirements. We have a clearly defined outcome, and we aim for that result.

Do significant delays ever occur? If so, how often??

These days, significant delays do not happen as much. They were quite noticeable during COVID as the global supply chain was disrupted. Lead times for components often exceeded fifty weeks. On the other hand, transfering a prototype to production with a third party BOM (bill of materials) can launch a series of unfortunate events resulting in component shortages or some extra negotiations with vendors.

When delays like that occur, how do you manage the situation?

The first step is to research the market and assess the risk. If we see that certain components are available, or the delivery schedule to distributors is stable, we know we can rely on these parts because any surprises are unlikely to occur.

In critical situations such as the pandemic, it was impossible to predict because manufacturers shifted their production capacity to specific areas to stay competitive. On our end, besides focusing on component availability, we also need to take into account their lifecycle. The process of designing a medical device does not take three months – depending on the complexity of the product, it might take several years . So we need to be sure that what we start now will still be available in five years or more. This prevents a situation in which we complete the entire R&D and certification process, commercialize the product, and 2-3 years later we face component shortages.

Medical device electronic engineers are partners for PMO

Medical device electronic engineers are partners for PMO

Your role key aspect is: working with the team, the client, or the subcontractors?

Mostly? Communication, and that applies to every area. You have to gather all the information, organize it into something meaningful, and implement it efficiently.

While preparing for the interview, I found out you have an engineering degree. Who do you think is easier to communicate with: someone responsible for the technical side or a project manager?

It depends. Often, especially in the case of the startups we work with, there is someone technical on the client side, someone who knows, for example, the entire signal processing side.. That is the case with one of our current clients. This person is not a PM, but a team member. Because they’re there, it is easy to explain our actions and why we’re doing something a certain way. In such a case, there is no fear on the client’s side about the technical aspect, because they didn’t just hear something vaguely and have no idea what it means.

When we talk to a technical person, we can explain at a low level of abstraction – very close to the device – why we are doing something and what results it produces. If we get incorrect results, we can easily explain our observations, because that person understands the technical language. However, if the client isn’t technical, the issue becomes whether it will work or not.

Your previous experience as an electronics engineer. Is it helpful today? Apart from understanding the technical aspects of what you’re managing, did it offer any other advantages?

I believe that this significantly shortens the communication path and the process of establishing certain things. When a client asks me something, I know exactly what they are asking about, thanks to my education. I can sort it out in my head – whether it makes sense and if we should try doing it that way or not.

I’m also able to immediately explain it to the engineering team, and there’s no back-and-forth of me saying, “I’ll get back to you after I consult with someone”. That way, something that I can handle in 15 minutes over the phone, even without knowing the technical details, would take days. I think it is an issue because it reduces efficiency.

Do you think transitioning from one position to another was difficult?

I had to learn everything for sure, especially about communication and management, where not everyone thinks the way I do. I interact with a wide range of people, each of them looking at the project from a different perspective – someone handles the business side, someone else is a doctor who will use the product, and yet another person is responsible for something completely different. Everyone has various things in mind and a different approach to work. Some people want to be closely involved in the project, while others don’t and prefer a call every three months to check on progress.

There are different personalities, and it took me the longest to learn how to deal with them – and I’m still learning. This also applies to the team. We have different ways of communicating what needs to be done. It’s the same with feedback on whether we are happy with the work or not. In short, that was probably the hardest part: transitioning from individual work at a computer to managing many people on both sides. And then there are suppliers with whom we sometimes have to negotiate terms.

So human interactions play the biggest role here.

Yes, people are the biggest variable in this whole process.

Do you think your engineering background makes it easier to communicate with the team and plan task timelines?

Being an engineer helps me estimate the schedule and timeline more accurately. I know what is necessary to deliver a whole milestone or task. If we take into consideration that some milestones require additional testing, workstations preparation or tool development – it’s easier if you understand each step required to come with deliverables.

I would not say I’m a controlling person, because we have a lot of trust and a shared goal within the team. No one wants to unnecessarily extend the project timeline – everyone wants to get it done as quickly as possible. But we often want to see results as soon as possible because the projects we work on bring us a lot of satisfaction and joy.

Finally, could you explain how you ensure that everyone in the team stays up to date?

I use a variety of tools. First of all, we try not to generate redundant meetings. That is something that’s unfortunately common in other places. We use a Kanban board during work, where everyone can see what is happening, and we keep each other informed in real-time. This ensures that even if someone returns from vacation after a week, they can quickly catch up on what happened.

We also regularly update the client on progress, and the team also has access to this information, so there is a mutual understanding of where we are on the roadmap. That way, if I regularly check the progress of tasks and see that nothing is happening, or no one is informing me, it’s my role to find out if there is a problem. If so, I project it onto the board so the rest of the team is aware of it.

For some projects, we hold more frequent short status meetings. This happens in projects with fast changes, where one day’s work can disrupt another person’s work. For example, changes in hardware affect what goes into the software, which in turn affects the product’s casing. In such cases, we stay very close to each other.

Do you struggle with non-optimized R&D schedules? Don’t waste your time on unnecessary hurdles & expenses. Work with a company where engineers do Project Management. Write to us, you’re kindly invited!
Magdalena Sroka Content Writer Consonance
Magdalena Sroka
Content Writer
LinkedIn
Share