Episode 32
New product development in auto sector : Challenges & Solutions
Category : High Variability Operations
Enormous workload, high uncertainty and heavy dependence on external suppliers all have together made the task of new product development in the auto segment very challenging and stressful. The process is riddled with rework, problems in production stabilisation, and delays in launch. However, by questioning the traditional paradigms of project management and resolving the core conflict in this environment, NPD lead times can reduce by as much as half. Find out how auto NPD can be managed to meet stakeholders’ expectations, click here: https://www.vectorconsulting.in/research-publications/auto-auto-components/de-stressing-npd/
Transcript
| Shubham Agarwal : | 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’m 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 Statista, as much as 91% of the NPD projects fail to complete, or go way beyond the scheduled time. Now, this is not shocking, I think everyone across knows that this is a common phenomenon. And it’s troubling because NPD is what decides the future for any organization, because that’s the new product, or anything new that’s 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’s 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’ll 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? |
| Vivek Chopra : | I’m good for them. How are you? It’s a pleasure to be here. |
| Shubham Agarwal : | Great, Vivek. Great to have you here. And I’m very well thank you. So, Vivek, let us open the discussion with you know, first understanding, what’s the real issue in managing the NPD or the new product development in the auto sector. So what’s what’s your view on that? |
| Vivek Chopra : | 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’s 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 potential demand for auto products and their supply, mostly 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 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 you take a typical auto company, it has three primary needs to be met. Need one is to continuously launch new or upgrades of its currently learning 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 or brands will also require their own upgrades in future, right. So it’s like every new brand gives birth to its own variance over time. And need three, and it’s 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 lost sales. Okay, so these are the three needs primary needs for any auto company. Right? And what this amounts to, is to launch more and more products geometrically over a period of time, right |
| Shubham Agarwal : | Yeah so the compounding will keep happening. |
| Vivek Chopra : | Yeah, so we have the old brands, so that you need to keep launching variance upgrades from time to time, we also have the newer platforms that they need to know launch keep coming up with from time to time, and also the regulatory environments, right. So a need for any typical auto company is 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, it’s very important is the biggest challenge for any automaker. |
| Shubham Agarwal : | 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 new variants are the regulatory challenges right |
| Vivek Chopra : | Absolutely, so they are always always in, you know, in a, 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. |
| Shubham Agarwal : | Right? So, Vivek obviously, I mean, these are 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? |
| Vivek Chopra : | Yeah, so most NPD organizations try to meet this challenge very, very enthusiastically. People who work in these organizations have no dearth of intelligence and motivation. So it’s not as of now, India has got the best of talent in the world, right. So but soon, they realized that despite all the hard work that they do, projects just refused 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 due dates are changed so many times during the course of a 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, right. And there is a period of time where the project seems to be coming back on track. So I’m telling the story that I keep encountering time after time in our clients, right? So after every delay , a new due date is set, and there’s 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 integrations. In other cases, some parts are not even close to design finalization, some tests are still running, right, something or the other in the project is always lagging behind. And the common refrain is the most common refrain 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. |
| Shubham Agarwal : | Story of every project probably |
| Vivek Chopra : | Yeah and this story continues with delays after delay, especially if the project is extremely large. For 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 the foot down and announces the launch date of project as a hard date. Now they say no you need to meet this hard date no matter what. 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 said by the top management. |
| Shubham Agarwal : | I’m sure that a lot of things go haywire in that. |
| Vivek Chopra : | Very very, absolutely. And many times these are not natural closures. These are forced closures where teams have to take shortcuts or deviations in a bid to meet the deadlines. The top management also doesn’t have a choice but to either approve or ignore these deviations right because once a project to complete it wants something to come out fast. Because every month 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 in the interest of time, but at that point of time, but they very often come back to haunt the auto companies after launch in different ways. What are the different ways. So we will have frequent line stoppages going to assembling issues, you know, now this could have been avoided had proper assembly checks and corrections been done during the NPD cycle itself, right? Okay. Then there’s supply issues of new parts from suppliers which keep coming from time to time. Again, these could have been avoided as suppliers been provided more time to build their production capacity before launch, then there are design problems that that detected much late since some tests was still running while the project was being launched. And then the post sale niggles is 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 resolve all the niggles 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 some things could have been done, some things could have been done during the NPD cycle itself. So they seem to happen, 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 conundrum that has to be solved. So which means what that any additional time that was given to these projects in the past, because because as I said, there were delays after delays, right taarik after taarik. So there are 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. 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. |
| Shubham Agarwal : | 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, these are the same issues that repeat every time, which basically means that we’re not targeting the right, right problem. Right? |
| Vivek Chopra : | Corect. Right. |
| Shubham Agarwal : | So what are the companies failing to get it right at the core, you know, what, what solutions don’t work? |
| Vivek Chopra : | So Shubham, the general tendency for any company is to provide a solution for every problem that it faces. Right, right. So when lead times are high, and projects are delayed, what do the companies believe, the companies believe that the solution lies in starting projects early, preferably, as soon as 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 something’s 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. Proper planning, no improper planning, great planning, ideal planning is announced as a panacea for all ills. And a huge amount of time and effort is invested in planning tools |
| Shubham Agarwal : | Right. But I’m also taught that, you know, planning, good planning is the way forward. That’s that’s a foolproof way to, you know, 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 point? |
| Vivek Chopra : | So I’ll tell you, I’ll tell you what’s wrong with this approach. To begin with, you know, if you think logically, if I look at narrative, we go back to the narrative that I 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. Now, in this backdrop, where projects are already spending more time in the system, if one tries to solve the problem by introducing newer projects at faster and faster rates, what would you expect to see? Right, you would naturally expect to see a buildup of open projects in the system over time. |
| Shubham Agarwal : | Totally. |
| Vivek Chopra : | At the same time, as I already mentioned, companies also introduce 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. Yeah, 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. |
| Shubham Agarwal : | Correct. |
| Vivek Chopra : | So now we have got two things happening simultaneously. One number of projects in the system is increasing over time, as I said, because companies are trying to launch projects earlier now. 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. Right, now the moment this happens, the moment, resources faced with an increasing number of projects coming to him and he’s also to face with a situation where he has to show progress in each of these increasing number of projects. Right? |
| Shubham Agarwal : | So all of these are parallel projects. |
| Vivek Chopra : | Yes, absolutely, he has to work simultaneously, 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, initiate more and more projects, because of our of our assumptions. So the moment, this happens the resources are forced to divide the available time among too many projects. Because he has to show progress everywhere, they’re forced to switch amongst projects, and then divide the available time amongst too many projects. This causes the average time that the resource is spending on a project to go down. And as the average time the resource is spending 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 that? Where’s the missing time going? Now we know finally, where the missing time was going. 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, I’d say it’s a classic pyramid scheme in action, where one project steals time from another project. |
| Shubham Agarwal : | So it’s like saying the faster you launch new projects, the slower you make your own projects, you can say that right? |
| Vivek Chopra : | Absolutely, absolutely, absolutely. And any any additional time that he gives to a project is actually being divided among many projects in the system, because invariably, what is the 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 the going to be used only on that project resources, not going to work only on that project for those three months, is actually in the 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. And to make the situation complex in a further complex in any auto NPD, there are many design teams and suppliers. And we’re 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 have 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, you know, two elements of the solution, one is start as early as possible. Another one is keep reviewing, stricter reviews, more regular reviews, they actually make the situation much worse than before, it causes a project to get further delayed, right. And as the project start getting delayed, people are forced to take shortcuts to meet time. So it’s the same story, which is getting repeated again and again. Right, right. And these shortcuts help reduce the pressure in the short term, they do help to reduce because you’re able to show some progress, right, by taking shortcuts or cuts in the short term. But they eventually come back to haunt 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. Right. And, and because, they are not able to pick up new projects. Again, the story gets repeated, right, there are further delays. Yeah, further, they don’t get the people don’t really are not able to focus on those new 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. |
| Shubham Agarwal : | Right, probably, you know, we often say that, you know, a technology or things come quite late to the Indian market. I’m not sure how much this problem is adding to that particular issue. |
| Vivek Chopra : | A lot, a lot. |
| Shubham Agarwal : | Right. What should be a starting point, so to say. |
| Vivek Chopra : | Yeah, so, we were talking about the conventional approaches, right, which are defined by the companies, which are supposedly solution but they’re not actually the solution, there are 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 and I repeat a project organizations capacity at all right? In fact, I would go further and state than most project organizations do not have a clear assessment about their capacity, their own capacity. They always tend to confuse capacity with output while in projects parallace these are two completely different terms. |
| Shubham Agarwal : | Vivek can I can I, you know, request for a quick example here because this is really interesting. How can I not know about my own capacity? |
| Vivek Chopra : | Yeah, so I’ll tell you why and how, how people get confused and how is capacity defined in these kind of environments right? |
| Shubham Agarwal : | Okay. |
| Vivek Chopra : | So, every NPD system is actually a multi project system okay, which means that there are multiple projects being executed by resources which are 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 environment, right. 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 multi project system in such a system, the speed of execution of an individual project depends on the overall traffic or WIP of projects in the system. Right. So, just like when you’re going on stepping onto 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. |
| Shubham Agarwal : | That’s right. |
| Vivek Chopra : | Right. Similarly, in any such multi project systems, now, if you consider any project to be a vehicle, right, and the 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. Yeah, right. Now, 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 project which already exists in the system, any new position should not divert the attention or resources away from the other 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? Yeah, this enough, but not too many projects is what we refer to as the 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 any engagement, right. And all other solution elements actually rally around this assessment of capacity that we do at the beginning of every project, |
| Shubham Agarwal : | 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? |
| Vivek Chopra : | Yeah, absolutely. So, this by itself, you know, this is going to go a long way in solving the problem, but there are other elements of the problem also that have to be resolved right. So, after we get a sense of the capacity, and 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 with the out 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 and a 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 and 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 a 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 estimate the capacity and putting the first mechanism in place, which was you know, controlling the inflow with out 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 it minimize the time gap between the first subsystem development and the last you know, part development or subsystem development of any given projects. So, a given project will have an at least 20-30 subsystems being developed, you know, parallely across different different teams. Now, the if the gap between the development of the first and the last subsystem is too high, right, there are certain integration points out there in the projects, where we know, for example, this vehicle assembly where all the subsystems have to come together for testing to happen right, if this gap is too high, eventually the project is going to get delayed, because then we will keep waiting for the last subsystem to come for you to assemble the vehicle right. So, that is what is a second no 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 NPD 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. And last but not least mechanism four which is very, very important is that we also identify teams where multiple projects are stuck and trigger actions to exploit an elevate the capacity of such teams. Right now, this is a team level intervention, this is not a project level intervention. Mechanism three that I spoke about was more of a project level mechanism four is more at a team level where a team could be stuck working on too many projects at a time. So that team has become, you know, kind of a constrain so as to say, right. So these are 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. |
| Shubham Agarwal : | Okay, interesting. I mean, quite detailed as well, because I think those really help. So, how soon have we you know, seen the results come out? |
| Vivek Chopra : | Oh, the mechanisms that are put in place, caused a complete 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 will take a couple of months or two to three months for the system to jump up. Right? The amount of firefighting, in the system reduces considerably, okay. And that is seen immediately. Okay, that’s, that’s seen by every person in the organization immediately, as a result of this the entire NPD organization gets de stressed, right, and reworks and iterations go down, because you’re completing the activities properly now. Right? Instances of unplanned issues close to launch day are reduced. Post launch engagement of NPD resources goes down drastically, because of better adherence to correct process during the NPD cycle. And the handover to operations happens more seamlessly than before. So once a project gets launched, it’s like, you know, you can, you know, forget about this project for the time being, at least irrespective, you know, which is very unlikely when, like, what used to happen the past way, they used to keep coming back from time to time. |
| Shubham Agarwal : | Right. This must be, you know, music to the ears, for anyone who is going through troubled NPD environment. |
| Vivek Chopra : | Yeah . Yeah, this is like heaven to him. |
| Shubham Agarwal : | Yeah. So, could you share some of the case studies, you know, where we implemented these solutions, these approach that we have taken. |
| Vivek Chopra : | So, Vector has been engaged in multiple companies in auto sector to roll out the NPD for management solution, and these companies belong to different segments within the auto sector. You know, we have engaged with a large two wheeler manufacturer. Also, we have worked with a tractor major. We have worked with a prominent commercial vehicles company, we have worked with some of the organizations also across these. |
| Shubham Agarwal : | Oh so you have seen this across the sector’s and not just in any one particular sector within the auto industry. |
| Vivek Chopra : | Absolutely. Across segments. Yeah. So in the two wheeler manufacturer, for instance, you know, the output or the number of projects that were launched, every year, they went up by close to 500%, after two years of implementation, and lead times went down by you know more than half during this time. 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, they are a huge source of interruptions to people and, and people don’t have an option but to meet the dates or due dates, which are provided by many times provided by the courts or the governments and they have to meet those due dates. So they were able to meet all these large and small regulatory requirements with a lot of ease when in 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 the deadlines. |
| Shubham Agarwal : | Great, Vivek, 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 be manage. There are better ways and there are sustainable ways to manage them 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. |
Comments
Related Information
Get in touch
Registered Office:
Vector Management Consulting Pvt. Ltd.
10th floor, Thane One, DIL Complex,
Ghodbunder Road, Majiwada,
Thane (West), Maharashtra - 400610, India.
Vector Management Consulting Pvt. Ltd.
10th floor, Thane One, DIL Complex,
Ghodbunder Road, Majiwada,
Thane (West), Maharashtra - 400610, India.