On-Time Delivery, a misnomer in New Product Development
– Nilesh Riswadkar
Hi, I am Dr Shashank. I lead Product Development at Imperial Motors, an Auto OEM. Few years ago, we embarked on a journey of transformation in our new product development department, using the guidelines and philosophy of Theory of Constraints (TOC). 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 performance. However, my bosses continue to ask me, “Shashank, 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 auto sector. It has been dogging me for over three years. It stumps even the most seasoned auto experts and consultants because the answer is not very simple.
The quest for ‘launch date’ adherence
Adhering to the launch date is important to ensure that the new product gets the full marketing work up when it makes its grand debut. For this, marketing teams have to be given plenty of time to prepare for the D day. At the same time developing a new product or new variant is a fairly complex process (refer Figure 1); so, adhering to launch dates decided a year or two in advance is always a challenge for NPD (New Product Development). This was more so at Imperial Motors where the process of NPD (New Product Development) was relatively slow.
At Imperial, invariably, the launch date would be postponed over and over again. The famous line from the film “Damini” – tareekh pe tareekh, tareekh pe tareekh seems apt here. Finally, towards the fag end of product development cycle, when we see that we are again going to miss the date (revised multiple times), 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 adherence to due date (which was anyhow moved around multiple times). The latter ensures that the new product performs as expected and brings financial rewards for the company. However, quite often, many departments at Imperial Motors were forced to compromise on scope. For instance, the research and development team and program manager could be forced to cancel development of a new color and deliver the product in the colors already available. We would do this with significant misgivings, wondering if our decision would prove costly for the company.
Is lead time reduction the solution?
I’d 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 slow pace of NPD (New Product Development) at Imperial Motors was at the root of the company’s inability to meet launch dates. So, I set out to change this. I made ‘improving speed of auto product development’ my primary objective. With the help of TOC thinking and solutions, we were able to achieve this (Read about solutions elements of TOC that enable drastic reduction of lead time).Wastage of time due to bad multitasking, rework, and interruptions was eliminated. Lead time of projects reduced significantly, and NPD output increased substantially. Consequently, 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.
Predicting project completion – a tall task
After lead times were reduced as part of the TOC initiative, the company had begun to use the new average NPD lead times as 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. Then the launch date can be planned accordingly . So, I added one more objective to my list:
1. Ensure that product development is completed as fast as possible
2. Accurately predict the lead time for product launch
Evaluating these objectives, I realized that these two have completely different goals. While objective 1 relates to process deployment for faster execution, objective 2 is about consistency in development lead times for accurately predicting project completion. Undoubtedly, to meet a launch deadline, NPD has to be fast and efficient. More importantly, however, the date has to be set accurately. This is possible if each type of product can be developed in a predictable period of time.
In order to check whether development time was consistent, I tried to understand how ’time’ had behaved in the past new product development cycles.
On studying the Imperial Motors’ new product delivery performance of five years, I observed the following:
Based on the table, I drew a few conclusions. Post TOC, lead times had crashed across product categories (objective 1 had been well achieved). However, neither pre-TOC nor post-TOC, lead times were consistent even within a product category. In fact, the lead times were always in a range. Higher the complexity (new discrete parts, new suppliers, new plant and processes, new technology, new color or new materials etc.) higher is the variation in lead times (Refer Figure 2). For instance, lead time for even a small project (like color refresh), varied between 3 and 4 months (post-TOC). The variability in development time was higher for completely new product categories. What is also important to note here is that even though the highest time taken post TOC 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, lead time of a new project can easily cross this number!
Evidently, though the deployment of TOC flow rules 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 release of concept drawings of the same part (a bracket, for instance) required for two different projects of similar category (minor product improvements) can be significantly different.
You may ask:
Why do touch times vary?
What factors in project environments affect touch time of a repetitive task?
Any NPD project environment will experience the following:
1. Variability in skill sets of resources working on the same project task (experience vs expertise)
2. Uncertainty due to varying complexity of project tasks – many more iterations than expected/planned for
3. Expanding of scope of project – Work expands while many conflicts need to be resolved before converging on project scope
All these can impact task touch times independently as well as cumulatively. It also happens that project tasks often ‘wait to be attended to’ in few of the functional resource groups (despite WIP control). 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 hidden, and eventually, add to project lead time. To summarize, project tasks experience ‘wait times’ because of
1. Queuing – variability of load vs capacity for a given resource group
2. Integration delays due to varying flow rates of multiple functional resource groups
3. Variability in natural wait times (inputs take longer time than expected)
Apart from the above, there are many other elements that also expand lead times. Examples are, variability in quality of task closures (unclean closure of intended scope) leading to rework, use of ‘time’ itself as a resource to negotiate for parts/tools costs etc. 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!
I can now answer the question Why are we unable to deliver/launch the products on an agreed launch date? This is as I said because NPD lead times are not predictable. So, what’s the way forward?
The answer hinges on how we view time in the context of project completion.
Can we not estimate time? Of course, we can, as long we understand the following:
o The estimated time is only an estimate. Estimates can change, sometimes drastically (I know this sounds obvious, but believe me, it’s not).
o Attempt 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 R&D proto shop as vendor has not supplied the parts yet.
Once we understand and internalize 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 look at Table 1 that has lead times achieved post TOC implementation. To build on this, I have grouped product categories to evaluate impact of each parameter.
This implies that variability of time is minimal and predictable when agreement on scope has fewer challenges e.g., serial nos. 1 & 2. In case of serial nos. 3 & 4, where converging on scope requires multiple iterations (across program, design and engineering, marketing and so on) which cannot be pre-determined, trying to adhere to launch date (even a range) is akin to chasing a mirage. Hence, when these products are in concept phase, the ONLY option is to focus on faster execution (objective 1) instead of trying to arrive at some ‘accurate estimate’ of launch date (objective 2).
This can be achieved by
1. Creating visibility on conflicts and iterations – keep checking speed of convergence
2. Pro-actively cutting Parkinson (expansion of time) by high frequency observations and decision making
3. Assessing the impact of above two on short-term expectations (vehicle layout completion, mock-up build etc.)
In the concept phase, when convergence on scope takes too long and a solution doesn’t evolve in spite of multiple iterations, product viability/feasibility may be challenged. On the other hand, only scope finalization in terms of initial vehicle layout/digital mock-up in itself doesn’t guarantee product viability unless product is physically seen and undergoes one round of quality check (exhaustive vehicle testing). Hence, the process to arrive at the best estimate of launch date (range) for serial nos. 3&4 (major product improvements and new product) is as per figure 3 and table 3.
Lead times of specific complex NPD projects can be known accurately 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 actual status of product development (phase the product is in). Year, and specific quarter within that financial year for the launch can be arrived at using the above guidelines.
ⅰ Sometimes launch dates come as ‘diktats’ from the top. However, if lead times could be known upfront and are seen to be short, the team can take necessary steps like hiring extra resources.