“Hi, I am Dr Shashank. I lead Product Development at Imperial Motors, an <a target="_blank" rel="noopener noreferrer" href="https://www.vectorconsulting.in/en/research-and-publication/articles/an-sos-for-the-oems/">Auto OEM</a>. A few years ago, we began a transformation journey in our New Product Development (NPD) department, applying flow-based principles to project management. Subsequently, we’ve achieved substantial improvement in both product delivery (a whopping 400% jump in output) and in product launch lead times (40%-50% reduction).  The Board members and the top management are now quite pleased with NPD’s performance. However, my bosses continue to ask me that why are we not able to deliver/launch products on an agreed ‘launch date’?  This is one of the most frequently asked questions in the world of product development for the auto sector. It has been dogging me for over three years. It stumps up even the most seasoned auto experts and consultants because the answer is not very simple.” <h5>The quest for ‘launch date’ adherence</h5>Adhering to the launch date is important to ensure that the new product receives comprehensive marketing preparation when it makes its grand debut. For this, marketing teams must be given plenty of time to build up for the D-Day. However, due to the fairly complex process of developing a new product or new variant (refer Figure 1), adhering to launch dates decided a year or two in advance is always a challenge. This was more so at Imperial Motors where the NPD process was relatively slow.<figure class="image"><img style="aspect-ratio:16668/9147;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//ot-blog-4-img-1-01-01-01-01-01-1738074478_1777269079.png" width="16668" height="9147"></figure>“At Imperial, invariably, the launch date would be postponed repeatedly. The famous line from the film ‘Damini’– “tareekh pe tareekh, tareekh pe tareekh” seems apt here. Finally, towards the fag end of the product development cycle, when we see that we are going to miss the date (revised multiple times) again, we would be forced to compromise on scope.”   Scope compromise is counterproductive. It defeats the very purpose of developing and releasing a new product into the market. Fulfilling the defined scope is more important than adhering to the due date (which was moved around multiple times anyway). It ensures that the new product performs as expected and brings financial rewards to the company. However, many departments at Imperial Motors were often forced to compromise on scope. For instance, the research and development team and program manager would be forced to cancel the development of a new colour and deliver the product in the colours already available. We would do this with significant misgivings, wondering if our decision would prove costly for the company.   <h5>Is lead time reduction the solution? </h5>“I always believed that reducing lead times would be the answer to the conflict between meeting deadlines and ensuring scope. Unfortunately, that belief has been proven false. I now see that the two are not necessarily linked. Let me explain how I came to this conclusion:  I believed that the slow pace of the NPD process at Imperial Motors was the root cause of the company’s inability to meet launch dates. So, I set out to change this. I made ‘improving the speed of auto product development’ my primary objective. Using flow management principles, we were able to drastically reduce the lead time, by minimising wastage of time due to bad multitasking, reworks, and interruptions. The NPD output increased substantially and most short-term projects were completed as planned. However, we were still unable to launch new products as per originally scheduled launch dates! The dates were being revised fewer times than before, but they were still being revised.” <h5>Predicting project completion – a tall task </h5>After lead times were reduced due to the use of flow management principles, the company began to use the new average NPD lead times as a reference for deciding launch dates. I wondered if the dates were now too aggressive. Speed is important, but that alone isn’t enough to ensure that projects are delivered on the expected due date. It is important for us to know upfront when a project will be completed. This helps in planning the launch date accordingly. So, I added one more objective to my list: <ol style="list-style-type:decimal;"><li>Ensure that product development is completed as quickly as possible.</li><li>Accurately predict the lead time for product launch.</li></ol> Evaluating the objectives, I realised that these two have completely different goals. While objective 1 relates to process deployment for faster execution, objective 2 focusses on consistency in development lead times enabling accurate prediction of project completion. Undoubtedly, to meet a launch deadline, NPD must be fast and efficient. But more importantly, the date must be set accurately. This is possible if each type of product can be developed within a predictable timeframe.  To check whether development time was consistent, I tried to understand how ’time’ had behaved in the past new product development cycles, i.e. before the implementation of flow management principles. On studying Imperial Motors’ new product delivery performance over five years, I observed the following: <figure class="image"><img style="aspect-ratio:16668/10066;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//ot-blog-4-img-2-01-01-01-1738074497_1777269711.png" width="16668" height="10066"></figure>Based on the table, I drew a few conclusions. Post-implementation, lead times had crashed across product categories (objective 1 had been well achieved). However, in neither scenarios, lead times were consistent even within a product category. In fact, the lead times were always in a range. If the complexity is higher (new discrete parts, new suppliers, new plants and processes, new technology, new colours, or new materials etc.), the variation in lead times is also higher (Refer Figure 2). For instance, the lead time for even a small project (like a colour refresh) varied between 3 and 4 months (post-implementation). The variability in development time was higher for completely new product categories. What is also important to note here is that although the highest time taken post-implementation for a completely new product development is 24 months, it is not the upper limit of lead time for any new product. Depending on the scope and complexity of the development, the lead time of a new project can easily cross this number!”  <figure class="image"><img style="aspect-ratio:16668/10220;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//ot-blog-4-img-3-01-01-1738074507_1777269300.png" width="16668" height="10220"></figure><h5>Inherent uncertainty </h5>Although the deployment of  flow management principles has ensured that tasks are completed very close to ‘touch time’ (without interruption or rework), this touch time cannot be accurately known beforehand. For example, the touch time for the release of concept drawings of the same part (a bracket, for instance) required for two different projects of similar categories (minor product improvements) can be significantly different.” <ul style="list-style-type:disc;"><li>Why do touch times vary?</li><li>What factors in project environments affect the touch time of a repetitive task?</li></ul> Any NPD project environment will experience the following:<ol style="list-style-type:decimal;"><li>Variability in skill sets of resources working on the same project task (experience vs expertise).</li><li>Uncertainty due to the varying complexity of project tasks – many more iterations than expected/planned for.</li><li>Expansion in scope of project – The work expands, while many conflicts need to be resolved before converging on the project scope. </li></ol> All these factors can impact task touch times independently as well as cumulatively. It is also seen that project tasks often ‘wait to be attended to’ in a few of the functional resource groups (despite limiting the number of projects/tasks worked upon at a time). At times, inputs from internal groups (support groups like Finite Element Analysis, CFD, patent check, etc.) or external groups (like suppliers/vendors, process engineering, etc.) take longer than expected (this expands task execution times). These wait times are often hidden and can eventually, add to the project lead time. To summarise, project tasks experience ‘wait times’ because of  <ol style="list-style-type:decimal;"><li>Queuing – variability of load vs capacity for a given resource group.</li><li>Integration delays due to varying flow rates of multiple functional resource groups.</li><li>Variability in natural wait times (inputs take longer than expected.</li></ol> Apart from the above factors, several other elements also contribute to the expansion of lead times. Examples include variability in the quality of task closures (e.g. unclean closure of the intended scope), leading to rework, and the use of ‘time’ itself as a resource to negotiate for the cost of parts/tools among others. Such uncertainties are inherent to every project.  This means that touch times cannot be predicted. The NPD lead time of any project is only accurately known in hindsight! <h5>Way forward </h5>I can now answer the question 'Why are we unable to deliver/launch the products on an agreed launch date?’ This occurs because NPD lead times are unpredictable. So, what’s the way forward?  The answer hinges on how we view time in the context of project completion.  Can we not estimate the time? Of course, we can, if we understand the following:  <ul style="list-style-type:disc;"><li>The estimated time is only an estimate. It can change, sometimes drastically (I know this sounds obvious, but believe me, it’s not).</li><li>Attempting to meet milestones (for example, Vehicle Build for design verification) by force-fitting to the estimated timelines can lead to compromises in execution. Efforts can backfire on either the project scope or quality. For example, vehicle assembly can be done with discrete parts managed through the R&D proto shop as the vendor has not supplied the parts yet. </li></ul> Once we understand and internalise the above, we can get to the business of trying to find the way to get the ‘best estimate’ (Please note that 'best’ is still an estimate). As a starting point, let’s examine Table 1 which shows lead times achieved post-implementing rapid flow management principles. To build on this, I have grouped product categories to evaluate the impact of each parameter.  <figure class="image"><img style="aspect-ratio:16668/8956;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//ot-blog-4-img-4-01-01-01-01-01-1738074516_1777269218.png" width="16668" height="8956"></figure>This implies that the variability of time is minimal and predictable when there is agreement on scope has fewer challenges e.g., serial nos. 1 & 2. In the case of serial nos. 3 & 4, where converging on scope requires multiple iterations (across the program, design, engineering, marketing and so on) which cannot be predetermined, trying to adhere to launch a date (even a range) is akin to chasing a mirage. Hence, when these products are in the concept phase, the ONLY option is to focus on faster execution (objective 1) instead of trying to arrive at some ‘accurate estimate’ of the launch date (objective 2).  This can be achieved by <ol style="list-style-type:decimal;"><li>Creating visibility on conflicts and iterations – keep checking the speed of convergence.</li><li>Proactively cutting Parkinson (expansion of time) by high-frequency observations and decision-making.</li><li>Assessing the impact of the above two on short-term expectations (vehicle layout completion, mock-up build, etc.)</li></ol> In the concept phase, when convergence on scope takes too long and a solution doesn’t evolve despite multiple iterations, product viability/feasibility may be challenged. On the other hand, only scope finalisation in terms of initial vehicle layout/digital mock-up doesn’t guarantee product viability unless the product is physically seen and undergoes one round of quality checks (exhaustive vehicle testing). Hence, the process to determine the best estimate of the launch date (range) for serial nos. 3 & 4 (major product improvements and new product) are shown in Figure 3 and Table 3.   <figure class="image"><img style="aspect-ratio:16668/9947;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//ot-blog-4-img-5-01-01-01-01-1738074528_1777269767.png" width="16668" height="9947"></figure><figure class="image"><img style="aspect-ratio:16668/12722;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//ot-blog-4-img-6-01-01-01-01-1738074546_1777269377.png" width="16668" height="12722"></figure> <figure class="image"><img style="aspect-ratio:16668/10220;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//ot-blog-4-img-6-1-01-01-01-1738074557_1777269512.png" width="16668" height="10220"></figure>Final word  Lead times for specific complex NPD projects can be accurately known only in hindsight. In foresight, only rough estimates are possible. However, in annual business planning (for major product improvements and new products), companies can estimate launches based on the actual status of product development (phase the product is in). The year and specific quarter within a financial year for the launch can be arrived at using the above guidelines.

