Key Takeaways

Businesses rely on the New Product Development process to grow. However, the process is stressful for companies. Is there a way to de-stress it? New Product development processes can be de-stressed to meet all stakeholder expectations in terms of cost and delivery deadlines

De-stressing NPD

“In this world nothing is certain except for death and taxes.” If this quote by Benjamin Franklin were to be examined by an NPD head, he may well be tempted to add “project delays” to this small list of certain events. It is not uncommon for us to get a pained look from NPD heads whenever we ask them to give us a feel of the current Due Date Performance of projects before the start of our engagements. The delays, as they explain, are not merely in days and months but sometimes in years. The original due dates are changed so many times during the course of a project that people are hard-pressed to remember when the project was originally scheduled to launch. To make things worse, the delays themselves are not predictable. For example, a project gets delayed three times, each time by three months, than by nine months at one time. After every delay that results in a revised due date, projects seem to be largely on track to meet the revised dates for the substantial portion of time. However, all hell breaks loose as the dates come closer. It is realised and sometimes communicated to top management that the t’s have not been crossed - and I’s have not been dotted; in other words, due processes have not been followed. Some component designs are still undergoing iterations, and some parts are not even close to design finalisation. The common refrain from the program management team is “We are progressing well but we are still not in a position to launch at the new date. Please give us some more time (re-revised date).” <h5>The anatomy of project closures</h5>When, even after revising the due dates, the predictability of achieving the revised dates seems no better than before, the only recourse left to the top management is to stop predicting and start taking firm - or sometimes even dictatorial actions to complete projects. From time to time, it puts its foot down to announce the launch of a project as a fait accompli. Once the announcement comes, the different stakeholders involved in executing the project have to get together and put in humongous efforts in ‘pushing’ the project out in what can only be described as premature delivery.  In fact, for a ‘battle hardened’ NPD person, it almost seems that nothing can ever get delivered without initiating this process of hard labour. “Projects do not naturally complete by themselves; they have to be closed”- is the common refrain. We have also heard people say that the action of closing a project in their environment can well be defined as a separate project in itself! <h5>Launch after-shocks</h5>What transpires during forced closures of projects is a saga of compromises where the top management has no choice but to join hands with the executing teams to approve or ignore deviations that were made during the NPD cycle in a bid to launch on time.Such ‘regularised’ deviations often result in mistakes or ‘blunders’ that come back to haunt the <a target="_blank" rel="noopener noreferrer" href="https://www.vectorconsulting.in/en/industries/auto-and-auto-components/">OEM </a>soon after the marketing launch. The ‘hauntings’ are in the form of:<ul style="list-style-type:square;"><li>Frequent line stoppages owing to assembly issues - this results in lost production of new models and disruption in the production of running models.</li><li>Rapidly changing production schedules owing to infrequent supply of new parts from suppliers.</li><li>Design problems that are detected late since some tests are still running while the product is launched.</li><li>Vehicle recalls have to be made after launch under extreme situations where components have been expeditiously & faultily passed during the NPD test trials under pressure of time</li><li>Post-sales niggles in product performance leading to frequent visits to service stations- fuelling poor customer satisfaction.</li></ul> Owing to all the above issues, the handover of the day-to-day running of the new model from the NPD team to the operations team is delayed - the operations team refuses to take the responsibility for running the new model until NPD has resolved all the issues. Sometimes it takes months for such handovers to take place, during which the capacity of <a target="_blank" rel="noopener noreferrer" href="https://www.vectorconsulting.in/en/solution-frameworks/research-and-development/">NPD</a> is used up in issue resolution and daily management of newly launched models. Consequently, NPD capacity is not freed up to take up work on new projects, which increases the <a target="_blank" rel="noopener noreferrer" href="https://www.vectorconsulting.in/en/solution-frameworks/research-and-development/">product development </a>lead times further. OEMs inform their external stakeholders about the launch in advance, and they align the capacities of their distribution networks to cope with the expected increased volumes of new or upgraded products coming out of the OEM plants. However, these stakeholders are left high and dry when the real volumes supplied are not in line with the projected ones. Worse, in extreme situations, the products themselves may have to be recalled from the market owing to a technical glitch not discovered during the NPD cycle. This results in lost sales for everyone - for the OEMs and their dealers - and lost prestige for OEMs amongst dealers. The effects of the mistakes or ‘blunders’ committed during the NPD cycle are clearly visible to everyone. Then why does the story repeat itself project after project?  If one were to ask a design or development engineer on what his ‘ideal’ NPD process and how much he is able to adhere to it, one is sure to get embarrassed looks. What are the underlying or core problems which create this time pressure time and again on a resource, causing him to deviate from his ‘ideal’ process? <h5>Core problem: Bad multitasking & desynchronisation</h5>A typical NPD organisation is a multi-project environment where projects are executed and delivered by a common set of resources. In such an environment, the overall WIP of projects in the system determines the speed of progress of individual projects. This is because the addition of a single project to the system has the potential of slowing down all other projects by diverting resources away from them. However, in the current reality, a new project added is always seen in isolation from other projects in the system.  This is because conventional wisdom ignores all resource contention and believes that driving up the speed of one project does not sacrifice the speed of other projects in the system. Influenced by this wisdom, the management drives all projects with equal zeal and with no relative priorities accorded to individual projects. As a result, the common resources are forced to divide their available time among multiple projects in no particular order, in a bid to move all of them. This reduces the resource availability for each individual project, slows  projects down, and increases the lead time taken to complete them. Over time, as current projects get delayed, more and more new ones get added, forcing common resources to divide their time even further and making the problem of high lead times much worse than before. Projects are perennially delayed, and resources are under continuous time pressure to complete their work. This phenomenon of switching across projects is called bad multi-tasking. As mentioned earlier, since no common relative priorities are given to projects being worked upon by multiple teams, each team decides priorities on its own. These priorities largely depend on the signals each team receives & interprets from various stakeholders (downstream departments, project managers, marketing, etc.) and vary over time and across teams.  Such changing priorities lead to desynchronisation of efforts amongst various teams. Teams that are required to work in tandem on a single project may choose to work on different projects at any given point of time, based on their individual notions of the importance of those projects. It is commonly said that a NPD project is a journey from one integration point to the next. An integration point is an event in the NPD cycle at which outputs, in the form of information or materials, from multiple teams working on different subsystems of the intended product are brought together to make sense of the integrated whole (the intended product model for the project).  Examples of integration points are NPD design gates/reviews, vehicle Alpha/Beta build events in the NPD cycle, etc. Any discrepancies between the outputs of different teams that can create a jarring effect on the integrated whole are resolved at such integration points. More importantly, on reaching an integration point for a project, every team is required to wait for respective outputs to arrive from all other teams before this process of synthesis can take place. Owing to desynchronisation of efforts between various teams, their outputs do not arrive at the integration points at the same time - some teams arrive much earlier than others.  With the pressure of time created owing to bad multitasking, most teams, which arrive earlier, move on to the next set of activities without synthesising their outputs with others. It is these skips in processes, particularly at integration points, which lead to mistakes or blunders that come back to haunt the NPD organisation during or post product launch. <h5>Wrong assumptions, wrong solutions</h5>Most NPD organisations lack visibility into the core problem mentioned above. Instead, they have been known to react in two ways to address the problems of due date failures and poor predictability. Those who are more technically inclined believe that adding more skilled resources to the NPD organisation would improve the situation. However, lack of skilled resources is a perennial issue that everyone falls back on when none else can be found. In fact, someone old enough in the system may recall that the same conclusion was drawn some years ago, and despite hiring additional resources, they are still in the same, or only slightly better situation now as before. Then there are those who believe that faulty project planning leads to poor execution. Strict time management in project plans is touted as the means to ensure timely execution. More sophisticated tools are bought to break down projects into activities and sub-activities, each with its own planned time. Deviation of plan times from actuals is monitored and escalated. Intermediate plan dates are strictly adhered to. All these faulty actions taken without addressing any of the core problems identified, viz: uncontrolled project WIP & desynchronisation, actually worsen the situation rather than relieving it. <h5>The way out</h5>For any solution to be effective, it should resolve the core problems, which are responsible for generating most of the negative symptoms in the system. The core problems identified are excessive bad multitasking and a lack of synchronisation caused by uncontrolled growth in the number of projects being worked upon simultaneously and an environment of changing priorities. As already mentioned, in a multi-project system like NPD, the speed of execution of an individual project depends not on the project itself but on the overall WIP of projects in the system. For such a system to work well, the projects have to be executed in harmony with each other. In other words, any addition of a new project should not reduce the resource capacity of the other ‘older’ projects in the system. Implementing Vector’s Flow-based project solution resolves the core problems identified by putting mechanisms and rules in place which:<ul style="list-style-type:square;"><li>Control the overall WIP in the system to a pre-determined level to ensure maximum speed of execution of projects which are currently being worked on.</li><li>Ensure proper synchronisation of work on a project across different teams to prevent stagnation at integration points.</li><li>At an individual resource level, foster the behaviour of working on lesser number of activities at a time but completing them much faster than before.</li></ul> The mechanisms that are put in place cause a complete shift in focus from managing individual projects in the time domain to managing the overall flow of projects in the system. The effect is seen almost immediately. The system output goes up. The amount of firefighting in the system reduces considerably, and the NPD organisation gets considerably de-stressed because:<ul style="list-style-type:square;"><li>Reworks & iterations go down owing to proper integration.</li><li>Instances of unexpected obstacles to flow, especially close to launch dates, reduce.</li><li>‘Unofficial’ engagement of NPD resources in the projects after their launch (due to production stoppages, service failures in the launched product) is reduced owing to better adherence to the correct process during the NPD cycle. The handover to operations happens more seamlessly than before.</li></ul> When WIP of projects in the NPD system is controlled, the availability of resources improves for the fewer number of projects that are being worked upon. Since the extent of firefighting in the system also reduces, resources do not have to spend their time dropping work at hand in order to put out unplanned fires. As a result, stoppages in the flow of a project owing to non-availability of resources come down, and variability in project lead times reduces. In light of reduced variability in project timelines, the Critical Chain methodology is employed to predict the completion date of a project much better than before. <h5>Conclusion</h5>A systems-based approach to problem-solving ensures that the few leverage points with the greatest potential to improve the system performance are identified and addressed. The results are achieved very fast with minimal investment. In fact, every company that has implemented Vector’s Flow Management solution has experienced a twofold to threefold jump in output with almost no increase in manpower. With outputs rising and lead times crashing, the repeated project delays become a thing of the past. Projects complete on time without anyone, including the top management, having to put any extra-herculean efforts to achieve the same. This is because the processes that are laid down during implementation of flow solutions put the NPD system in an auto-drive mode where all teams/resources work at maximum speed and in sync with each other. The top management capacity is freed up from getting too embroiled in day-to-day expediting of projects that are getting delayed. As a result, they are able to spend more time to perform more strategic roles that they are originally meant to do, such as improving the ideation and quality of projects that get initiated in NPD. It does look like every cloud has a silver lining, death and taxes notwithstanding.

New Product Development (NPD) is crucial for evolving customer needs, but iterative processes and variability challenge efficiency and delivery. Problem: NPD teams often encounter capacity overload, excessive work-in-progress (WIP), bad multitasking, and frequent scope changes, leading to delays and inefficiencies. Solution: Implement structured processes that enhance the quick flow of projects - enforce WIP control and complex gates, prioritise projects based on capacity, and focus on stage-wise planning to manage variability effectively. Benefits: Streamlined workflows, reduced lead times, improved output predictability, better resource utilisation, and faster delivery of successful products to market.

Businesses rely on the New Product Development process to grow. However, the process is stressful for companies. Is there a way to de-stress it?

Download PDF

Explore strategies to streamline New Product Development (NPD) processes with insights from Vector Consulting Group's expert Vivek Chopra.