With Stefan Riesen (ERNI Switzerland)
In the last year and a half, Stefan was assigned a project leadership mandate in the Med Tech Industry. We have met him for an interview, and he shares his lessons with us.
Stefan, you have just returned from a mandate.
Yes, I was assigned to a project leader role with one of our customers in the MedTech Industry.
Was this your first mandate for ERNI in the MedTech Industry?
Yes and no. I moved into the project just after joining ERNI in February 2020. However, this was not my first assignment as a project leader in the MedTech Industry. So, I knew what to expect.
And were your expectations fulfilled?
For the most part, yes. The MedTech Industry is highly regulated and therefore certain paradigms don’t change that quickly. Foremost, the regulations require a structured and well-documented project execution in order to keep patient risk within acceptable limits when using a medical or diagnostic device.
That sounds easy, just follow the process and everything will be good.
In theory, that sounds easy; however, the development cycle times in the MedTech Industry are also under high pressure. The market demands better products within shorter timeframes. Also, the pandemic has had a significant impact on the market. On one hand, the demand for IVD solutions has skyrocketed, and on the other side, the supply of components, such as microcontrollers, has plummeted. This puts development and manufacturing under even more pressure, mainly regarding the development cycle time. When just giving in to the pressure, quality will suffer and put lives at risk.
Isn’t that a very serious responsibility?
Yes, it is. And that’s why it is crucial to manage a development project in a way that keeps the residual risk within the acceptable limits. That is not always easy. And although I was successful with the project, I also took away a lot of lessons for future projects.
Can you share your lessons with us?
Of course. I have four main lessons:
- Have a common scope understanding and focus on that goal
- Identify and mitigate risks as early as possible
- Integrate and test continuously
- Always look back and continuously improve
Let’s talk about the first lesson.
When under time pressure, it is important to keep the development team focused on the next required steps. In order for this to be possible, a mutual agreement and clear priorities on what shall and what shall not be implemented during the project is required. For this, a close collaboration between the R&D Team and all relevant stakeholders is crucial. The main stakeholders are the business side (including customer support), the medical science team, and the manufacturing operations. Also, the colleagues from regulatory affairs and quality assurance are not to be neglected.
These are a lot of stakeholders. How do you ensure that they are all appropriately involved?
Communicate, communicate, and communicate once more. Be transparent on where you stand and request clear answers. That is easier said than done. For this, it’s important to send out reading material prior to meetings so that everyone can prepare him/herself. Also, we established that document reviews were to be created on collaborative platforms, i.e. shared files, and every involved party could enter their comments directly into the file to be reviewed. The document management system was then only used for a formal sign-off and release of documents.
And what about “Identify and mitigate risks early”?
This point addresses both product and project execution risks. For the latter, it’s important that they are continuously gathered, monitored and updated according to the development of the project. Especially for product risks, proper involvement of all experts is crucial. Have the SW team identify potential misbehaviour of the SW; have the system engineer analyse what such a SW misbehaviour means for the system behaviour, and then have the medical science team assess what this system behaviour means for the patient. Only then is a holistic view on the risks achieved.
But the mitigation of risks usually comes at a cost.
Exactly. Therefore, a holistic view is also paramount for mitigations. For example, if a risk can be mitigated with an additional software feature or with operator training, one must ask which possibility has the better effort vs. effect ratio instead of having the decision be driven by the budget limitations of one department. After all, it’s one company that the team is working for and it might be beneficial to invest into the implementation of a feature rather than have it “fixed” in the field.
Why should you continuously integrate and test?
Also in a waterfall or V-model project setup, providing early and continuous feedback to the developers is crucial in order to achieve proper product maturity before moving to the next stage. This can be achieved through continuous integration and testing.
But testing should be done in a formal way at a specific project phase.
Yes, in a regulated environment, the formal testing phase of the final product cannot be omitted. However, nobody is preventing you from involving the testing team in the other phases of the project as well. We established that during development, we regularly made a preliminary build of the software and handed it over to the testing team for a preliminary execution of the test cases. Based on this, a) the testing team could improve the test cases, and b) give feedback to the developers so that they could make corrections before a release candidate was built. Further, the testing team was also involved in the elaboration and review of the requirements, ensuring that these were properly testable at the end.
And does this not lead to higher costs?
On the contrary. With this procedure, we achieved that only one release candidate needed to be created and formally tested before releasing the project without unacceptable risks to the patient. On the bottom line, this is more effective than having multiple V&V campaigns all associated with a higher overhead. The efficiency can be further improved by automating as much testing as possible. The Verification Team (V&V Team) has started using a UI testing framework to emulate all user interactions, uses data injection to create a known system state in the test cases, and has even installed a collaborative robot to emulate physical user interactions such as a consumable change. This allows for improvement of the regression testing and ensures that the development projects don’t introduce unwanted side effects with the changes.
And you have a fourth lesson: Always look back and continuously improve. Isn’t that a contradiction to having a clear focus?
No, here I’m speaking about collaboration and communication, not about the technical work in the project. In contrast to agile projects, a waterfall process usually only knows lessons learned milestones at the end of the project. But the world is not just black and white. Nobody prevents you from having a regular retrospective and assessing what can be improved in the project setup. We did a monthly retro and based on this we – for example – restructured the shared drive for convenience records or the structure of our regular meetings, thus improving the overall efficiency of the project. In my opinion, continuous improvement of the development collaboration is the most effective way to an efficient project execution.
Thank you for your insights. If I am interested in learning more or having my project discussed with ERNI, what can I do?
Contact us. It’s that simple.