This episode of the Global Medical Device Podcast features a compelling conversation with Perry Parendo, a seasoned expert in product development and project management within the MedTech sector. Host Etienne Nichols and Perry delve into the challenges and opportunities facing medical device development, emphasizing the critical role of agile practices, risk management, and the necessity for a patient-focused approach. The discussion sheds light on how companies can navigate regulatory landscapes, manage project risks, and drive innovation to enhance patient care.
Key Timestamps:
Quotes:
Takeaways
Insights on MedTech Trends:
Practical Tips for Listeners:
Questions for Future Developments:
References:
Questions for the Audience:
We're eager to hear your thoughts on this episode and your suggestions for future topics. Please share your feedback and leave us a review on iTunes!
For in-depth discussions and questions, email us at podcast@greenlight.guru
Sponsors:
This episode is brought to you by Greenlight Guru, the only quality management system (QMS) and electronic data capture (EDC) software designed specifically for the medical device industry. Make your product development process smoother, faster, and compliant with Greenlight Guru. Discover the difference at www.greenlight.guru
Perry Parendo: Theres waterfall, theres agile, theres Toyota, theres set based design, and theres APQP in the automotive industry. Theres huge groups of concepts out there and theyre really, they can be different, but they can have a lot of carryover between each other. So in my defense, life, you may argue that that was a waterfall look, but were actually doing some agile practices. We didnt call it that, but we had a chief engineer too, and that was a Toyota thing. They're all a blend. There's no organization that's doing purely the theoretical of any one of those processes. And yet I talked to company after company, wow, we need to do better with product development. So we're going to implement this new process. In the back of my mind I go, it's going to be a waste of time and money and it's going to frustrate your team. They're going to do the same thing they're doing today, just with a different title and a different set of meetings.
Etienne Nichols: 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.
Perry Parendo: In the world of medical devices, time is usually of the essence. But here's the problem. Traditional product development processes are usually the slowest molasses. They cause delays and they're headaches. For companies like yours, Greenlight Guru is the ultimate solution for Medtech's biggest challenge. You may be facing lengthy development cycles that drain your resources and hinder progress, but we streamline the entire product development journey. We make it faster, we make it more efficient and less prone to hiccups. By centralizing your data management, automating your workflows, and allowing real time collaboration. It's all here. It's designed to propel your projects forward. And guess what? Regulatory compliance is built right in. It reduces the risk of costly revisions and ensuring you stay on track. With Greenlight guru, you're not just developing products, you're accelerating progress, making a difference when it matters most. Don't let inefficiency hold you back. Embrace innovation with Greenlight guru.
Etienne Nichols: Go to www.
Perry Parendo: Dot Greenlight dot guru to learn more.
Perry Parendo: Hey everyone.
neral Motors Research Labs in:Perry Parendo: Welcome. Yeah, I appreciate the opportunity to be involved with this and tian and just like you say, share what I can with the community and see where, see where it can help out.
Etienne Nichols: We met at MD and West earlier this year, and I remember what struck me was we were talking about project management and specifically in the medical device world, and we just both sort of, we shake our head at the project, at the state of project management in Medtech. Now I have a PMP, so I like to think that I know something, but at the same time, I learned my project management in the medical device world. So you've been in other industries. So I'd love to hear what your experiences are outside medical device, but wherever you'd like to start, I'd love to hear it.
Perry Parendo: Doctor Justin, you know, one of the things with medical device, obviously with the patient impact, you know, it's crucial for the government and FDA to kind of control things and make sure we're doing the right things. And yet so many companies are so focused on compliance versus actually delivering a project. And so there's a lot of patient risk, and there's a lot of things like that that are important, but that tends to almost overly focus the teams that way versus really thinking how to, how do we assemble a team, manage a project, and deliver basically on time? And so a lot of that, I think we're just, so companies can get so wrapped up with FDA expectations, they don't think beyond just basically being compliant. And so I've found that kind of a limitation with companies I've either worked for or I consulted with over the years.
Etienne Nichols: I can certainly see that as well. I can, I can distinctly remember being in project meeting, you know, the conference room meeting where we talk about all the different requirements that we're trying to meet. And someone may say, hey, we, it would be really nice if we did this. And in fact, maybe they even say, we need to do this thing. But someone identifies that, it's just gold plating, you know, and we're, but it becomes something of a need because we feel like, well, if we're going to really pursue a quality product, we need to do this, this and this, and it just seems to never end. I'm curious about your experience and how, how do we, like you said, deliver that project on time? Or is it even possible in the medical device world?
Perry Parendo: It's certainly possible. You know, I think it's really understanding the requirements, the source of the requirements, the priorities between them, and deciding basically on day one what's critical and what's nice to have. And if it's a nice to have that's delaying things. It needs to disappear for now. Get something out there. You can always improve the product or make some changes later. But, yeah, I've seen, and this isn't just medical advice, but I see a lot of companies that are doing the gold plating. That's a common phrase for sure. And, yeah, that would, I think it's hard to argue not to do something that might be beneficial to the patient. You know, there's kind of a human reaction of, well, that if you don't want that, don't you really care about the patient's health? And it's like, that's not the point. It's, this is large, a larger step forward. Let's do this part. The incremental pieces. Yeah, be nice, but let's get the big, big chunk out there today and get approved and in place and then move on from there.
Etienne Nichols: The word you use there is, it's hard to argue with something that might benefit the patient, but let's focus on what we know will benefit the patient. Maybe that's part of the distinction.
Perry Parendo: Yeah, no, that's a, that's a good observation, because I've seen sometimes new products are released, and I won't say who it was for sure, but, you know, a company is adding these new features, then you talk around to some docs and they go, we don't use those features. You know, they're, they're nice. They might be beneficial, but we got to get people through the process here. We got to get the device with patience. And that's our focus, not tuning them to get an extra 1% or 3% or whatever it might be out of the product. And you can't blame them for that, but it makes some of the incremental improvements not as motivated to work on.
Etienne Nichols: Yeah. So those two things that you already talked about, and it's just a few minutes that we've already spoken that are specific to medtech are those regulations that are kind of inherent. You have to have those regulations in place. So compliance is, is an added complexity. But the second thing is we're, we also focus on the patient and sometimes that can slow us down because like you said, we want to add all of the things, but maybe we need to focus on, pull ourselves back and just focus on one, the, the main goal in helping the patient. So with those in mind knowing thats a specific thing about med tech, what are some things that you notice or maybe some differences you notice in project management that dont have to be there from these industries outside Medtech and within Med tech? Is there any consistent or trends that you see thats a difference across PM's?
Perry Parendo: One of the big things ive seen thats different from my experience and my background compared to med tech is partly that patient uniqueness. But we're so focused from a compliance point of view on patient and health risk, we're not focused on project risk. And when I worked in the defense industry, we were hugely focused on project risk. So not just product, not just patient risk, but, and not just product risk, but much broader than that. It was the technical risk schedule risk and cost risk. And we were so focused on it because it was a large project that we actually developed models for those things and then actually performed Monte Carlo analysis to understand the sensitivity of the cost risk schedule risk and technical risk. And that was, and I've actually done it for other things in the medical device world. I'll call it covertly, because if they don't even know how to do risk, how are they going to understand a Monte Carlo? Just having some simple models and looking at things you can get a pretty good feel of. Are you really confident or is this really an optimistic, it's really not going to execute well, so let's break these things quietly.
Etienne Nichols: Yeah, well, I want to break those things down a little bit. So I don't know if we want to start with technical cost or time, but, or even how you did, how you managed to do those things covertly. I'd like. Do you have any stories about that or.
Perry Parendo: Well, yeah. Well, everything starts with technical risk, so that's really the place you start with any kind of risk management, which then ends up being the driver of your project management. And modifications to your plan and what you monitor.
Etienne Nichols: But if it's technical talk for just a second. So when we talk about technical risk for a medical device, backing up even a little bit further. When I think about medical devices and risk management, usually the conversation is referring to ISO 14 nine seven one, and it's talking about risks from the product to the patient. Is that what you're talking about when you talk about product or technical risk?
Perry Parendo: Or I'm, I'm dialing back even more on that technical risk and thinking that's a component of it. But what if part of that technical risk is our yields are going to be 30%. The 30% good parts don't cause harm to the patient, but they'll never see the therapy if we can't make money. So some of those technical risks are it's initially conformance to requirements. Can we meet the technical requirements or not? But then it evolves into can we actually meet the business requirements, too, which is get it released on time, make a profit, have adequate production yields, and thats essential piece of the ill call technical risk. And then as you get more into the business risks, thats when you can get into, and what does this do to our schedule? This goes, well, how, how quick could it be? If it goes poorly, how long can it be? And then all of a sudden you start seeing, well, if it takes longer and we have people engage longer, it's going to cost more. Or maybe that higher, higher risk technology actually costs more as well, you know, as far as, you know, maybe purchasing it from a supplier. And so they all tie together. But it's usually technical schedule and then costs being final. And then really to jump into the Monte Carlo piece, you basically simplify those models to a point so they're easy to add some of the Monte Carlo variation into it and then just run that simulation. And you kind of have that feel in both or in all three categories of technical cost and schedule risk. And once you have that, and that's, again, something I pulled from my defense life. When you do that, and particularly for me, again, in the defense world, id have a customer army customers say, whens this going to be done? And I said, well, what schedule do you want? The 10% schedule, the 90% schedule. The confidence varies. And because I had the Monte Carlo, I knew where I stood. I said, I can tell you most likely at 50 50, but if youre trying to talk to Congress, maybe you need a 90% confidence because you dont want to screw up, or maybe you need the 10% because youre trying to sell it and get more money. Just tell me which one you want. I can tell you the window, but I don't like giving point solutions like it'll be done May 16. That's way too precise to ever happen.
Etienne Nichols: Right. I love that because, so I've actually just been reading Andy Duke's book called thinking in bets. I don't know if you've heard of that.
Perry Parendo: Oh, yeah. Annie's awesome.
Etienne Nichols: Yeah. It's just the idea that you could put a percentage on it. And it was actually a success in my marriage recently because I said, I'm just 80% sure that if they do this, it's going to lead to this. And she said, well, I'm glad you left other options open because, you know, sometimes you think you're so sure of things, but to go back to projects, to give that, like you said, if you're in the Department of Defense, talking to Congress is one thing, talking to investors, another medical device CEO's need the same thing because they may be talking to a hospital. Who wants to know when can we buy versus investor who wants to know when, when will we get see an Roi and trying to get additional funds. So, I mean, it's directly applicable. Love to dive into more, more of this. If you, you know, one of the specific questions I'm always curious is what tool do you use to use to produce this Monte Carlo? I mean, maybe I'm jumping ahead of.
Perry Parendo: Myself, but there's, there's all kinds of tools that you can use for the Monte Carlo. I mean, and I'll just use some names because it's easier. You know, something like minitab is a tool that actually can do some Monte Carlo. There were some tools called at risk and crystal ball that are Monte Carlo focused tools, which are, I shouldn't say more powerful, but they're basically connected to Excel and they're very easy to program and get the output and run it. Many tabs are possible, but it's a little bit more, there's a little bit more baggage to executing that. And then Microsoft project, I forget the name of it. I thought there was a secondary software, but they had some software. You could actually do it right in Microsoft project schedules. So there's all kinds of ways to do it. Okay. That's cool.
Etienne Nichols: I know a lot of medical device companies use Microsoft projects, so that's helpful to know. And Minitab, a lot of medical device companies will have that for their quality.
Perry Parendo: Side as well, correct? Yeah.
Etienne Nichols: Okay. Okay. And I know I get a little bit in the weeds sometimes, or my own curiosity, I just chase that. But we go back to the technical schedule and cost. What I would be curious is, I mean, all of the information you feed into that Monte Carlo, that Monte Carlo is only as good as the information you, you feed it. So when you're building out that confidence level, how are you establishing that based on the information you're receiving, or maybe even upstream of that question, how do you get this information?
Perry Parendo: Yeah, so that's an awesome question because what I've. Well, Annie talks about it, too, in that book. I got friends that are good friends with her, reviewed her before. Yeah. So we've had a lot of conversations about Annie, and I've listened to podcasts they've done with her and read, I think, every single one of her books that she has. So she's, she's incredible. But we're horrible. We, as humans are horrible at estimating. We tend to be optimistic. And so with that in mind, how do you do a good Monte Carlo analysis to really capture it? We tend to be optimistic. So you got to really phrase your questions for getting feedback from a variety of people. Well, you know, there's always optimists and pessimists. So you got to make sure you're talking to the pessimists a bit for that worst case, because they'll give it to you. They're like, oh, shoot, yeah, if we can't get that part, the other vendor, they're going to take two months to deliver instead of the one month from this vendor, or they'll give some reality. And probably the biggest trick from a Monte Carlo point of view is knowing you're trying to get a most likely best case. Worst case. And, and it's not a normal distribution. And so the best tool that I've used is actually a triangular distribution because it's always skewed high. And if you use that tool, so to speak, that triangular distribution, your plan in your best case really usually aren't that far away, but your worst case can just really blow up. And that's where you really start seeing the schedule risks show up. And then what I would do is I would basically take the most likely, I basically add a buffer at the end of the schedule for the, that gets me to the most likely date, depending upon what I need to communicate and how safe we need to be with stuff. But, yeah, if our current plan says it's a twelve month project, but my 50 50 is 14 months, I'm not going to be telling people twelve months. So I'll add the buffer to push it out. We'll keep charging to the original optimistic date, but there's most likely it's going to float out a little bit.
Etienne Nichols: Robert. So there's, I kind of look at it like a budget to a certain degree. When you think about or just maybe money in general. Just as an analogy, there's a couple different ways to achieve your goals. Let's say your goal is to be debt free. You could maybe increase your, you know, increase your income or you can decrease your spending. How do you look at it with project management? Let's say we're chasing this goal and we have, we're trying to meet the twelve months, but it's looking like maybe more likely is the 14 month. We can change the plan or we can increase our pace. But how do, what are some, what are some things that, that you recommend when you're looking at those timelines and how to manage those things?
Perry Parendo: Yeah, there's a variety of ways that people say you should think about it. It's like, well, if it takes, it's supposed to take 14, it'll take 14. But there's some true business need. Like that's one of the differences in medical devices. The FDA fiscal year. If you want to be in, in the previous year, you got to be done in September and submit October 2 starts a new clock. And it just, people want to push and be before certain milestones like that. And if it really is a business need and not just a patient need but a regulatory type hurdle, what's it take to do it in that twelve instead of the 14 most likely? Do we need to add some people? Do we need to maybe reduce some of the technical risks so we don't have as much uncertainty? And I wouldnt say theres always ways to reduce it. But within a given window, if your Monte Carlo says ten to 18 months and your target are, lets say ten to 25 months, big window, but youre most likely is 14, you can probably find ways to get it to twelve, but youre not going to find ways to get it to eight. So if someones asking for eight, im going to tell them thats just not happening. Thats not even in our wildest dreams unless you totally change the scope. If you do that, a big replan that delays it in itself before we can even get started Preston and maybe.
Etienne Nichols: This goes back to statistical thinking and really understanding the statistics, but how do you know to tell somebody, well, we cant get it to eight, but we could potentially get it to this other number. I mean, at some point, your confidence in the Monte Carlo, I mean, you have to have that understanding. But how? Yeah, how do you go through that?
Perry Parendo: Yeah, it's, it's really, it's just a lot of conversations and maybe a bit of experience too, but, yeah, it's, it's knowing that you've really talked to enough people. So that triangle that I was talking about, that you really have, you know, if people say, well, it could be, you know, it could be an extra two months. Are you really sure it could be an extra two? Or is it maybe even extra three? Well, one time it was three. Well, then, I mean, you gotta, you can't just take the given data. You need to question and discuss and, or why is it two and what else could happen? And all of a sudden it's like, oh, yeah, it's probably not two. It is that three. And it's, again, it's not just accepting at face value the inputs and certain philosophies of project management is listen to the people closest to the work. Well, yeah, but doesn't mean you can't question them. You know, I think asking respectful questions is, is more than acceptable.
Etienne Nichols: Pasta is one thing people are most interested in. But like you said, a lot of times that's driven by the schedule, which is driven by the technical risk. Risk. Are there different, like, if we look at those as three separate categories, are there different things we should be thinking about or are they literally going to flow into one another? I don't know if that makes sense.
Perry Parendo: It does make sense. I mean, they're connected, so they kind of flow, but they're still unique conversations. So if it takes longer, what's all happening in that longer time? What are the costs that, so you kind of get the tasks that might make it go longer, the activities we may need to scrap some stuff and reorder some expensive, exotic material. Okay, well, how much might, I mean, it's a different conversation on the cops. It's just a deeper conversation. I would say. So they flow, but they're, it's not direct all the time.
Etienne Nichols: Yeah, that makes sense. Well, when we're talking about these different things that you kind of alluded to it when you talked about talking to the people who are closest to the project. There's this assumption that we're kind of making that people do that. And, and I think that's a big assumption when some projects get started. I think there's a lot of assumptions that aren't stated that well, we know just intuitively somehow that this and this and this is going to happen. But what's best practice? And, you know, just while we're on the Monte Carlo, what's best practice in project management? And then what's reality.
Perry Parendo: For pulling, pulling a true schedule together? Yeah, I think there's, I have a YouTube channel. I don't know if you've looked at it before, but I've got a bunch of YouTube videos out there, one of them that I particularly like. It hasn't gotten as many views as I think it deserves, but it's called the heartbeat of product development. And just the idea. Part of the idea is there's a rhythm to development within any organization. And there tends to be kind of general guidelines and I forget the exact numbers anymore. But requirements and concepting is usually 15% of your project. And then the next phase kind of design ish, is maybe another 35 additional or 45% something in that window. And so when you start, and you can usually see the near term well, but 18 months out gets kind of fuzzy. So if you know, kind of that rhythm of what your projects tend to be at your company, and you can start seeing those first phases, those end tasks, you can just basically take those past percentages, not as specifics, but as part of the Monte Carlo uncertainty. We've released the design. We have a manufacturing process. Now we need to do our validation work. Well, if that validation work is usually 35% to 45%, that's, we kind of know something. And as we're progressing, you kind of start getting a feel for how it may ripple through. But I can usually, knowing the rhythm of a company, have some idea pretty early on of what's probably going to happen again. Okay.
Etienne Nichols: And I would definitely keep a, or put a link in the show notes to your YouTube channel. That's pretty cool. I, I guess I didn't come across that one, so I'm gonna, I'm excited to check it out.
Perry Parendo: Yeah. Thanks.
Etienne Nichols: What about a company who's, this is relatively new for? Are those percentages that you gave, or maybe given the videos, are they relatively similar across products or across different companies, especially in early stage?
Perry Parendo: I would say that there's, it really goes across the industry to a point. If your requirements aren't that extensive and it's going to be a pretty short process or less regulatory burden, then probably your design constraints aren't as hard and your design is going to be a little shorter. So it really, it does tend to move together. I would say anywhere from a nine month to a three year project. Those ratios, I think follow pretty closely.
Etienne Nichols: Well, what are some of the other things that you've noticed across industry with medical devices that medical device companies could stand to get a little bit better on, or what were some things we could improve?
Perry Parendo: Yeah, you know, I john, a couple notes thinking about that, of what transfers from other industries, because I have a, for my corporate life had a blend, but also my consulting, even though it's mainly medical device, probably 70, 80%. I still get tastes of outside of medical, so I still kind of get a feel for it.
Etienne Nichols: And we didn't really go into your background, so I mean, we can do that a little bit. Just, that might be interesting, see if there are stories to draw from.
Perry Parendo: Yeah. So, yeah, I started, and I think you said this in the intro or with the bio, but I started General Motors back in the eighties and just, you know, new to the world and kind of figuring things out and just, you know, saw the real world. I told you before we started recording, but I just, as an intern, I designed and installed a ventilation system in a car assembly plant for GM. I didn't know until after that the crew, the contractor was installing it was actually part of the Mafia. And what an experience for a 21 year old that when third shift screwed something up, I'm basically chewing out the mafia guy. I'm like, this might not go well for me. No kidding. But they really did a great job. They were easy to work with. There was no weirdness to it. But, yeah, someone told me later, yeah. You didn't realize that it's like, no, I'm just, I'm a small town Minnesota kid. I have no clue what I was getting into. So I went from that into, biggest part of the next phase was aerospace industry. And so really sensors and products for aerospace, small kind of small products, but had the great fortune of working with Boeing as a customer and just an organization. There's certainly some issues in the news these days with them, but back in those days, my exposure to them is I don't think there's another organization on the planet that has their act together better than Boeing does. Their process for root cause analysis, for project management, for requirements, just everything was just stellar and just, they were just methodical. They knew what happened. They knew the rhythm. They were just awesome training ground as a customer. They were an awesome training ground for me of how to do things and do things right and do them well. It was after that that I so obviously regulated industry there with aerospace. Then that's when I went into my defense life and worked some smaller new technologies, but then also some really large projects, which is why risk management in Monte Carlo was required. I enjoy telling people a story. We made two prototypes in a three year period for $1.2 billion. So the scale of what we were doing and the complexity was certainly there. So understand your risk, understand your schedule, understand your costs. It was worth the time and the money to, to understand that very well, and you can scale it down for a smaller project like we tend to. Certainly dont have a $1.2 billion prototype in the medical device world, but you scale it down for a smaller project and simplify the model that youre using to understand whats going on. And then after the defense world, I transitioned in the medical device world with no therapy background, no FDA background, but the criticality of the oversight from the government and the FDA and the Department of Defense, their oversight approach, I would say, was somewhat similar. Where they're going to question stuff and if you have a, if you make a stupid mistake, they will always find it. Those kind of principles carried over. But I came in as a peer project manager and learning medical as quick as I could and delivered basically an 18 month project in ten months. Wow. Because of a competitive threat. But that was a case where, if this is that important, I better do some of this Monte Carlo stuff. Oh, sorry, it wasnt ten months. It was eleven. Our internal customer asked for ten. I was chasing it, but we end up eleven. But thats pretty good when standard was 18.
Etienne Nichols: Absolutely.
Perry Parendo: But that's where I did some of the Monte Carlo kind of covertly because they didn't understand risk, despite what I was trying to do with it. But I knew if this was that visible within the organization, that I better do these things, at least simply to just have a better feel for the project. And then after my medical device experience, along the way, I'd been teaching a graduate engineering class in addition to my job. So I had some academic view and that actually led me to some of my initial clients and kind of some exposure to medical device because they were working adults in my class. And then those former students, which I tend to call friends, once you're together for 14 weeks in a night class, you kind of know people. You don't know them all, but you know a lot of them pretty well. And former students would just ask for help. And I helped them kind of part time. Then after a few years of part time help, I got to stop helping my friends or give up my corporate job. I gave up the corporate job and just kind of went from there.
Etienne Nichols: Preston, so when you were doing that covert operation in the medtech industry kind of early on, was anyone else doing something like that that you knew of or you were kind of alone? Did it change the terminology and your language when speaking with management versus internal versus external stakeholders and so on, or how, what was the output of that work that you could directly relate to?
Perry Parendo: The biggest thing for me the output of it was it just influenced the decisions I made. I really couldn't communicate what I was doing to anyone. My customer, my management, my team. It was not part of their culture, but I knew it was necessary information. And as an example, even though we were trying to go fast at that time, the whole Toyota product development system and things like that wasn't overly common knowledge. But I carried two concepts forward. One was high risk, one was lower risk. I carried them as long as I could conceptually, until we had to kind of cut bait and move on. So I knew that there was some risk involved with both of them and I carried them until the point where I thought the risk was going to explode on us if I didn't pick a path.
Etienne Nichols: What do you mean the high risk, lower risk? Explain that concept.
Perry Parendo: We basically had some existing technology that was kind of safer, maybe quicker, but there was some new technology that performed better, least we thought it would. But we didnt have much manufacturing experience with that new material or new technology. So are we going to screw up tooling? Manufacturing process yields, but if it performs better and be nice to perform better to beat the competition, how do you balance those together? Its faster, but youre not competitive. Is that a good answer? And so, and honestly, at this point I cant remember which technology I picked. I remember pushing the tooling and everything we could as far as we could without cutting chips. And then one day it's like, okay, we got to make a decision and go. But at that time, my management, if we're going to be fast, you need to pick a horse. So I never told him I was carrying two concepts. I just did it very quietly because I knew that there were some benefits of both and I just, I didn't know enough to decide. And on paper it's kind of free to carry both for a while. So I carried both as long as I could.
Etienne Nichols: Preston, Id say most people probably try to do something like this in their head. I mean, intuitively, you know, there's multiple options and you're just sort of mentally thinking through or trying to think through and weigh your options. I guess that's where the phrase comes from. But you're talking about doing this on paper to where you can actually outsource your brain a little bit more and look at the full picture. I mean, is that accurate? And what are the benefits there in that decision making?
Perry Parendo: Yeah, from a decision making point of view, the human brain is amazingly capable, but at the same time, it has some limits of what it can absorb at any one time. And so by having it on paper, you could kind of like, do your own critical analysis of your thinking versus if you think you have it straight in your brain and you maybe have it 80, 90% straight, but that extra few percent may steer you a little bit wrong on your decision making at times. And so just being able to see it and reflect on it and stop spinning on it, what I found is the brain can hold a certain amount, and so you could spin in that if you put it on paper, you can get to the next layer so that you kind of get, maybe you're not just focused on the high risk items. Now you can think about the moderate risk items or whatever that next layer might be. And I've. I've found that to be a very useful technique. By making lists, putting things on paper, running simulations, it's a sanity check on yourself, but also it's a way to basically export it and not have to maintain it and, and in memory, and you're able to think next level and next steps a lot better.
Etienne Nichols: What are some of the next level steps or next level thinking that a lot of medical device companies just don't get to?
Perry Parendo: Yeah, I think some of it, and this is some of the notes that I put down. Just making good decisions, knowing when you need to make a decision and someone standing up and making it. I don't like making decisions as a leader. Not that I don't want to, but I'd rather the people closer to the work do it. But I used to always tell my team, I said, I'll make a decision for you, but you might not like it. So if you have one, go for it, because I'd rather do what you do. If you have a good rationale than me. I haven't been thinking about this long enough to have a quality decision yet. And so they would oftentimes decide, but sometimes there was, whether for political reasons or career reasons, people just want to stick their neck out. I would kind of have some conversations and then make a decision based on that. So the concept of decision making, I think, as a, as a leader for projects, is critical of just doing that well, and then executing the decision, not just talking about it, but actually being good for your word, being consistent. Here's what we want to do. And we're going, yeah, and then there's no delay. There's confidence in the team.
Etienne Nichols: Two of the areas of project management that feel maybe it's my own personality, but they're relatively difficult compared to the rest is the beginning, the very beginning, knowing when to start and what all those activities need to take place to make sure you do them all comprehensively because that's going to influence a lot of the bulk of your work in the middle. And then actually closing out that project, chasing down all those loose ends and just making sure it's all finally done. What's your experience and how can you make those easier? If that is experience and if not, I'd love to hear that, too.
Perry Parendo: Yeah, no, that's a great question. That was actually one of the notes I made myself I want to try and talk about. So, yeah, there's popular language for that. Is the fuzzy front end of a project. Yeah. Because it is so confusing. Where do we start? How do we balance it? And what I found is leadership oftentimes because it's confusing. They're kind of hands off. You know, you're the people. You go make your decisions and kind of go. And then when it gets to the end, when a lot of stuff is going on, then they start micromanaging because now it's important and they can see tasks. And I think you need to flip that as a leader. You need to be involved in the fuzzy part. Straighten that out because you have experience. Let's, let's straighten out that fuzzy stuff. But also I'd like to give, I'll call, I hate the word empower, but you want to give your team the ability to make some decisions, too, because if they're going to screw up and you can't trust them, I want to know that near day one, if possible, not on month twelve, on a twelve month project. So I would let things, certain things float and see how they played out. If they weren't critical, the critical things, the high risk things, the big impact things that I learned from, say, a Monte Carlo, I would make sure that those are going well. But kind of that next tier, I kind of let some of those things float and see how the team work. And some people, if they weren't capable, okay, we're going to have to take away critical things from them or manage them differently. People that show they're capable early, let them run, and literally as a project executes towards the end. I'm way hands off. And most managers, that's when they kind of pick up their pace of managing. And I feel the most effective management is if you got a trusted team, let them run, leave them alone. And they tend to do better than I would. There's certain things that I would see, and I go, boy, I don't know how that's going to go. We'll see. And then it turns out awesome. I'm like, well, I'm glad I didn't get in the way of that.
Etienne Nichols: Yeah, I could see that. A lot of teams like to self select their team leaders and things like that, and just, there's natural hierarchy that seems to form and just kind of roll with that, encourage it. How, how deep do, whether it's project managers or whoever need to get into some of the specifics of managing that, that project from a reporting standpoint or measuring standpoint. Like, one of the things that comes to mind is earned value, for example.
Perry Parendo: Yeah. Yeah.
Etienne Nichols: I don't know if you want to talk about that or just, just some of the tools that are, that are out there that people may not be aware of. Any thoughts?
Perry Parendo: Yeah. So in the defense world, earned value was a big thing. That was a monthly requirement for us. So I got pretty comfortable with that there reporting on it, reporting on the variances and such. I found many companies that I work with, their schedules are so immature. You can't even do earned value for projects I was leading and trying to detail. I would try to do it again kind of covertly just to get an idea. Are we on track? Are we making progress? I really tried to do kind of some quiet, simple earned value and earn value just to.
Etienne Nichols: It's been a long time since I've thought about it. For those listening, it's essentially looking at your overall project and almost putting a dollar value against the amount of time left to a certain degree. Is that way to describe it?
Perry Parendo: Yeah. So you basically convert hours into dollars of effort, and you have planned versus actual and a bunch of other ratios. But if your actual dollars consumed labor and materials is 50% more than you had planned, that ratio is probably going to continue forever, and you're probably going to be over on delivering. Yeah. And so it's a really cool, it requires data to do it, and then there's all the different nuances of the ratios that you're looking at and for different purposes, what you can read into one or the other. I spoke at a conference, international conference, a number of years ago. And it wasn't military based, but it was when I was in that world. And one of the, one of the talks, or maybe two talks said these two things, but one of them was a, even in the military, we tend to over schedule, we are too low of detail in our planning. We could actually go one level higher and still be effective. Then the other part of it is back to the fuzzy front end topic. Your earned value metrics at 15% of the way into the project are pretty much where those metrics are going to end, really. Basically you're setting up that pattern, that heartbeat of your team in that 1st 15%. And so if you don't manage well in the first 15%, you're setting up behaviors and habits, they're going to extend the rest of the project and you can't, as a team expands and money's being spent and tools are being made, you're not going to get more efficient, you never get better. I said those ratios maintain. At best they maintain and sometimes they get worse.
Etienne Nichols: Entropy is real and we're human.
Perry Parendo: Yes, good analogy.
Etienne Nichols: So, project managers, if you take the title away, a lot of first time founders or first time CEO's of medical device companies, whether they're doctors who have ideas, or engineers who have come up with an invention from talking to doctors, let's call them CEO's, but really they're project managers at the beginning. I mean, it's an accidental or otherwise. And what are some things that you earn value? Is that something that they should learn or what are the things that if you thought of an accidental project manager, you were talking to them? Well, here are some things you've got to figure out and you've got to know at the, at the onset, one.
Perry Parendo: Of the big things, I'm trying to think how to phrase it best, but there's a lot of tools for Project management. But when you're talking, particularly in that founder area, they are so excited about their idea and they expect their team to be equally excited. And motivation is huge. And if you ignore that and you think they're going to be excited as you are, I've always more on the soft side. Try to understand my team, what's their interests, what are their motivations, and make sure they're getting those assignments. There's going to be a lot of crappy work to do. So two things, the founders probably going to jump to the exciting things because that's why they founded it. But me as a project manager, I would take the crappiest assignments that no one else wanted on occasion, because it's like, no one else wants this. It doesn't really fit. It's just got to get done, and it's a horrible task. I would take those on, and I didn't brag about it to my team, but my team knew I sucked it up for them. But then also on the flip side, if I knew what they loved and I was giving them those things and I had something crappy, but it really did fit them, they knew I wasn't giving it to them to be mean. Hey, I know this isn't your thing, and I would literally say this, I know this isn't something you like to do, but we got to get this done. There's this other task coming, and it's a really cool thing for you. As soon as you get this done, you'll get that next thing. And what a way to motivate, to get through a crappy task, whatever that. And it might be crappy for them, might not be crappy for someone else. So if I could split it that way, I would. But sometimes it just, it had to fall on that person. And so you just make sure they understood you weren't, you were appreciating the fact they weren't going to be like, doing cartwheels to do this thing and they would attack it, you know, well, and that made a big difference. And I think that's one of the things founders misinterpret is everyone's not as excited as they are. And make sure you're taking some of the **** work at times. You're not just doing all the fun work as the project manager, as the founder of the company.
Etienne Nichols: And maybe that highlights the difference between a pure project manager and a founder. That excitement level and the ability to see past your own excitement. But to instill that excitement in your group is also pretty important.
Perry Parendo: Yeah. And there are ways to do it. You figure out what motivates them. And I think not everyone, but most people can be aligned to a project goal with their individual goals. But if you don't understand the individual, you can't get that alignment.
Etienne Nichols: I think a lot of people assume that that individual thinks the same way they do or is motivated the same way. Do. Would you agree or that.
Perry Parendo: I think that's a hugely valid point. Yeah. And people are. I mean, just, it's so amazing sometimes the stuff that people like, you know what really gets me going? I love regulations. I'm like, are you kidding me? But some people love digging into that and exploring it. It's a research project. And if that flips your switch, good for you. You get all those tasks.
Etienne Nichols: Yeah, absolutely. And don't let that person go because they're valuable.
Perry Parendo: I was going to say, yeah, make sure they, you retain that one.
Etienne Nichols: So there's the two. One other question I want to ask, and maybe there's more. And if you have more in your notes, let's get to that as well. I don't want to, I want, I want to hit whatever you wanted to talk about. I've worked on multiple types of projects where, on the one hand, maybe all of those people report to my project, maybe nobody reports me directly. And that's actually my favorite because I don't have to deal with that level of free frustration. But, but they all report to my project 100%, and those are my favorite. And then there are other types of projects where, you know, I'm, I'm the guy on your project, but I'm doing it for everybody else, too. And that's hard to like. Well, you know, maybe we're not the highest priority project. We've got three or four or whatever the number is, and, but I really need you to do this thing. What are your thoughts on, on that, that partial versus whole? And do you have recommendations for both companies and project managers?
Perry Parendo: I think it's a great question because I see that a lot, too, the shared teams. And at times it makes sense. You got critical resources, but companies try and solve it by establishing a priority list. And then someone says, well, you're priority two, not priority one, you get zero. It's like, wait, wait, wait, wait. We need to think about how we balance this. Maybe you're putting 35 hours a week into number one, but I need 5 hours to keep us moving. But sometimes people take those priorities as all or nothing. Or, and the other challenge is there's, if they maybe have three assignments that about a third of their time, the invisibility of those other two thirds, how can we make it, make me aware that, you know, you have other things going on and how we can work with that. But if it's left in the dark, then it's all on the worker. And it's kind of, I think, demotivating. It's just like taking a college class. Every professor thinks your class is the only one you're taking. And it's like, no, I have a life and other classes going on.
Etienne Nichols: Really good analogy. Yeah, it's really good.
Perry Parendo: I think helping people balance as opposed to, you know, you work this, when you're done, you move on to priority, too. I don't, I don't think that works. I think everything's a balance and it's always dynamic.
Etienne Nichols: Yeah.
Perry Parendo: And I don't see many companies do well with that.
Etienne Nichols: Right. And maybe that's just a struggle that will forever be inherent with a partially balanced team. I don't know.
Perry Parendo: I think, though, if you actually say, again, if they're split 30%. 30%. 30% and you can have some visibility to their work as a group, I think it helps. But if you kind of, it's like, here's what I need from you this week, and it's 50% from each person. How do you just got to be honest? You got to have a culture that can have that conversation instead of, well, I can't say no, so I'm just going to say yes and not do a chunk of each one of them.
Etienne Nichols: Yeah. So this is a me being a visual thinker. A lot of times a project manager can visualize the boundaries of their project, and we see where that fits into the company. And so we have this project team within this boundaries, and they, they extend outside the boundaries of your project if they're partially on your team, partially out. And so this, this is something I'm pretty passionate about. Like, as a project manager, you don't just focus on the people who are stakeholders to your team, stakeholders to all these things. You actually need to go way outside the boundaries of your project. And if you disagree, I'd love to hear it, but I think, I feel like it's almost a political position to a certain degree where you go outside those boundaries so you can start being influential even outside your project. Otherwise, you may not be able to influence those people who are outside your project who need to work on your project.
Perry Parendo: That's such a great point. I literally, I think it was this week, had a meeting with a client where I'm doing some project management for them. And first, to your point, I talked to one of the higher levels at this client, and I said, one of the things we're missing is the cross project dependencies. You know, like you said, we can look within our project, but what else is from the outside maybe influencing us, shared resources, whatever it might be. So I said, I think we're missing some cross project dependencies. I told him a couple. He says, well, what other ones do you see? And I give him a list about three or four others. So, yeah, you got to look outside your boundaries. That was one thing I wanted to say. Oh, and then, yeah, this had no impact on me directly. But part of that meeting I had this week that I mentioned, one of the people in the meeting said, here's what else I'm doing. And he made it visible. I'm working on this for you, but I'm doing these other things, too. I'm struggling with this here. I don't know why he told me, but they're like, well, are you part of that project team meeting? He says, I already have too many meetings. Being a shared resource. I got to do status to all of them, and I have no time left to do work. And so he said, I don't want to be in that meeting. I just need this piece of information. And so everyone was kind of quiet, and I was the project manager, and so I just go, I mentioned someone by name in the meeting, and I said, do you know something about this? And they're like, yeah, can you help him? Yeah. Didn't help me, but if it helped one of the people on my team, he was going to be grateful and he could get his other work done. And then there was something else that came up on another project, wasn't related to us. The conversation happened, well, how can we help with that? A lot of times people are like, well, that's out of scope. That's not our focus. This meeting, it's not on the agenda. If people are struggling with something, fricking help them. We got to not just be selfish about our own project. We got to help other projects, other people in the business at large. And that's not altruistic. When you get a team that thinks that way and you're picking each other up, it goes a long way. I've been bet on. Those teams are awesome. I've been on teams that weren't that way, and it's just a nightmare. It's frustrating.
Etienne Nichols: Yeah. People may look at it as, like you said, maybe they. Some people might look at it as self serving, but other people may say as too altruistic. But, I mean, there's a balance there. I can remember in manufacturing, I had a project team, and I knew another manufacturer, manufacturing engineer who needed. He was just at a workload that was immense. But I also looked forward. Six months from now, we were going to need his help. So I guess started feeding him a few resources and just kind of like digging the well before I was thirsty, you know what I mean? And then as soon as we needed his, his help, he was on it, and. And we could get through that more difficult period, and you just got to be able to look outside and look ahead and get those things done. So.
Perry Parendo: And doing those things. People want to be part of your team. Yeah. Whether it's this project or the next project, they're like, hey, I want to work with you again. Versus, thank God that project's sober, right?
Etienne Nichols: You want everybody to be mourning because the project's over, not. Yeah, because they're on it. Yeah. Let's just delay that, that morning period.
Perry Parendo: Yeah.
Etienne Nichols: What, what else is on your list? Anything else that you felt like we needed to cover? And are we okay on time? Because I took his pass. I never do this, but, oh, no.
Perry Parendo: We'Re having such a great time with this. It's.
Etienne Nichols: I can talk project management all day.
Perry Parendo: Man, this is fun. And obviously I can, too. Probably way more than I can. This is great. But, yeah.
Etienne Nichols: What else did you want to cover? And then we'll just kind of wrap up.
Perry Parendo: Well, this is the, the last big thing, and this is actually the talk that I did at MD and M West when we met. But there's all these different processes for project management or project planning. There's waterfall, there's agile, there's Toyota, there's set based design, and there's APQP in the automotive industry. There's huge groups of concepts out there. And my talk at Mdm west was, and they're really, they can be different, but they have, can have a lot of carryover between each other. So in my defense, life, you may argue that that was a waterfall look. But we actually doing some agile practices. We didn't call it that, but we had a chief engineer, too, and that was kind of a Toyota thing. They're all a blend. You know, there's no organization that's doing purely the theoretical of any one of those processes. And yet I talked to company after company, wow, we need to do better with product development. So we're going to implement this new process. In the back of my mind, I go, it's going to be a waste of time and money, and it's going to frustrate your team. They're going to do the same thing they're doing today, just with a different title and a different set of meetings. And what you really need is know what's important for your company. Focus on those aspects. For instance, is requirements. Important is innovation and intellectual property. Important is cost. Important is delivery schedule. Important is manufacturing costs important. What are those aspects that are important to you as an organization? How did you get successful today? And then make sure that's emphasized in whatever process you're using, because in my corporate life and in my consulting life, I've seen so much overlap between those theoretically different processes. They're all intermixed in every organization and they're always different, but they're emphasizing what's important to them. And I think that's, I think we need to get a little bit less hung up on process labels and just emphasize how do we want to run our business and what tools can help us. Tools and motivation, soft skills to get there.
Etienne Nichols: I can see companies getting in just distracted by those shiny new ways of doing things, whether it's scrum agile and all these different things. And I went down that rabbit trail myself. I pursued the PMP, and then I got disenchanted. I wanted, okay, I'm going to be a certified scrum master. I'm a fix this process, and I went down that rabbit trail. So Toyota and Cotta and all that. Yeah, but you say these companies need to focus on what's important to them, and it sounds like they're going to self select to a certain degree, because I agree these companies are doing a process of some sort now, and so you just try to implement a change. They'll kind of covertly get back to their old ways of doing things. It seems to be the tendency. So how do you, how do you establish something that is helpful for a company or a team or a department without trying to put a, you know, square peg in a round hole?
Perry Parendo: I love that question. Early in my career, I was part of a division wide improvement team, and it wasn't for new product development, but the topic really doesn't matter. And we had an outsider come in and it was a co worker, but someone outside of that group. And he went into this management meeting, and we were fighting with him for months to like, we need to move in this direction. We need to move in this direction. In less than 45 minutes, he went to that meeting and came back. And I go, I must not have gone, well, you're back already. He goes, no, they agreed. I go, there's no way I agreed. They haven't agreed to anything for the whole time we've been trying to work on this. I said, what did you do? Tell me what you did. He said, perry, you need to know where you need to take them. You need to know where they're at today. You only need to ask for the next step. He says, where you want to take them is going to blow them away. They're not ready for that. And if you ignore where they're at today, you can't have a plan forward if you don't even know their current status. So know where they're at, know where you want to take them, move the next step. I've followed that since that day as best I can. I fail a lot and everything as everyone else does, but I've tried to keep that mindset of next step, not big step, next step. And we haven't talked. I used to coach high school basketball. I've done that for a lot, a lot of time. Same thing with players. You can't say, okay, we're going to run this, and this is what the Minnesota Timberwolves do or the LA Lakers do. These kids are like, in third grade. They're probably not ready for that yet. What's their next step? Maybe dribbling. Yeah.
Etienne Nichols: Yeah. Oh, man.
Perry Parendo: I.
Etienne Nichols: So I'm, I'm just starting to coach two to four year old soccer, which halfway through, they switch directions on where you're supposed to go. Right. That is very confusing for a two to four year old anywhere. You know, three year olds just think about it that way. And so it's a perfect example because last night at halftime, all the parents laughed at me. I got out my notebook, and I had all the kids, they all surrounded me because I had a prop, and I said, okay, guys. They thought I was pretending to do a play and I was trying to be funny, but I also said, and I had an arrow, and I said, all right, guys, we're going to be going this way. You, you're going to run and we're going to go that way. They're like, okay, okay. And we're. And just the arrow over and over, we're going that way. And that's all I cared about and why my team was the only team out of all the two to four year olds knew which direction after halftime, which direction to go, and which was the competitive advantage. Oh, the competition's hilarious.
Perry Parendo: But, yeah.
Etienne Nichols: Thank you so much for this. This was really fun conversation. Anything else? And if you, if there was one major takeaway for our audience that you wanted them to take away from, it's hard to wrap up in an hour long plus conversation with one sentence.
Perry Parendo: But.
Etienne Nichols: But if there's one takeaway you wanted people to take away from this, what would it be?
Perry Parendo: Care about your project, care about the people, focus on the priorities, and a lot of other things. Take care of themselves.
Etienne Nichols: Thank you, Perry. I am excited. Maybe we'll do this again sometime. I don't know. This is a fun conversation for those who've been listening. You've been listening to the Global medical Device podcast. I appreciate your attention and we look forward to talking to you next time. Everybody take care. Thank you so much for listening. If you enjoyed this episode, can I ask a special favor from you? Can you leave us a review on iTunes? I know most of us have never done that before, but if you're listening on the phone, look at the iTunes app. Scroll down to the bottom where it says leave a review. It's actually really easy. Same thing with computer. Just look for that leave a review button. This helps others find us and it lets us know how we're doing. Also, I'd personally love to hear from you on LinkedIn. Reach out to me. I read and respond to every message because hearing your feedback is the only way I'm going to get better. Thanks again for listening and we'll see you next time.