New Product Development (NPD) is the process adopted by companies to develop new products/models to cater to evolving customer needs. Most products move from the initial hype to maturity phase, and finally to obsolescence during their lifetimes. The market conditions prevailing during the launch of a product keep changing with time and companies have to continuously evolve their offerings in order to manage demand through the life of a product. NPD organizations are responsible for launching:
• new products/models and
• upgraded versions of current models on an ongoing basis so as to sustain their market demand, till the time they are replaced
A typical NPD organization is a multi-project environment with multiple product development initiatives running simultaneously, some being upgrades of existing models while others are completely new products/models.
Any new product, on introduction is expected to sell in large enough volumes so as to make a substantial difference to the company’s topline and profits. High demand for a product may be a necessary but is certainly not a sufficient condition for higher sales. The company must not only be able to generate demand but also be able to capitalize on it:
• by providing superior availability in the market and
• by ensuring high reliability of product performance across volumes; else the initial euphoria about the product dies down.
Therefore, apart from developing the product, the scope of an NPD initiative also includes the design & development of a manufacturing process and operations infrastructure to achieve the following:
a) Capability to adaptively match the future product’s supply to its (often volatile) market demand and
b) Capability to ensure repeatability in production so that variability in product performance is minimized
Typical NPD Stages
Once a conceptual idea for a new product or an upgrade is generated, the NPD process helps the company resolve the following questions in sequence and at different points in the development cycle:
A) Does the product idea satisfy the significant needs of a large enough segment of the market? In other words, will it help the company make money now and in the future?
This is the primary question to be answered since nothing else matters if the response to this question is negative. Most companies have an initial “Idea generation & screening” stage where multiple market research techniques are employed to generate product ideas. The ideas then get compared amongst themselves to identify those that are the most promising.
B) Is the product idea viable i.e. is it capable of meeting the performance criteria that it has set out to achieve?
This question is resolved in the next stage related to Concept Development and Testing. During this stage, the viability of a product idea is assessed internally within the organization by the design and engineering teams of the company. Detailed product design is generated and multiple tests performed to validate the product performance against the critical targets defined in the ideation stage. Design revisions are made to meet targets and validated through repeat tests- the entire process is iterative in nature. On successful completion of this evaluation, the company decides to go ahead full steam with development of product by allotting a budget. Communication with external supply chain partners is initiated to jointly develop the product only after this stage is passed and budget allotted.
C) Can the product be produced repeatedly with minimum variability so as to achieve reliability in performance?
This question is resolved once the company begins partnering with its supply chain partners to develop the product parts. The partners and the originator company work together and make changes in the initial concept design to resolve problems arising out of variability in parts produced by suppliers, all the while performing multiple iterative tests to validate the changes.
D) Are the product design, the manufacturing process & infrastructure aligned to produce as per the estimated market demand with relative ease and with minimum additional operating expenses over current levels?
The production processes by which the new product would be manufactured and assembled start getting devised by the process engineering groups along with the detailed product design. These processes are applied and tested on the product while the product design itself is getting evolved through the development cycle. The feedback from these trials is incorporated into the product design and the manufacturing/assembly process design. Changes are made accordingly and then validated over multiple iterations. The objective is to make the manufacturing/assembly processes robust so as to be able produce at the required rate when production commences, all the while controlling additional investments in equipment/facilities while minimizing chances of rejections during production.
As evident from above, the extremely iterative nature of work in the NPD process differentiates it from other project environments. Flow-backs in this process are a norm rather than exception. This iterative nature is the primary & common cause of variability in the NPD process. The multiplicity of tests and iterations tend to make a full-blown NPD process to be much longer and subject to much greater variability than EPC or capital equipment manufacturing processes, all of which are project environments.
TOC Flow management principles define tactics to improve flow of work in the NPD organization. The favorable conditions thus created help in unblocking the capacity of NPD resources and improving their output. They also help in reducing the lead times of individual projects while improving their predictability.
Application of Freeze or WIP control in NPD
The initial phase of the NPD cycle involves idea generation and screening. Product idea generation is typically the responsibility of marketing and allied functions, which generate these following due processes of market research (through focus groups, road trips and other extensive modes of customer interactions). These ideas get screened and if found suitable, get percolated to the design and engineering functions which then proceed to test for their soundness and practicability in the Concept development and testing stage. During this stage, the primary elements of the ideas are given shape and their feasibility is tested through simulations/prototype testing etc. all of which require extensive time and capacity of the design, engineering & testing teams. Changes are made in the initial product design idea through iterative evaluations till the design and engineering functions get convinced that they have the blueprint of a practical & successful product which aligns to most, if not all elements of the initial idea that was generated by marketing. This is followed by a “Hard Gate” review event, where the results of the evaluation are assessed and a decision to go ahead or not is taken. The budget for a project gets approved and decided only after this hard gate review is crossed.
Concept development & testing phase involves substantial expenditure & effort from design & engineering functions. However, since the budget for a project is not allotted unless the concept is approved, all costs incurred in this phase are absorbed internally either as Operating Expense or from a common R&D budget meant for all concept evaluations. Since there are no project specific expenditures involved in this phase, this appears as a sort of ‘zero investment’ phase to the idea generator functions like marketing. In other words, their understanding is that infinite number of ideas can be evaluated without any investment involved as long as they are in this initial phase. However these functions tend to ignore the investment in time and resources required by R&D to evaluate these concepts and more importantly, the fact that this capacity to evaluate the concept too is limited.
As a result, the initial screening of ideas to be sent for concept evaluation tends to be done in a lax manner. If no controlling mechanism is in place, too many ideas tend to get generated and sent for concept evaluation too fast resulting in overload on design and engineering teams that evaluate them. Sometimes half- baked project ideas get taken up for concept development and evaluation without proper screening and under pressure from idea generators. Ideas tend to get approved serially for concept development and passed through, rather than being compared against each other in batches to identify the most promising ones, given that the capacity to test all these ideas in R&D within a near term horizon is limited. As a result many ideas which are passed for concept evaluation are abandoned or postponed mid way either because they are found to be impractical or because more ‘exciting’ ideas come up later and are then immediately pushed for evaluation to R&D, thereby unnecessarily wasting the capacity of engineering teams already used up in evaluating previous ideas which were dropped.
The result – there is an excessive WIP of projects at the concept development & testing phase at any given point of time, much beyond the near-term capacity of the design, engineering and testing functions to evaluate them. This encourages bad multitasking among these teams in this phase.
Before the start of any TOC implementation, it is generally observed that due to high prevalence of bad-multitasking at the concept development & evaluation stage, the rate at which projects get confirmed for passing to the developmental stages with approved budgets is very poor. This is despite the fact that there may be a large number of product ideas that are simultaneously being worked upon by R&D for concept development and evaluation. Since the rate of projects moving to the post budget phase tends to be a mere trickle, many concept evaluations are forcefully prioritized and expedited as management runs out of patience. In-fact, this initial phase of concept development and testing takes the maximum time in an unregulated NPD environment, with projects spending years as WIP in this stage, before they are completely evaluated, passed and budget allotted to them!
The overall WIP of projects in an unregulated NPD environment comprises a disproportionately large number of projects at the first two stages of “idea generation & screening” and “concept development”. In order to reduce the bad multi-tasking that is prevalent at this stage, it is important to control the number of ideas which are being simultaneously evaluated by the design & engineering teams. This is done by stopping work on more than half of the ideas. Therefore when the initial Freeze is applied to projects, the maximum impact is felt on projects at this stage, where most of the projects get frozen.
By enforcing the WIP Freeze, TOC tends to define and strengthen the Idea Screening event as the first Hard Gate, where a decision to commit the limited design and engineering capacity for concept development and evaluation is made. This is accomplished by limiting the maximum number of projects at the concept development stage that the design and engineering teams can work on. When the idea generators realize that it is not possible to push ideas for evaluation the way they used to in the past, they tend to be more careful in selecting & pushing more deserving ideas for concept development.
The initial WIP freeze, along with application of TOC Flow management principles reduces the bad multi-tasking and increases output of the design and engineering teams in evaluating ideas & creating feasible blueprints/designs for later development. The rate at which project budgets get approved for development with supply chain partners increases.
Although this increase in the rate of budget approvals is desirable, it tends to put additional pressure on the development & process teams that work in the downstream to develop these product blueprints with the suppliers and also the production processes. These teams have so long been used to working on fewer projects coming at them at lower rates from R&D. This increase in load on these teams working at the downstream also has to be actively monitored and controlled with respect to the capacity of these teams.
Hard Gates and Soft Gates
To elaborate on what has been explained in the figure above, an NPD project cycle is characterized by the presence of certain “Hard Gate” and “Soft Gate” reviews at various points in the project cycle.
During any Hard Gate review, the decision to invest either substantial organizational resources or money on the project is taken. Without this decision the project work cannot, rather, should not move to the next stage. For example, in any NPD process the first logical Hard Gate review should happen during Ideas screening and before the product idea is sent for concept development and evaluation. During this review, a decision is taken on whether the concept is worthy enough to invest substantial R&D time and resources to prove it. In organizations where this first Hard Gate review is not conducted strictly, product ideas tend to get pushed for evaluation prematurely leading to the situation, which has already been depicted in detail. In many companies, product ideas, all vying for common and limited organizational resources, tend to get screened serially as and when they are generated, instead of competing with other product ideas before being passed through. Therefore a multitude of product ideas, all with sign-offs for concept development obtained at various times in the past, sometimes years ago, lie in the system. These ideas get pushed in unregulated numbers, taken up and dropped and reworked multiple times.
Sometimes the numbers and scopes of these signed-off ideas is much more than the annual budget of the organization to take up for further development- the near term capacity of the design and engineering teams is used up to evaluate too many product ideas that anyway will not be taken in the near term owing to paucity of budget.
The second Hard Gate review is generally conducted after the concept evaluation is completed by the design, engineering and testing teams. During this review, a decision on whether to invest the money to develop the concept into a full-blown product is taken and followed up by a decision on the budget to be allocated. The investment on a specific product idea gets ‘formalized’ only after this review is conducted and budget approved.
Such Hard Gates, where decisions to stop or to continue work on projects may be taken are generally not seen in non-NPD environments. In non-NPD project environments, a legally binding commitment to execute the project or order is given to the customer at the time of initial negotiations itself and no decision to stop work can be taken unilaterally in the middle of the project, even if it is realized that the project may lead to losses for the executioner.
Teams that are supposed to get involved in the project after the Hard Gate review have to wait for the review to be completed before starting their work. At the same time, the teams that are involved throughout, in stages both before and after the Hard Gate review cannot work on activities subsequent to the review decision unless the review gets completed and a go-ahead given to the project.
On the other hand Soft Gate reviews are more of stocktaking and conflict resolution exercises. Such reviews do not involve Go/No Go decisions but resolve the question on “when” to start the subsequent activities rather then “whether” to start them at all. During such Soft Gate reviews, the decision to start work on subsequent stages can be taken even though work on preceding stages may not be entirely completed. Such decisions are taken after duly considering the risks involved in going ahead without fully completing the previous stage, as opposed to the potential reduction in project lead times that can achieved by advancing the start of the next stage.
A typical NPD project cycle will logically have two Hard Gate reviews (in most cases) but comparatively more number of Soft Gate reviews (any number depending on level of monitoring needed).
Hard Gates act like sluice gates in a dam that control the flow of water to the downstream entities. The sluice gates when opened, release an avalanche of work to the downstream. The Hard Gates can therefore be seen as inflexion points where there is a sudden, discontinuous change in the flow of work from upstream to downstream entities. In an uncontrolled environment the inflexion point at the Hard Gate is not prominent since whatever arrives at the gate passes through. In a regulated environment, looking at the capacity of the downstream teams to work on multiple projects simultaneously, one can control the release of work to the downstream teams from the Hard Gate. This can be accomplished, in some cases, by carefully controlling and scheduling the Hard Gate review events, since projects are expected to wait at these gates till a decision is taken. All in all, the Hard Gates are primary control points in NPD projects systems from where the flow of work can be monitored and controlled in order to manage the system performance.
Soft Gates on the other hand are more permeable and allow flow of work to teams working downstream more continuously. Consequently, teams both upstream and downstream of Soft Gates tend to work on the same set of projects with a smaller time lag in participation. Therefore any freeze in projects at the upstream of Soft Gates also freezes the current WIP of work of teams working downstream. Consequently any attempt to control active WIP of teams in a differential manner may fail if applied at a soft gate. Also since there is no major resource or finance specific decision to be taken in these gates, the application of WIP control may not be as successful, with teams starting work on the next stage through covert means.
A tight control at the hard gates can regulate the flow of work in the entire NPD system as re-iterated below:
Planning in NPD environments
NPD and Shifting Scopes
There is a large element of “discovery” in NPD projects environment. The “uncertainty” in an NPD projects comprises of the following:
a) Schedule variability-Variability in schedules or times required to perform tasks
b) Content variability- Uncertainty in the content of projects or the tasks themselves
Schedule variability is common across all project environments, but content variability differentiates NPD projects from other types.
The content of work in NPD projects is a moving target. At the start of an NPD project it is not always possible to chart a very accurate sequence and description of tasks too far into the future. This is because of the following reasons:
a) The tasks to be performed in future often depend on the outcomes of tasks being executed currently.
b) Also since NPD projects are longer in duration, the project goals & objectives keep changing due to evolving market dynamics during the course of their execution. For example, if during the course of executing an NPD project, a competitor develops an additional feature in his product, the company may feel compelled to include this feature in the scope of the current NPD project undergoing execution.
Owing to content variability, a detailed project plan for the entire duration of the project including its future stages is susceptible to frequent changes as new tasks may get added and old ones get deleted with time.
Consequently the time estimates for future NPD stages, which are based on project tasks and scope defined at the start of the project, will also change. How practical is it then, to manage the execution of the current stage of a long term NPD project by tracking a critical chain which includes the entire project network with its future stages and their “iffy” tasks with their estimated durations? Managing the current stage execution by looking too far ahead into the future may lead to too many wrong decisions on ongoing tasks, particularly when the future tasks themselves may change.
Therefore for NPD environments, TOC flow management solution avoids making detailed project networks for stages that are due too far in future. NPD projects, which are very long term, are managed one stage at a time with the expected end date of a stage being used to drive completion of the current stage. The end date for the current stage is drawn from
i) a high level estimate of all the stages & their expected durations and
ii) based on when the final project is required to be delivered.
Detailed planning at activity levels are performed for more immediate stages where there is greater certainty regarding the tasks to be performed.
The TOC flow management solution helps manage content variability by avoiding too much speculation on content changes. The problem is reduced to a simpler one of managing the uncertainty in the current stage with its schedule variability but with comparatively lesser variability in content. The emphasis is on faster execution of the current stage with the understanding that any early finish will be translated to early start for the next stage.
NPD and the problem with detailed planning
As mentioned in the previous section, in an NPD project it is not advisable to create a detailed plan including tasks to be performed too much in the future. The focus should be on defining the work content for more immediate stages. However, creating project network for immediate stages also has its own set of complications.
The scope of an NPD project includes sub-systems that vary in numbers from small (for Refresh projects) to very large (for completely new platforms/models). These are sub-systems that are supposed to undergo changes in the product being developed. The remaining sub-systems, which are not included in the scope, are common to existing product platforms.
However, the complex interdependencies between various sub-systems make it difficult to determine the exact order in which they would be taken up for design. This makes it difficult to create a detailed project network complete with information about sequence of work. For example some sub-systems may have to be revisited if other sub-systems connected to them undergo changes during the course of development. Also since flow-backs due to multiple iterations are common, a component may have to be revisited multiple times by an engineer. The development engineer will also have to procure the part multiple times as it gets modified in the same stage. The number of such iterations that will have to be performed at a component design level, even for the most immediate NPD phase cannot be predicted in advance. A detailed project network at a component level depicting the sequence of design, test and procurement tasks along with their iterations cannot be clearly defined in such environments.
The solution lies in defining a ‘good enough’ network, which while mentioning the sub-systems and components in scope, goes ahead with some healthy assumptions on their occurrence in the project sequence. Although the detailed network is not drawn, the major convergence and divergence points are identified independently by performing a relational analysis between the components being designed. These are treated as control points and are tracked to assess the quality of flow and level of project completion.
