Ep#32 New Product Development in Auto Sector: Challenges and Solutions

Hello and welcome to the counterpoint podcast, I am Shubham Agarwal and we are discussing about NPD projects today. Now doing NPD projects on time is a rare event, I am sure you would agree with me on that. Most projects are grossly delayed and many launched products fail in the market. As per data published on Stetrister, as much as 91% of the NPD projects fail to complete or go way beyond this schedule time. Now this is not shocking I think, everyone across knows that this is a common phenomenon and it is troubling because NPD is what decides the future for any organization because that is the new product or anything new that is coming into the market. It is also referred to as the dark underbelly for many companies. For the discussion today, we have with us Vivek Chopra, he is a senior consultant at the Vector Consulting Group and he has been instrumental in transforming NPD environments in vast majority like auto, pharma, high tech and consumer goods. Now in almost all cases, organizations have been able to cut down lead times by half. Yes you heard me right by half while increasing the overall output of the projects. So we often refer to him as the NPD Guru at Vector. We will focus our discussion today on the auto industry and the challenges in managing new product development projects in that industry. So let's welcome Vivek, hi Vivek, welcome to the counterpoint podcast, how are you? I am good Shubham, how are you, it is a pleasure to be here. Great, great to have you here and I am very well, thank you. So Vivek, let us open the discussion with you know, first understanding what is the real issue in managing the NPD or the new product development in the auto sector. So what is your view on that? Okay, so the auto sector is one of the biggest engines of economic growth across the world. So in other words, if you want to understand how well an economy is doing, just look at the performance of the auto sector and you will get a good idea. At the same time, there is still a substantial gap between a potential demand for auto products and their supply, more so in a country like India, which still has a long way to go when it comes to per capita vehicle ownership. So it's not surprising that that auto industry in India is one of the most hotly contested one with many players vying for a share of the market. Okay, now if we take a typical auto company, it has three primary needs to be met. Need one is to continuously launch newer upgrades of its currently running models with fairly high frequency. Need two is to frequently launch completely new platforms of brands in order to address new customer segments. And what is interesting is that each of these new platforms of brands will also require the own upgrades in future, right? So it's like every new brand gives birth to its own variance over time. All right. And need three, and it's a very important need also is that auto companies have to comply with new regulatory requirements, which keep coming from time to time. And failure to meet these regulatory requirements and all of them come with a hard date. And failure to meet these deadlines would mean non-production of vehicles and loss sales. Okay, so these are the three needs primary needs for any auto company. And what this amounts to is to launch more and more products geometrically over a period of time, right? Yeah, so the compounding will keep happening. Yeah, yeah. So we have the old brands for which we need to keep launching variance upgrades from time to time. And the newer platforms that they need to launch keep coming up with from time to time. And also the regulatory environments, right? So a need for any typical auto companies to increase its output over a period of time is very, very dire, right? And to meet this geometrically multiplying need well, without geometrically multiplying its investment resources, and it's very important, right, is the biggest challenge for any automaker. And I'm sure the, you know, the priority shifts that happen between these three needs would also be quite, quite a concern, because, you know, what to prioritize, do you give priority to the new variants or the regulatory challenges? Absolutely. Absolutely. So they are always, always in, you know, in a state of confusion as to what to do, what not to do, what to build right now, where to use my capacity at this point of time, where not to use my capacity, and so on and so forth. So very obviously, I mean, these are new, not new problems. And I'm sure everyone in that sector understands it well. And so for that reason, companies must have tried to solve it, right? And they have, they would have taken different approaches, different ways to find a way around. So how do companies conventionally try to solve it? Yeah. So most NPD organizations try to meet this challenge very, very enthusiastically. People who work in these organizations have no death of intelligence and motivation. So it's not as if now India has got the best of talent in the world, right? No doubt. Yeah. So that is the despite all the hard work that they do, projects just refuse to come out. The delays are not in months, but in years. So I'm not talking about no month delay or a days delay, but the delays are in years. And the original duration has changed so many times doing the course of project that people are hard pressed to remember when a project was originally scheduled to be launched. Okay. So after every delay, a new due date is set. And there is a period of time where the project seems to be coming back on track. However, all hell breaks loose as soon as a new due dates come closer. So then suddenly it is realized in many cases that some components are still undergoing iterations. In other cases, some parts are not even close to design finalization. Some tests are still running. Right. Something or the other project is always lacking behind. And the common reference, the most common reference to the project, the most common reference. You know, I think it's going to be a long time. And the common reference, the most common reference from project management always, always is that we are progressing well, but we are still not in a position to launch at the new date. Please give us some more time. That is right. Story of every project probably. Yeah. And this story continues with delays after delay, especially if the project is extremely large for, you know, new platforms. This story is as in these delays become extremely unsustainable over a period of time. And after numerous delays and due date changes when the project is still not completing, finally the top management springs into action. It puts it for, puts the foot down and announces the launch date of project as a hard date. Now they say, no, you have to meet this hard date, no matter what. Right. And once the announcement comes, people have no choice but to come together and somehow complete the project. Now, the focus is on somehow completing the project to meet the hard due date that has been set by the top management. I'm sure there are a lot of things go haywire in that. Very, very. Absolutely. And many times these are not natural closures. These are four closures where teams have to take shortcuts or deviations in a bit to meet the deadlines. The top management also doesn't have a choice but to either approve or ignore these deviations. Right. Because it wants the project to complete. It wants something to come out fast because every month, every, every a delay of single month or a single quarter means, you know, that much loss in revenues for them. Right. So these deviations are taken at that point of time, but they very often come back to haunt the auto companies after launch in different ways. How? What are the different ways? We will have frequent line stopperages going to assembling issues, you know, now these could have been avoided had proper assembly checks and corrections been done during the NPD cycle itself. Right. Okay. Then there are supply issues of new parts from suppliers which keep coming from time to time. Again, these could have been avoided as a suppliers been provided more time to build their production capacity before launch. Then there are design problems that that that are detected much late since some tests were still running while the project was being launched. And then there are poor sale nickels coming from the field in frequent visits to service stations. So you have these, you know, R&D people who keep visiting the service stations from time to time to, you know, to resolve all the nickels which are coming from the field. Now if you look at, very interestingly, if you look at the issues that I just spoke about and what is very surprising about them is that they seem to have happened because not enough time was given to develop the product, right? Yeah. That's what comes out from those things. As I said, you know, some things could have been done. Some things could have been done during the NPD cycle itself. So they seem to have happened because not enough time was given to develop the product. Yet the product took so much time to come out in the first place, right? So that is the paradox that is a conantrum that has to be solved. So which means what? There are any additional time that was given to these projects in the past, because as I said, there were delays after delays, right, tarik after tarik. So there were delays after delays and any additional time that was given to the project, it means was not actually spent on that project. That can be the only conclusion that can come out of this, right? So where did the missing time go? If we try to understand where this missing time went, we'll be able to understand the root cause of the problem. Lovely. Because that's what we want to understand as well. And you know, since you mentioned these issues, these concerns that keep happening, I'm sure these are not one time issues, you know, these are the same issues that repeat every time, which basically means that we're not targeting the right problem, right? So what are the companies failing to get it right at the core, you know, what solutions don't work? Yeah. So Shubham, the general tendency for any company is to provide a solution for every problem that it faces, right? So when lead times are high and the projects are delayed, what do the companies believe? The companies believe that the solution lies in starting projects early, preferably as soon as the idea for a project is generated, right? So the assumption is that the earlier we initiate the project, greater the chance of projects coming out on time, right? Similarly, when technical issues are discovered late, close to due dates, when you realize that something is not working, right? Tests are failing very close to the due dates. Then companies believe that visibility is a problem, okay? So they start making more detailed project plans with stricter and more regular reviews of project milestones and the actual completions, right? planning. In proper planning, great planning, ideal planning is announced as a panacea for all else and a huge amount of time and effort is invested in planning tools. But I'm also taught that planning, good planning is the way forward. That's that's a foolproof way to complete your projects on time. Are you suggesting that this approach itself is wrong? This because this sounds logical, you know, plan well, review and go forward. What's the problem with that approach? So I will tell you, I'll tell you what's wrong with this approach. To begin with, you know, if we think logically, if I look at narrative, you know, we go back to the narrative that I, you know, was narrating to you, to begin with the projects are already delayed and the project completion rates are already poor. That is where we are starting, that is a starting point, right? What does it indicate? This indicate that the projects are spending more time in the system on an average. Right. Now, in this backdrop, where projects are already spending more time in the system, if one tries to solve the problem by introducing new projects at faster and faster rates, what would you expect to see? Right. You would naturally expect to see a build up of open projects in the system over time. Totally. Right. At the same time, as I already mentioned, companies also introduce the other so-called solution of doing great planning at a more detailed level, along with extremely stricter reviews of plans. Right. So for a company, the way to solve the problem is by having more regular reviews, you know, what used to have reviews monthly reviews are converted to weekly reviews. And that the assumption is if I do weekly reviews as opposed to monthly reviews, right? The visibility will improve and I'll be able to solve the problem faster. Right. So now we have got two things happening simultaneously. One, number of projects in the system is increasing over time, as I said, because the companies are trying to initiate projects earlier now. And number two, projects are being asked to show resources are being asked to show some progress on an increasing number of projects during the reviews. Correct. Right. Now the moment this happens, the moment this happens, the moment the resources faced with an increasing number of projects coming to him. And he's also faced with a situation where he has to show progress in each of these increasing number of projects. Right. So all of these are parallel projects. Yes. Absolutely. He has to work simultaneously, you know, practically simultaneously on all these projects. Right. And these projects also increasing over a period of time because we are trying to launch more and more, more, initiate more and more projects because of our assumptions. Right. So the moment this happens, the resources are first is first to divide the available time among too many projects. Right. Because he has to show progress everywhere. He has to keep he, they're forced to switch amongst projects and divide the available time amongst too many projects. This causes the average time that are resources pending on a project to go down. And as the average time that resources pending on a project goes down, the speed of individual projects also drops. Right. Now, if I refer back to the mystery of missing time, right, I mentioned, no, where is the time? Where is the missing time going? Now we know finally where the missing time is going. Right. As you can see, in most conventional project environments, any additional time given to a project is invariably divided amongst all the projects in the system through resource switching. Right. So it's a classic pyramid scheme in action where one project steals time from another project. So it's like saying the faster you launch new projects, the slower you make your own projects, you can say that, right? Absolutely. Absolutely. Absolutely. And any any additional time that you give to a project is actually being divided among many projects in the system because invariably, what is our resource doing is switching? Yeah. Right. So if you have given say three months, additional months to a project, rest assured that those three months are not going to be going to be used only on that project. A resource is not going to work only on that project for those three months. He's actually in an environment of, you know, regular switching, he is going to keep switching from one project to another. And therefore that time will get divided amongst too many projects, which is why I called it a classic pyramid scheme. Right. And to make the situation complex in a further complex in any auto NPT there are many design teams and suppliers and who are all have to work together in tandem on a single project. And most of these teams and suppliers are also shared across projects. Right. So when you have this environment where too many projects are entering the system and delays are multiplying, every project becomes urgent and teams are actually no way to decide which project to work on priority. Yeah. Right. Invariably what happens is that synchronization among teams suffer, which further adds to the delays. Right. And so, so as I said, there are two elements of the solution. One is start as early as possible. Another one is keep reviewing, stick to reviews, more regular reviews. They actually make the situation much worse than before. And it causes the projects to get further delayed. Right. And as the projects start getting delayed, people are forced to take shortcuts to meet time. And so it's the same story which is getting repeated again and again. Right. And these shortcuts help reduce the pressure in the short term. They do help to reduce the because you are able to show some progress by taking shortcuts, cuts in the short term. But they eventually come back to hunt the organization in the longer term in the form of issue, as I said, from the plant or the field. In fact, you know, when we go to any organization and we hear the NPD teams, you know, doing our study or diagnostics, we hear them telling us that they're spending a substantial portion of their time dealing with issues from previous launches. And this is making it difficult for them to pick up newer projects. Interesting. And because they are they are not able to pick up newer projects again, the story gets repeated. Right. Those newer projects don't. So they're further delay. Yeah. Further delay. They don't get they people don't really are not able to focus on those newer projects on time and those projects also get delayed. Right. So it's a story of a solution which actually worsens the problem rather than, you know, resolving it. Right. Probably, you know, we we often say that, you know, technology or things in the come quite late to the Indian market. I'm not sure how much this problem is adding to that particular issue. Right. What should we are starting point, so to say? Yeah. So we were talking about the conventional approaches, right, which are taken by the companies, which are supposedly solution, but they're not actually the solution. They're a part of the problem itself. Right. And the failure of all these conventional approaches lies in the fact that they do not consider the project organizations. I repeat, a project organizations capacity at all. Right. In fact, I would go further and state that most project organizations do not have a clear assessment about their capacity, their own capacity. They always tend to confuse capacity with output. When I'm projects parlance, these are two completely different terms. We can, you know, request for a quick example here because this is really interesting. How can I not know about my own capacity? Yeah. So I'll tell you why and how, how people get confused, right? And why is capacity, how is capacity defined in these kind of environments, right? So every NPD system is actually a multiproject system. Okay. Which means that the multiple projects being executed by resources was shared across projects. Okay. So you really will come across a dedicated, you know, kind of a team, which is only working on a single project in an NPD, in an NPD environment. Okay. So you have resources, teams which are shared across multiple projects. In such a multiple project system now, the speed of execution of an individual project. Okay. So it's a multiproject system. In such a system, the speed of execution of an individual project depends on the overall traffic or WRP of projects in the system. Right. So just like when you're going on the stepping on to the road, your speed of a vehicle does not depend only on the power of the vehicle. Right. It depends on the traffic that the vehicle encounters on the road. That's right. Right. Similarly, in any such multiproject system, now if you consider any project to be a vehicle, right, and capacity to be a road. Right. And the speed of execution of any individual project will depend on the overall traffic of projects in the system, which is basically a number of open projects in the system. Right. Now for such a project, for such a system to be in a stable state, what do you mean by this system being in a stable state? It means that any addition of a new project, if I'm adding a new project into the system, it should not take the attention of the resources away from the projects which already exist in the system. Okay. They should not any new project should not divert the attention of the resources away from the other project in the system. And the moment this happens, that is the addition of a single project, new project leads to slowing down of already existing projects in the system. We know that the system is unstable, and we are working on too many projects at a time. Okay. Okay. So the idea eventually is not to work on too many projects at a time, but on enough number of projects. Now, now what is the meaning of enough but not too many projects? Right. This enough but not too many projects is what we refer to as a capacity of the NPD organization. And we need to estimate this. We have got tools to estimate this enough but not too many projects before starting an engagement. Right. And all other solution elements actually rally around this assessment of capacity that we do at the beginning of every project. Right. I love the term enough but not too many projects because I think that really explains it. But you know, apart from estimating the capacity, are there other elements or what are the other elements of the solution? Yeah, absolutely. So they are this by itself, you know, this is going to go a long way in solving the problem and there are other, you know, other elements of the problem also that have to be solved. Right. So after we get a sense of the capacity, the solution that we have, it puts in mechanisms in place which basically do four things. Number one, they control the overall system WIP based on the capacity identified. So the way this is done is by balancing the inflow of projects without flow. Number two, these mechanisms ensure proper synchronization of work happening on projects across different design teams and different supplier teams. In a typical NPD large NPD project, you know, large NPD new platform kind of project, there could be as many as, you know, 50 to 60 teams design and development teams working in tandem in different locations across the country. Okay, even abroad sometime, right. So it's very important that we are able to synchronize the effort which is happening across all these teams. Right. And this is, this is made very easy. This is in fact the first element of the solution that I spoke about, which was, you know, trying to get the statement, the capacity and put in the first mechanism in place, which was, you know, controlling the inflow without flow, that makes it easy. Right. But there are some additional solution elements that we have to put in place to ensure the synchronization of work happening across all the teams. Right. And what this does, it does is to minimize the time gap between the first subsystem development and the last, you know, part development of subsystem development of any given projects. So given project will have an at least no 2030 subsystems being developed, you know, apparently across different teams. Now that if the gap between the development of the first and the last subsystem is too high, right, there are certain integration points out there. Where the projects where, you know, for example, there is vehicle assembly where all the subsystems have to come together for a testing to happen. Right. If this gap is too high, eventually enough projects is going to get delayed because then you will keep waiting for the last subsystem to come for you to assemble the vehicle. Right. So that is what is a second, you know, second mechanism that we have of ensuring proper synchronization of work. The third thing, the third mechanism that we have is to basically measure the flow of individual projects based on proper completion of activities. As I mentioned, shortcuts or deviations or compromises are a way of life in NPT environment. We have to stop that. Right. So it's very important for us to measure the flow of individual projects based on proper completion of activities and we have mechanisms in place to ensure that that is happening. And whenever the flow on a project stagnates, it triggers immediate action at a project level. Right. Right. And last but not least, mechanism four, which is very, very important is that we also identified teams where multiple projects are stuck and trigger actions to exploit and elevate the capacity of such teams. Right. Now, this is a team level intervention. This is not a project level intervention or intervention. Mechanism three that I spoke about was more of at a project level. Mechanism four is more at a team level where a team could be stuck working into many projects at the time. So that team has become, you know, kind of a constraint so as to say, right. So, so these are, you know, team level interventions that we do. So there are project level actions and also that team level actions taken depending on the signals that we get from the ground. Okay. Interesting. I mean, quite detail as well because I think those really help. So how soon have we, you know, seen the results come out. Oh, the mechanisms that are put in place cause a complete shift shift in the focus from managing individual projects to managing the overall flow of the system. Right. And the effect is seen almost immediately. The system output jumps up within no time. Depending on the context of the environment, right. So it takes maybe in an auto company, it'll take a couple of months or two to three months with the system output jump up suddenly. Right. The amount of firefighting the system reduces considerably. Okay. And that is seen immediately. That's that's seen by every person in the organization immediately. As a sort of way, the entire NPT organization gets distressed. Right. And reworks and iterations go down because you're completing the activities properly now. Right. Instances of unplanned issues close to launch day to reduce post-launch engagement of NPT resources goes down drastically because of better adherence to correct process doing the NPT cycle. And the handover to operations happens more seamlessly than before. So when a project once a project gets launched, it's like, you know, you can, you know, forget about this project for a time being at least. Irrespective, you know, which is very unlikely when like what's what used to happen the past way they used to keep coming back from time to time. Right. This must be, you know, music to the years for anyone who is going through troubled NPT environment. Yeah. Yeah. This is like heaven to him. Yeah. So could you share some of the case studies, you know, we implemented these solutions, these approach that we have taken. So vector has been engaged with multiple companies in auto sector to roll out the NPT flow management solution. And these companies belong to different segments within the auto sector. No, we have, we have engaged with a large two-ville manufacturer. Also, we have worked with a tractor major. We have worked with a prominent commercial vehicles company. We have worked with the, you know, some other organizations also across these. So in the two-millio manufacturer for instance, also we've seen across these sectors and not just in any one particular sector within the auto industry. Absolutely across segments. Yeah. So in the two-millio manufacturer for instance, you know, the output on the number of projects that were launched every year, they went up by close to 500% after two years of implementation. And the lead times went down by, you know, more than half during this time. Right. And they were also, they also found that they were able to meet all their large and small regulatory requirements. Because as I said, these regulatory requirements keep coming from time to time. And they are a huge source of interruptions to people. And people don't have an option. But to meet the dates or due dates, which are provided by, many times they are provided by the courts or the governments. Right. And they have to meet those due dates. So they were able to meet all these large and small regulatory requirements, a lot of ease. When the past, they always used to struggle meeting them. They used to take a lot of time and then all of a sudden, there used to be a lot of last-moment firefighting to ensure that they don't miss deadlines. Great. I think this is lovely. And it's really motivating as well that the NPD environments, the way we have seen them for years, is not really the way they need to manage. They are better ways and they are sustainable ways to manage them and sure. And I'm sure this discussion would be helpful to the listeners as well. Thanks a lot, Vivek. For all the listeners, if you have any doubts or concerns or questions that you have with whatever we discussed today, you can drop your questions on our social media handle. Or you can also write to us on our website. Thank you. This is Shubham signing off. [BLANK_AUDIO]