Frank Webb, the previous Director of Engineering at Edison, shares valuable insights on the challenges of meeting critical delivery timelines in a fluid build environment. With his proven track record of successfully leading both engineering and program management functions, Frank explores the complexities of this issue and discusses the various factors that can impact delivery timelines.
During the discussion, Frank addresses a critical question that many stakeholders in this field grapple with - who holds ultimate responsibility for delivery? By clarifying the roles and responsibilities of all parties involved in the delivery process, Frank provides strategies for ensuring that each stakeholder is accountable for their part.
Key Takeaways:
- Edison serves as the guide to help you navigate the journey from the design phase to the production of your product. In other words, it falls to us to anticipate the upcoming challenges and to oversee the whole program, so that we can provide our partners with helpful advice about what steps to take and when to take them.
- We are committed to delivering results and being accountable to ourselves and to our partners throughout every stage of the process.
- It's no secret that design risk and supply chain delays can wreak havoc on delivery schedules. That's why we've taken a proactive approach to these potential pitfalls. We work closely with our suppliers, keeping open lines of communication at every step of the way. Plus, we've implemented processes that identify and mitigate risks early on in the process. With our active and determined approach, we're confident that we can handle any challenge that comes our way and keep delivery schedules on track.
- The ability to comprehend what a customer needs, even when they cannot express it themselves, is what sets a great program manager apart from the rest. By truly understanding the customer's business and goals, a great program manager can create a program that exceeds expectations and delivers results. It is through this dedication to understanding and anticipating the customer's needs that program managers can make a real difference in the success of their projects.
Full Transcript:
Brandon: Welcome to the Capital Light Assembly podcast brought to you by Edison Manufacturing and Engineering. Edison is your low-volume contract manufacturing partner focused on capital-light assembly of complex mobility and energy products that are not well suited for heavily automated production. I’m Brandon Bartneck joined again today by Frank Webb. Frank, welcome back to the podcast.
Frank: Thanks for having me, Brandon. I’m glad to be here.
Brandon: Yeah, last time, so in the first episode of the podcast, you joined to talk about quality for the type of work that we’re doing in Capital Light Assembly. I think the next pillar of this production is delivery, right? So, how in this low-volume world do you actually deliver reliably to a set schedule and to the expectations that have been set by whomever? So, the first, maybe foundational question, is who's responsible for delivery and the ability to provide a product when it has been requested and is needed?
Frank: That's a really easy question, and that is the contract manufacturer, as we are, right? It doesn't matter if the item that causes the delay is a design issue or something outside of Edison's direct realm of control or something within our realm of control. I view us as we are the shepherd of getting from design release to bringing it into low-volume production. So, it's kind of up to us to see what's coming and see the landscape of the program and be able to help advise our partners on what needs to happen and when and make sure we're holding ourselves and each other accountable as we get to the actual delivery of the product. So, we are to answer your question quickly.
Brandon: So, it's less of, in a situation like this, in which a customer someone is working with an external partner for manufacturing that the manufacturer, in this case, Edison, like it can't be a passive role that we're playing, waiting to get the input to meet our schedule, but it must be another more active role.
Frank: Absolutely, and that's actually something that, when we were founding the company, that was one of the major complaints that we all had in working with contract manufacturers in the past and complaints we had heard from working with previous partners and customers, that hey we ran out of a bolt we ran up x bolts let us know when you get more, but by the way, we're still billing you for the facility and the folks on the line, right? That's not really acceptable to us. It's not acceptable to me. It's not what I expect out of a really high-quality contract manufacturer. I expect somebody looking out forward a little bit to give us a heads up that we're going to have a problem and helping work with us, work together, on solving it before it becomes a real shutdown situation.
Brandon: Yeah, it makes a lot of sense, and so thinking about how or when things go wrong, right? So whenever someone wants to build a product, they work with a contract manufacturer here, and they have a set demand where they have “x” products on some curve that they need to provide and complete so that they can sell them and generate revenue and feed their business all these types of things. What are the typical things that go wrong that prevent that delivery schedule from being met?
Frank: Yeah, well, the things that can go wrong kind of depend on the specific circumstances of a program. So, if we're talking about a new product, a newly invented product, or something that's just coming out of the prototype phase, obviously, the design can go wrong. Design almost always goes wrong. It's very rare that something comes straight out of a prototype, goes into production, and has no revisions, right? That hasn't happened, at least ever, in my experience. So that's a major concern and something we plan for ahead of time, and that is the way that we approach program change control and engineering change control, which can be two different things that kind of work together, the way that we manage delivery schedules, and where we add buffer in our time periods, right? The really critical one is the time between what we call the MRD, the material requirement date, and the start of our first production build. That is a space in time that helps us absorb some of those things as well as internal right issues on the assembly line in the inventory system as well as from the design side. Really it's also kind of a collaboration effect with having, if we can, if it's if it's feasible, we like to have the design engineers on site for our first couple of builds to see how the product is actually coming together, test the thing right when it comes off the line, make sure that it satisfies the requirements, and it's what they expect and we're doing that live together and you really cut a lot of communication delay out of that. Other things that can go wrong are supply chain delays. If you're, especially when you're in the low volume space, a lot of the time, if you're getting a commodity produced product, whether it be a weldment or a cast part, or injection molded part, machine part, you're a small volume customer to most shops that are manufacturing that part, which means you're a low priority, right? Especially if you're dealing with a larger shop that's got orders from the big three, they've got orders from Boeing, they've got orders from, you know, lord knows who, a giant, you know, a six to seven figure order is going to get precedence over you. So being really proactive and engaged with that supply base, checking in and catching if things are falling off track, whether or not openly discussing it, being able to identify that with site visits as well as check-ins on a regular basis and really managing that supply base helps us to mitigate that, as does being really proactive with a risk register, right? That helps with the first item as well, but really proactive risk management means you're generally not surprised when you run into a risk because if you've done your risk register and your risk management properly, you have anticipated this at least at some level, and you've articulated what we're going to do should that risk be triggered. Having that plan already set ahead of time really takes the delay out of reacting to an adverse situation because the team has already been informed. We've already gone through the exercise; we know what the plan is and how we will react. So, those are two major things, design risk and supply chain risk, that can really hamper us, right? There are things that tend to be outside of the contract manufacturer's control, and what we try to do is put quite a lot of effort into being forward with those types of scenarios and really understanding the maturity of the design and how much we need to plan for in terms of risk in design journey as well as the maturity of the supply chain. Especially if we're in control of that supply chain, we're responsible for that supply chain understanding, where that supplier lands, and where on their priority scale. Sometimes the commodity that we want and the way that we want it done drives us to a supplier or a set of suppliers that are generally doing this as a low volume, you know, niche add-on to their business. So that requires a different level of management and forethought in order to really mitigate the risk of being pushed over the edge. You're pushed out of the priority tree.
Brandon: I think this risk assessment and then the subsequent plan is really interesting, and the way analogous, I think, like an FMEA for operational execution and such an effective. But the question I have is, how do you do this well? Right, so, it's easy to say, going into a program, let's proactively identify the things that could go wrong and find a way to pro-actively mitigate those things, but that only actually means something if you identify the most important risks and ideally, like all of the feasible risks that you're able to actually proactively identify and avoid and find ways around them. But the gap between just doing that activity and doing it well is huge. So, like how, in your experience, what goes into executing well in this space?
Frank: It's a good question. I think it's really too faceted, number one, and it's, you're right, it's going to be very similar and very analogous to a proper DFMEA or PFMEA. The first thing that you generally start within a DFMEA and a PFMEA is what have we done before that has been similar to this, and what went wrong then, right? So, you go back to your previous PFMEAs for these types of operations, and you start looking at it as a thought starter, but you can't let that blind you either because you also need to take a bottom-up approach. Let's look at every part, every process, every piece of equipment, every designed system, right, and think about what changes could happen there. So, I look at it as both a top-down and a bottom-up. Top-down of what have we done in the past, our team members or us, as this direct team has done in the past, and what types of risk registers have we created? We try to keep all of those we do here at Edison and be able to look back at that and utilize the learnings from those previous situations, especially when risk was triggered because you learn a lot more than as a thought starter of these are the things that we know from experience have happened. And then also taking a step back and not necessarily forgetting about that, but not thinking about that for a moment, and let's look at every, like I said, every component, every subsystem, every possible direction of design change, you can't anticipate every possible design change, but you're going to anticipate what the effects would be of the different systems. Doing a design change on a system with a bunch of tooled parts is obviously a lot riskier than doing a design change on a system with a bunch of harnesses that we make offline, right? Those are two different things and two different levels of risk management. So, doing the top-down and bottom-up approach together is how we approach it and how we come up with a really effective risk management plan.
Brandon: Yeah, there's a weird kind of cultural aspect there too, of like, this idea of you don't expect things to break, right? Expect the best, but at the same time, plan for the worst because optimism and hope are not a good strategy for just about anything.
Frank: Yes. I actually like the way that we have the culture operating at Edison, especially with respect to that, because team members tend to look at it from the perspective of this is how we're going to do it, and this is the standard risk register. This is the way that we see issues coming about, but we're very optimistic, right, but you have to have somebody step in a little bit from the outside, whether that's leadership in that department or leadership in a different department, sometimes individual contributors in different departments that will step in and come at it and try to poke holes in it. Let's sit around, let's put the plan on a pedestal, and then see where we can throw a dart at it, see where we can poke a hole in that balloon, but being able to do that in a really healthy manner in a really productive manner allows us to come up with much more effective plans than one that's done in a vacuum, right? Everything, everybody that's been in product development has come across the DFMEA that was copied and pasted from the previous iteration, you know, the design, and it never catches what goes wrong because you haven't really considered from a really collaborative standpoint what's different about this that could cause us an issue and what are we going to do about it.
Brandon: So, this development and management of an effective risk register, which is fueled by past experience and documented best practices, is a core foundational idea. Anything else that you’d highlight from an operational best practice standpoint to make sure that we are delivering and at least giving ourselves the best chance to meet a delivery schedule?
Frank: The one that is probably an easy answer, but I think it can't go understated, is really strong program management. Having a program manager who understands their role in the program and what they are really empowered to do to drive that program to success, and then having all the tools available to them. I mean, many people like to tout the PMP, and I think it's a great tool, but it's a tool in the tool belt. There are other things that go along with that. There's project management software, there are all the lessons learned in the template that we create every single time we do this, but having a really regimented and scientific method of program management to empower and enable the program manager to not necessarily deliver the program on their own because that's not a realistic expectation, but to empower that person to help empower their team, their program team, in order to perform the best that they possibly can and allowing them to have the resources in the tools and their tool belt in order to drive that team to success. Some of them are soft tools, right, they're interpersonal things, and some of them are hard tools. This is, you know, the right way to create a schedule, the right way to track actions and how not to slide back into managing a program from an issues deck, right, which is a really common crutch that happens in this industry. There's a lot of value to be had out of just driving the program to completion using the right high-level program management tactics.
Brandon: And maybe this is an interesting jumping-off point or transition point, right - so the program manager is the interface between the work that's being executed at Edison and our customer, partner who we are working alongside. Can you speak well about how important or what role that relationship and an open, transparent relationship between Edison and our partners or customers play in making sure that we collectively own the responsibility to execute, but at the same time, we aren't empowered to execute everything? What's the importance of having a relationship, or how does that work?
Frank: It's really critical. It's very critical because the program manager is kind of where the buck stops when it comes to the Edison program team’s performance, right? It's this individual who has the most oversight or visibility to all of the different functional activities happening all at once, and so they are most empowered to see issues before they happen. Being able to match that level of really that zooming out on the Edison program with the ability to build and maintain a strong professional relationship with the customer advocate, they then become the voice of the customer to the team, and that's really important because not only are they the voice of what the company, what Edison wants to do and accomplish, we're going to do to accomplish x goal in y time, but they are also the voice of look I have a relationship with the customer, and I understand what they want I need to be able to articulate that down to the team member on the actual functional team that is helping do the actual work so that level of interface and people management is really kind of what makes that interface work. So, the ability to understand what the customer needs and wants, whether they can articulate it themselves or not, is really what makes the difference between a good program manager and a great program.
Brandon: Yeah, it seems, so far, like the old school supply relationship of throwing something over the wall and having your contract manufacturing partner execute and send it back to you like doesn't really, especially in the spaces we’re playing with these complex assemblies and new markets and new technologies and new products, like it needs to and, it's a cliché term, but it really needs to be we need to be a supplier partner and a true partner alongside our customer be able to work hand in hand to proactively and reactively address challenges that come up throughout a program.
Frank: For sure, and when we talk about, I mean, you can talk about established products, those where usually we're doing it in a new way, right, in a way that an established product that may have been around for decades. It hasn't been manufactured the way we're going to manufacture it yet, right? That's why we're involved. So, you can't take that for granted as a throw-it-over-the-wall. Maybe the design is more stable, but that doesn't mean that the assembly process is already vetted out because if it was, we wouldn't be here, and doubly, so, when you're talking about the new technology products or the start-up products, those are coming into a brave new world, and they haven't, you know, they haven't had the acid test of going to market or going to any production environment yet. So, you've got it from both sides in that scenario, but the same principles apply of being really connected to the customer because the customer, our partners or design partners, generally know more than pretty much anybody on the planet about the product that we're trying to build. So being really well plugged in with that team is what really makes the difference, and being able to articulate those requirements both from our internal team out to the customer and understand what we can do, and then hearing the requirements from the customer out sometimes helping them articulate what those requirements are, is really what can help make the difference and that conduit ends up being program management.
Brandon: Cool. Yeah, and just a kind of sampler teaser here, but I think there's a good intro to what it takes to deliver in the space. Is there anything just super high-level that you think we missed, or do you want to make sure to highlight from the discussion?
Frank: I think we've gone over all of it, but the thrust of it is that the conglomeration of all of these things together is what drives completion. I've talked a lot about program management here because, ultimately, what makes the difference in completing a project is understanding the requirements, the capacity, and the capabilities and then tracking that progress relentlessly all the way to the finish line. But I think that's what makes the difference is having a really powerful program management staff that understands the business, that understands the customer, and also has the tools in their tool belt to be a really effective high-level program manager.
Brandon: Well, thanks again, Frank. I really appreciate you coming on for another discussion here. It's great learning from you. I appreciate the thoughts, and yeah, thanks, everyone, for listening!
Frank: Absolutely! Thank you.
