Knowing when to turn on the design controls is a delicate balance. Design controls should be a framework - they don’t necessarily need to stifle the creative process. It doesn’t have to be restrictive.
Peter suggests that project managers should learn more about qualitative management and regulatory affairs. Make sure you know what’s good enough.
Peter provides online training on risk management, project management and design control. You can find him and learn more at gantus.com.
Memorable quotes from this episode:
“Medical device product development is far from a straight line.” - Jon Speer
“It was never intended in product management or design control to be changing technical solutions fundamentally while you’re in that process.” - Peter Sebelius
“You can’t write something down that you haven’t thought through well.” - Peter Sebelius
Transcription:
Announcer: Welcome to the Global Medical Device Podcast where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge direct from some of the world's leading medical device experts and companies.
Jon Speer: Hello this is Jon Speer, the Founder and VP of Quality and Regulatory at Greenlight.guru and you are listening to the Global Medical Device Podcast. We have found yet another brilliant mind in the medical device industry. Our guest on this episode is Peter Sebelius. Peter is the founder of gantus.com, G-A-N-T-U-S. Peter and I talk about something that's very important to probably many of you listening and that's medical device product development project management. So be sure to listen in as we talk about things like, "Can you be Lean and Agile in your product development efforts and still comply with FDA and ISO regulations?" You're gonna wanna find out by tuning in to this episode of the Global Medical Device Podcast.
Jon Speer: Hello and welcome to the Global Medical Device Podcast, this is Jon Speer, Founder and VP of Quality and Regulatory at Greenlight.guru. Today we are gonna discuss an exciting topic of medical device product development project management. Today I have a guest, Peter Sibelius. Peter is the founder of gantus.com and works exclusively with medical device product development and associated areas. Peter is a certified project manager and has vast experience as a manager in the medical device industry, and as an esteemed project management and design control trainer and is a member of the Joint Working Groups on ISO 13485 and ISO 14971, very important standards for our industry. Peter knows his stuff. Peter works with making product development compliant and Lean on the same time. So Peter, welcome to the program.
Peter Sebelius: Thanks, Jon. Thanks for having me.
Jon Speer: Oh, absolutely. Peter, you and I have had a chance to have some really great conversations over... Well, I guess we've known each other now through Skype. You're calling in today from Sweden, I'm in the US, but we've gotten to know each other decently well, have some good conversations, and we have a common passion and that's medical device product development.
Peter Sebelius: True. Yeah, I definitely... We definitely share that passion.
Jon Speer: Peter. I think I first discovered you in my search for content on ISO 14971 and I was looking for a video, actually, to see if anybody had actually tried to describe this in a succinct but informational format, and I came across your video on ISO 14971 and I'm gonna tell you it's the best video I've ever seen on medical device risk management, by far and a way, you do such a great job on that.
Peter Sebelius: Thank you, Jon. Thank you. Thank you.
Jon Speer: Alright, so we're gonna talk about medical device product development and specifically project management. And I wanna try to start off with something first that can help people think about this. We hear all these things about Lean product development or Agile methodology, and so on and so forth. And I think that's used... That terminology or that philosophy is pretty popular, certainly with software development these days, but there's this opinion that I cannot be Lean and Agile with my product development activities, and also compliant to FDA and 13485 at the same time. So, I'm gonna throw that out there and get your take on that topic. Can you be Lean and compliant at the same time?
Peter Sebelius: Well thanks for that question, Jon. I definitely think you can, but definitely many companies are also struggling with this because for several reasons actually. It seems many times that the more documents you have, the better it is, and that's certainly not true and people have various challenges with this monster, basically, that they consider the 21 CFR 820 to be, or the ISO 13485, for that matter. But you can do it. And I think there are many ways around these problems, of course, but you can be Lean for sure, and I'm hoping that we can discuss some of these things and I'm looking forward to learn from you, what you think of them.
Jon Speer: Yeah, I tend to agree. I think... I'll take you back. I won't go through every step along my journey but I'll take you back to some of the highlights in my past 17 plus years in this industry, and I... When I first started it was 1998 and although design controls were new at that time, newer at the time, they'd been a couple years old, but it was kind of a new philosophy for many of my colleagues and I didn't know any different. But I read the regulations, I saw the famous waterfall design control diagram and I'm thinking, "Oh medical device product development is a straight line." And it didn't take long, but I realized, "No medical device product development is far from a straight line." And so you've got to try to figure out with any project, "What can I do, what do I know, what can I take from start to finish as quickly as possible?" Because how many times have you worked on a project where that deadline was given to you before you even started the project? And so you gotta figure out ways to be quick and nimble but it is a struggle, because if I read the regulations literally, I can very quickly determine, "Oh this says I need to do my user needs and then when I'm done with my user needs, then I go through a designer view, and then I do design inputs and do those and so on." So what are some thoughts and ideas that you have about ways to use that Lean and Agile methodology, but keep the controls in place to satisfy the regulatory nature?"
Peter Sebelius: Yeah. That's a good question and I think that there are two things that I would like to mention in that context and one of the things is actually not to have the controls. Now that may sound provocative, but one mistake that many companies do is that they actually try to apply all the design control principles way too early, which means that you're trying to set up both the project and your specifications and have them all approved without really knowing exactly what the product is going to be like. Now, to me, that is to apply those principles too early because it was never intended, in project management or design control for that matter, to be changing technical solutions fundamentally while you're in that process. So the solution to that is to understand and be able to use feasibility studies or concept studies or pre-studies that are actually not under design control that are maybe a much more appropriate way of organizing work when it's fundamentally changing all the time.
Peter Sebelius: So that would be one of the keys to sort of wait a little longer before turning on all the design controls. It's important then of course to be clear about the purpose of those things. I'm not saying you should have a finished product and then finish the product in two weeks at the end, which also happens for some companies, but that's of course not the intention, but to find the right balance. And I sometimes say I believe a famous politician said you have to have a gut feeling sometimes. You have to have that gut feeling when to turn on the design controls not too early and not too late.
Jon Speer: Alright, so let's talk about turning on the design controls a bit. I think that's a term or a phrase that's often thrown out in this industry and I'm not sure everybody has a clear image, or maybe everybody has a clear image, I just think the image is somewhat restrictive at times. I still come across people, even in 2016, who think of design controls and they automatically in their minds think restrictive. And I think that term design control has is a misnomer for some people because they look at this, "When I enter design control now I suddenly can't be innovative and creative." I struggle with that 'cause I think design control should be a framework and when I try to teach and explain that topic and I know you do a lot of training on design controls and risk and related topics but when I try to explain this to people, it's like, "Use design control as it's your friend. Realize that it's a tool, it's a methodology to try to help you capture the essence of your device, to prove that it's safe and effective for your intended use. It's not restrictive."
Peter Sebelius: And I agree with you. When I refer to it as when you start your design controls and make the project more formalized, it's of course still possible to change things, it's just that it's gonna take more time and more resources to do that. And when I refer to that turn on design control, I mean, when you have approved your first version for the first real effective version of the design and development plan and you have approved your design and development inputs. That to me would be now we are under design control. And that's, of course, not a perfectly black and white situation. You start moving into that. But that also brings me to the other reason why this sometimes is a challenging area, and that is that people are worried about not having everything defined. And this is why I always tell manufacturers, "You have to be able to use TBDs," as I call them, or "to be determined", it's perfectly okay to write a requirement to say, "Well, we think it's gonna be like this, but we don't know the exact amount or the weight or that dimension, but we think there's gonna be this requirement." And you should use TBDs and make sure you update that as you go along because what otherwise happens is that you just keep on waiting on having all the details. And to be honest, you won't have that until you've basically done your last verification.
Jon Speer: Yeah. Yeah I like the TBD concept. The way my mind works is I wanna have a place holder. I wanna have a reminder so I don't forget it. Like you say, I don't always know the details, but I know it's gotta be some shape, size or have some sort of characteristic in this particular area, and if I can capture that, and define that as I evolve my design and prototype and so on, I think that's a great suggestion for people. Alright, so you mentioned something a moment ago that I hear a lot, and actually experience a lot with some of the customers that I work with, and that is they're gonna do all of the work, all the inputs, the outputs, the verification almost the validation activities, but they're not gonna document it, and they're gonna wait until they have the, quote, perfect product or the product that they're ready to go to production with, and then they're gonna try to do a mad dash, they're gonna catch up all the design controls and so in that case, they're just doing design controls as a check box. And I just like, aah... It just agitates me. So, I'm sure you've had some similar experiences.
Peter Sebelius: Sure. Sure, and there are two different... I think there are two different views on that. One is that people... Well, it all comes down to what I think what documentation is to you and I think the right way to look at all those documents that people often speak negatively about is that... Well, the good thing with them is that they force you to think because what you cannot write down is something that you probably haven't thought through well. And this is the beauty of that, I think, when you start making your requirement specifications and plans. 80% of that is probably a no brainer to write down, but then you have those 20% that you really need to think hard to figure out and that's a good thing that you have to think hard because otherwise, you're gonna run into problems.
Peter Sebelius: So going through this process properly and having that as the framework, as you say, I think is a really, really good idea. Then people sometimes wait with signing all the documents. And I think that from one point of view, I can understand it, because if you have a system which is really, really difficult when it comes to approvals and how to implement and make documents effective, I can understand that. But if you have a strong desire not to sign and get your documents approved early, that's usually a symptom that your document control procedures are bad. And people tell me that we don't want to change anything because it's so difficult. Yeah, but then you need to look at your procedure. It's not intended to be that difficult [11:51] ____ there is something wrong then.
Jon Speer: Right. Alright, so Peter we spent a fair amount of time talking about design control today and I led off our discussion, saying that it was gonna be about medical device product development project management. So some may be wondering, "Wait a minute guys, I thought you were gonna talk about project management and why are you spending all this time talking about design control?" So share with me your opinion, your thoughts.
Peter Sebelius: That's a good comment. Thanks for keeping us on track. The good thing here, I think is... I can tell you that when I came to the medical device industry in 1999, almost... Almost when you started out working with this, I was very much into project management, I was reading every book there was on the topic and I came to...
Jon Speer: Me too.
Peter Sebelius: Medical devices from the defense industry, which has always been really good at structured product development and the US Department of Defense has authored lots of really nice documents that talks about this and your military standards as well, from US. So I was all all into this and then I came to a medical device company, started looking at design controls and I thought to myself, "Well, this is sort of similar but they don't have the same names." And I came to it with project management plans, or project plans, and I saw that there was a requirement for design and development plans. And I started asking myself, "So what's the difference?" And basically, when you boil it down, the only difference is that design controls won't require you to consider financial aspects of how you develop a product. Other than that they are so similar, and project management and design controls are basically best practices on how to run product development. There might be 5-10% in design controls that you feel, "Why am I doing this?" Yeah, okay, well, we'll just have to live with them. But the 90% those are things that makes perfect sense from every point of view, in doing most product development projects. So these are very, very tightly linked to each other.
Jon Speer: Yeah, thank you for sharing that. And I can remember very distinct I'll say were discussions, but they were probably more like arguments in my career, where there was this topic of the product development process versus design controls and how they're separate things and you need to keep them distinct, and you have to have a firm line between the two, because there's this fear, or conventional wisdom, whatever you wanna label it as, that FDA if they come in and do an inspection, or you get an ISO audit, that they only get to see the design control stuff and all the other stuff, that's our secret sauce, that's our business process and so on. And I think people get hung up on that.
Peter Sebelius: Yeah, I agree with you. The major difference, you would find, for example, in the design and development plan compared to the project plan is just that the budget is missing. Or your cost performance baseline. I usually... I refer to the guide... A Guide for the Project Management Body of Knowledge, which is an excellent book on the topic of project management. I would say it's fairly boring because there are not many color pictures in it, but it's like the work on project management in the world, there is nothing in it... Or there's nothing in project management that is not in that book, basically. And so I refer to that one. And when you compare that, when I do my project management courses for medical device product development, you can see that all the elements that are in design control, you will find them in the PMBOK. They might have slightly different names, but it's all in there, so they really tie together. And speaking about this worry about having the budget and the financial things available to the auditor. Well, I usually tell people, "Well, put in a reference to the budget, you might not want to list it in your design and development plan, but just make a reference. And if there is an auditor, that pursues that line of auditing... " I've never ever seen that happen.
Jon Speer: Right?
Peter Sebelius: "And then you still have everything in one place. It's transparent to everyone. You can see why you have that. It's not two different worlds living next to each other. It's one integral approach to developing a product in a project form."
Jon Speer: Right, those are great tips. So Peter if I'm developing a new medical device and maybe... Well, it doesn't matter if I'm brand new to this industry or I've been doing this for 1,000 years, what are some key tips and pointers that you can give me as a product development project manager, what are some... Maybe a few tips that you can provide me, to help me better understand how to leverage Lean methodology in my efforts, and not get too hung up on is this business or design control? Help me kinda wrap my head around that.
Peter Sebelius: I think that one of the things that project managers in the medical device industry should be doing is to learn more about qualitative management and regulatory affairs, basically. I once had a student on one of my courses who said, "Well I'm here because I want to know the rules, so I know how to bend them." And that's maybe a quite cynical approach to it. But still there are so many project managers that are only doing project management and then they get a pushback from maybe a QA department or regulatory affairs saying, "No, it should be like this and that." And that's not always true. So having your own knowledge and confidence in yourself, knowing that this is going to be sufficient, is a very, very valuable competence to have, I think.
Jon Speer: Yeah.
Peter Sebelius: So that would be one advice. Make sure you as a project manager or someone you have really close to you in your project knows what's good enough.
Jon Speer: Right, right. Yeah, I think that's a key tip. I can remember that my first stop in this industry, I worked for a larger company and there was a lot of misconceptions, I would say, with how we handle medical device product development. The first misconception at that company was because you are an engineer that means you're gonna be a good project manager. The second misconception that was in place at that organization was that product development is an engineering issue, it's not an enterprise-wide issue. So I don't know if you wanna comment on either one of those two misconceptions.
Peter Sebelius: Well, someone told me that the more complex the project is, the less you need an engineer to manage it, and I think that's true.
Jon Speer: Yeah. I mean, engineers... Let's use the engineering mind to solve technical issues. And don't mishear me, I know plenty of engineers who are very good project managers, but sometimes that engineering skill set is not necessarily what's gonna lend itself well to product development project management.
Peter Sebelius: I would agree, I would agree. Yeah, yeah. And picking up on some of the advice here because I wanted to add one more thing. You said, what should one think of if you want to develop products and be successful with that? And this might be a thing, which is not that easy to change and I know you've been working a lot with this in your product and your system, the quality management system that you're offering, and that is to get the document controls right.
Jon Speer: Yes.
Peter Sebelius: And what I see companies doing mistakes with over and over and over again, is that they have way too many signatures on their documents. And one should keep in mind that this is something that we almost entirely choose ourselves as manufacturers. I would say that there are some documents where we would want to have QA involvement, or at least ensure that the information is made available to management so that they can make the right decisions, but for those few exceptions all the rest is up to ourselves to determine who should be reviewing and approving. And when you get that document with eight signatures on the front page, it's taken forever to get those signatures. Probably it was just the first or the last or no person on that list that actually read the document.
Jon Speer: Yeah. Everybody on there says, "Well, the person before me already read it so I don't have to."
Peter Sebelius: Yeah. Or I think that the rest of the people that will be signing will read it. So I might... You know. That doesn't work well, simply put, and I'd rather have one or... One reviewer signing it if they are to sign it at all, and then one approver, and I know that I can hold that person responsible for that signature. We had a saying in the military when I was doing my military service that a shared responsibility is no responsibility.
Jon Speer: Right.
Peter Sebelius: You have eight people, that's just 12.5% responsibility, isn't it?
Jon Speer: Yeah. Well, the same philosophy is true if you're trying to make a decision by consensus, chances of you making a decision will be very, very, very small. You're right. Alright, so Peter, I think we've done a good job of trying to provide some tips and pointers, or at least getting people thinking about some key concepts between design control and product development process, how really they are one and the same and trying to get people to think about Lean, Agile methodologies as you go through that process. And I'm sure that we can talk about this for a lot longer than our time today, but I do want to... But I want you to share a little bit about what you do at Gantus and some of the training programs that you offer and how people can find you and your programs.
Peter Sebelius: Yeah, thanks, Jon. So I provide online training on risk management, which is I guess a topic in itself that we could be spending a lot of time on. But I do have an online course for risk management for medical devices in ISO 14971 which is quite nice because people can take it anytime they like, and they appreciate that. And also training courses on design control and project management combined with product development in the medical device industry. So I do company internal courses and open courses, mainly in Northern Europe, but also in US during this fall. And then, of course, I try to help out reviewing and optimizing the processes for companies that are medical device manufacturers trying to solve some of the problems that we've been talking about, where they have those eight, 10 signatures and they're wondering why are we doing this, when they start feeling it takes an awful lot of time, there's probably something wrong in our process. That's a quite common assignment for me to help out with those procedures or processes.
Jon Speer: Very good. Well, I want you all to do a search for Peter Sebelius, S-E-B-E-L-I-U-S, Gantus, G-A-N-T-U-S. And Peter the website for Gantus again is, can you remind us?
Peter Sebelius: That's gantus.com.
Jon Speer: Gantus.com. So when you search for that I want you to spend that few minutes and watch his video on ISO 14971 risk management; it's good stuff, it really is. So, Peter, thank you for being our guest today, I enjoy, as always, having a conversation with you and look forward to our next. We've got a couple of other topics that we've been kinda bouncing back and forth. So look for upcoming podcasts real soon with Peter on these kinds of topics.
Peter Sebelius: Thank you, Jon, I enjoyed having this talk with you, looking forward to the next time.
Jon Speer: Alright, well great. As Peter mentioned a couple of times during today, that it's important to do some logic when you're doing your quality system and capturing your design controls, and risk management. And I think that that's so important, especially today, now more than ever, you do need to address the quality system components, you do need to capture your design controls, design history file and risk management activities, of course, and what better way to do that than to use a software solution that's designed specifically for the medical device industry. So yeah, that's right, check out Greenlight.guru. That is the domain. Greenlight.guru has developed a software solution that helps managing your documents, your records, your quality system, your design controls, your risk management, all those things that you need to do to meet FDA 21 CFR Part 820 and ISO 13485 and ISO 14971, as easy as possible. Again, this has been Jon Speer your host, and the Founder and VP of Quality and Regulatory at Greenlight.guru and this has been the Global Medical Device Podcast.
About The Global Medical Device Podcast:
![medical_device_podcast]()
The Global Medical Device Podcast powered by Greenlight Guru is where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge, direct from some of the world's leading medical device experts and companies.
Like this episode? Subscribe today on iTunes or SoundCloud.