BAHASA Read More

Problem: This is the case of Imperial Motors’ whose NPD team struggled to meet agreed launch dates despite cutting lead times and boosting output, forcing repeated postponements and scope compromises. Unpredictable task touch times, resource variability, and hidden wait times made project completion inherently uncertain. Solution: Applied flow-based project management to speed execution and reduce waste while analysing variability drivers across product categories. Shifted focus from rigid dates to faster execution, scope convergence visibility, and best-estimate launch ranges. Results: Output rose 400% and launch lead times fell 40%–50%, delighting top management. NPD gained speed, predictability for simpler projects, and a practical framework to set realistic launch expectations for complex ones.

Key Takeaways

In auto NPD, lead times can be reduced; however, predicting them accurately is difficult. The way forward involves understanding that time estimates are subject to change and focusing on achieving the best possible estimate based on the current phase of product development.

On-time delivery, a misnomer in new product development

“Hi, I am Dr Shashank. I lead Product Development at Imperial Motors, an <a target="_blank" rel="noopener noreferrer" href="https://www.vectorconsulting.in/en/research-and-publication/articles/an-sos-for-the-oems/">Auto OEM</a>. A few years ago, we began a transformation journey in our New Product Development (NPD) department, applying flow-based principles to project management. Subsequently, we’ve achieved substantial improvement in both product delivery (a whopping 400% jump in output) and in product launch lead times (40%-50% reduction).  The Board members and the top management are now quite pleased with NPD’s performance. However, my bosses continue to ask me that why are we not able to deliver/launch products on an agreed ‘launch date’?  This is one of the most frequently asked questions in the world of product development for the auto sector. It has been dogging me for over three years. It stumps up even the most seasoned auto experts and consultants because the answer is not very simple.” <h5>The quest for ‘launch date’ adherence</h5>Adhering to the launch date is important to ensure that the new product receives comprehensive marketing preparation when it makes its grand debut. For this, marketing teams must be given plenty of time to build up for the D-Day. However, due to the fairly complex process of developing a new product or new variant (refer Figure 1), adhering to launch dates decided a year or two in advance is always a challenge. This was more so at Imperial Motors where the NPD process was relatively slow.<figure class="image"><img style="aspect-ratio:16668/9147;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//ot-blog-4-img-1-01-01-01-01-01-1738074478_1777269058.png" width="16668" height="9147"></figure>“At Imperial, invariably, the launch date would be postponed repeatedly. The famous line from the film ‘Damini’– “tareekh pe tareekh, tareekh pe tareekh” seems apt here. Finally, towards the fag end of the product development cycle, when we see that we are going to miss the date (revised multiple times) again, we would be forced to compromise on scope.”   Scope compromise is counterproductive. It defeats the very purpose of developing and releasing a new product into the market. Fulfilling the defined scope is more important than adhering to the due date (which was moved around multiple times anyway). It ensures that the new product performs as expected and brings financial rewards to the company. However, many departments at Imperial Motors were often forced to compromise on scope. For instance, the research and development team and program manager would be forced to cancel the development of a new colour and deliver the product in the colours already available. We would do this with significant misgivings, wondering if our decision would prove costly for the company.   <h5>Is lead time reduction the solution? </h5>“I always believed that reducing lead times would be the answer to the conflict between meeting deadlines and ensuring scope. Unfortunately, that belief has been proven false. I now see that the two are not necessarily linked. Let me explain how I came to this conclusion:  I believed that the slow pace of the NPD process at Imperial Motors was the root cause of the company’s inability to meet launch dates. So, I set out to change this. I made ‘improving the speed of auto product development’ my primary objective. Using flow management principles, we were able to drastically reduce the lead time, by minimising wastage of time due to bad multitasking, reworks, and interruptions. The NPD output increased substantially and most short-term projects were completed as planned. However, we were still unable to launch new products as per originally scheduled launch dates! The dates were being revised fewer times than before, but they were still being revised.” <h5>Predicting project completion – a tall task </h5>After lead times were reduced due to the use of flow management principles, the company began to use the new average NPD lead times as a reference for deciding launch dates. I wondered if the dates were now too aggressive. Speed is important, but that alone isn’t enough to ensure that projects are delivered on the expected due date. It is important for us to know upfront when a project will be completed. This helps in planning the launch date accordingly. So, I added one more objective to my list: <ol style="list-style-type:decimal;"><li>Ensure that product development is completed as quickly as possible.</li><li>Accurately predict the lead time for product launch.</li></ol> Evaluating the objectives, I realised that these two have completely different goals. While objective 1 relates to process deployment for faster execution, objective 2 focusses on consistency in development lead times enabling accurate prediction of project completion. Undoubtedly, to meet a launch deadline, NPD must be fast and efficient. But more importantly, the date must be set accurately. This is possible if each type of product can be developed within a predictable timeframe.  To check whether development time was consistent, I tried to understand how ’time’ had behaved in the past new product development cycles, i.e. before the implementation of flow management principles. On studying Imperial Motors’ new product delivery performance over five years, I observed the following: <figure class="image"><img style="aspect-ratio:16668/10066;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//ot-blog-4-img-2-01-01-01-1738074497_1777269680.png" width="16668" height="10066"></figure>Based on the table, I drew a few conclusions. Post-implementation, lead times had crashed across product categories (objective 1 had been well achieved). However, in neither scenarios, lead times were consistent even within a product category. In fact, the lead times were always in a range. If the complexity is higher (new discrete parts, new suppliers, new plants and processes, new technology, new colours, or new materials etc.), the variation in lead times is also higher (Refer Figure 2). For instance, the lead time for even a small project (like a colour refresh) varied between 3 and 4 months (post-implementation). The variability in development time was higher for completely new product categories. What is also important to note here is that although the highest time taken post-implementation for a completely new product development is 24 months, it is not the upper limit of lead time for any new product. Depending on the scope and complexity of the development, the lead time of a new project can easily cross this number!”  <figure class="image"><img style="aspect-ratio:16668/10220;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//ot-blog-4-img-3-01-01-1738074507_1777269278.png" width="16668" height="10220"></figure><h5>Inherent uncertainty </h5>Although the deployment of  flow management principles has ensured that tasks are completed very close to ‘touch time’ (without interruption or rework), this touch time cannot be accurately known beforehand. For example, the touch time for the release of concept drawings of the same part (a bracket, for instance) required for two different projects of similar categories (minor product improvements) can be significantly different.” <ul style="list-style-type:disc;"><li>Why do touch times vary?</li><li>What factors in project environments affect the touch time of a repetitive task?</li></ul> Any NPD project environment will experience the following:<ol style="list-style-type:decimal;"><li>Variability in skill sets of resources working on the same project task (experience vs expertise).</li><li>Uncertainty due to the varying complexity of project tasks – many more iterations than expected/planned for.</li><li>Expansion in scope of project – The work expands, while many conflicts need to be resolved before converging on the project scope. </li></ol> All these factors can impact task touch times independently as well as cumulatively. It is also seen that project tasks often ‘wait to be attended to’ in a few of the functional resource groups (despite limiting the number of projects/tasks worked upon at a time). At times, inputs from internal groups (support groups like Finite Element Analysis, CFD, patent check, etc.) or external groups (like suppliers/vendors, process engineering, etc.) take longer than expected (this expands task execution times). These wait times are often hidden and can eventually, add to the project lead time. To summarise, project tasks experience ‘wait times’ because of  <ol style="list-style-type:decimal;"><li>Queuing – variability of load vs capacity for a given resource group.</li><li>Integration delays due to varying flow rates of multiple functional resource groups.</li><li>Variability in natural wait times (inputs take longer than expected.</li></ol> Apart from the above factors, several other elements also contribute to the expansion of lead times. Examples include variability in the quality of task closures (e.g. unclean closure of the intended scope), leading to rework, and the use of ‘time’ itself as a resource to negotiate for the cost of parts/tools among others. Such uncertainties are inherent to every project.  This means that touch times cannot be predicted. The NPD lead time of any project is only accurately known in hindsight! <h5>Way forward </h5>I can now answer the question 'Why are we unable to deliver/launch the products on an agreed launch date?’ This occurs because NPD lead times are unpredictable. So, what’s the way forward?  The answer hinges on how we view time in the context of project completion.  Can we not estimate the time? Of course, we can, if we understand the following:  <ul style="list-style-type:disc;"><li>The estimated time is only an estimate. It can change, sometimes drastically (I know this sounds obvious, but believe me, it’s not).</li><li>Attempting to meet milestones (for example, Vehicle Build for design verification) by force-fitting to the estimated timelines can lead to compromises in execution. Efforts can backfire on either the project scope or quality. For example, vehicle assembly can be done with discrete parts managed through the R&D proto shop as the vendor has not supplied the parts yet. </li></ul> Once we understand and internalise the above, we can get to the business of trying to find the way to get the ‘best estimate’ (Please note that 'best’ is still an estimate). As a starting point, let’s examine Table 1 which shows lead times achieved post-implementing rapid flow management principles. To build on this, I have grouped product categories to evaluate the impact of each parameter.  <figure class="image"><img style="aspect-ratio:16668/8956;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//ot-blog-4-img-4-01-01-01-01-01-1738074516_1777269104.png" width="16668" height="8956"></figure>This implies that the variability of time is minimal and predictable when there is agreement on scope has fewer challenges e.g., serial nos. 1 & 2. In the case of serial nos. 3 & 4, where converging on scope requires multiple iterations (across the program, design, engineering, marketing and so on) which cannot be predetermined, trying to adhere to launch a date (even a range) is akin to chasing a mirage. Hence, when these products are in the concept phase, the ONLY option is to focus on faster execution (objective 1) instead of trying to arrive at some ‘accurate estimate’ of the launch date (objective 2).  This can be achieved by <ol style="list-style-type:decimal;"><li>Creating visibility on conflicts and iterations – keep checking the speed of convergence.</li><li>Proactively cutting Parkinson (expansion of time) by high-frequency observations and decision-making.</li><li>Assessing the impact of the above two on short-term expectations (vehicle layout completion, mock-up build, etc.)</li></ol> In the concept phase, when convergence on scope takes too long and a solution doesn’t evolve despite multiple iterations, product viability/feasibility may be challenged. On the other hand, only scope finalisation in terms of initial vehicle layout/digital mock-up doesn’t guarantee product viability unless the product is physically seen and undergoes one round of quality checks (exhaustive vehicle testing). Hence, the process to determine the best estimate of the launch date (range) for serial nos. 3 & 4 (major product improvements and new product) are shown in Figure 3 and Table 3.   <figure class="image"><img style="aspect-ratio:16668/9947;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//ot-blog-4-img-5-01-01-01-01-1738074528_1777269806.png" width="16668" height="9947"></figure><figure class="image"><img style="aspect-ratio:16668/12722;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//ot-blog-4-img-6-01-01-01-01-1738074546_1777269356.png" width="16668" height="12722"></figure> <figure class="image"><img style="aspect-ratio:16668/10220;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//ot-blog-4-img-6-1-01-01-01-1738074557_1777269471.png" width="16668" height="10220"></figure>Final word  Lead times for specific complex NPD projects can be accurately known only in hindsight. In foresight, only rough estimates are possible. However, in annual business planning (for major product improvements and new products), companies can estimate launches based on the actual status of product development (phase the product is in). The year and specific quarter within a financial year for the launch can be arrived at using the above guidelines.