Abstract
The Lean Product Development (LPD), depicted by Toyota and Honda development systems, is a benchmark in the automotive industry and has been widely accepted in other sectors with dramatic benefits. The lack of formalization of the Toyota PDS system, though, makes it difficult to replicate. Research on this system has resulted in the identification of several principles, tools and techniques, but did not present a way to make them systematic. This paper aims to propose a systematic way to make the lean engineering product development planning. The method allows the creation of an activity network, which provides at the same time value creation and waste reduction. The first part of the paper introduces Lean Product Development. Next, the issues related to the lean development are identified. In sequence a lean method to the development planning is presented. Finally, the method is evaluated against the identified issues.
Introduction
A Product Development (PD) Project is problem-solving and knowledge-accumulation process based on two pillars: “do the thing right” and “do the right thing”. The former guarantees that progress is made and value is added by creating useful deliverables that reduce uncertainty and/or ambiguity (Schrader, Riggs, Smith, 1993; De Meyer, Loch, Pich, 2002): value creation. The latter addresses the challenge to produce these deliverables at the right time, when it will be most useful (Thomke, Bell, 2001; Murman et al., 2002): waste reduction. Developing complex and/or novel products multiplies these challenges; the coupling of individual components or modules may turn engineering changes in a component into “snowballs”, in some cases causing long rework cycles and turning virtually impossible to anticipate the final outcome (Mihm, Loch, & Huchzermeier, 2002).
Not surprisingly, overtime, over budget and low quality are commonplaces on PD projects. A great exception in this scenario, and abenchmark in the automotive industry, is the Toyota Motor Company. Toyota has consistently succeeded in its PD projects, presenting productivity four times better then their rivals (Kennedy, 2003). To deliver better products faster and cheaper, some firms are attempting to use the same principles as Toyota's, and create “lean PD” processes that continuously add customer value (i.e., that sustain a level of “progress” toward their goals (Walton, 1999; Browning, Deyst, Eppinger, Whitney, 2002). Unfortunately, unlike Toyota Production System (TPS), that was formalized by Shigeo Shingo and enforced by Taichii Ohno, the Toyota development system has not been well documented (Ward, Liker, Cristiano, Sobek., 1995; Sobek, Ward, Liker, 1999)
This paper aims to present a systematic way to make the lean engineering products development planning. The method allows the creation of an activity network, which provides at the same time value creation and waste reduction.
This work consists of four parts: (1) a brief introduction to lean development; (2) the identification of the issues of lean development; (3) the conceived method; and (4) the method evaluation against the identified issues.
Lean Product Development
In the 1950's, Eiji Toyoda, Shigeo Shingo and Taiichi Ohno at Toyota Motor Company, in Japan, developed the Toyota Production System (TPS). The TPS, which most people now associate with the term Lean or more with the Just-in-time (JIT) principle, was born when Japanese car industry stuck in a severe crisis. At that time it became clear that the only way to escape from the possible impending doom of this industry were drastic changes in efficiency and productivity (Salzman 2000). This change happened through lean thinking (or philosophy), which is a way to specify value, align the value-added actions, when requested execute these actions without interruption and improve continuously (Womack & Jones, 1998). The lean philosophy was presented to the rest of the world by the results of MIT International Motor Vehicle Program – IMVP (Womack, Jones & Ross, 1990), whose goal was to compare the performance differences between car companies operating with traditional mass manufacturing systems and those using the TPS.
Meanwhile, these principles have been adopted by diverse sectors of industry such as aerospace, consumer products, metal processing and industrial products (Spear, Bowen, 1999). The lean thinking success, though, is not limited to manufacturing. It can be applied to other processes with high cost reduction and quality improvement potential, which is the case of product development. On the development phase the lean thinking goes beyond systematic waste reduction and the application of lean manufacturing techniques to product development (Kennedy, 2003). To allow the Lean Product Development, besides lean itself, the project plan allows the value creation, while providing waste reduction.
The value, as defined by the final client, is the basis of lean thinking. In a program or project, the value is the raison d’être of the project team, which means they must understand all the required product/service characteristics regarding the value that all stakeholders of the program expect to receive during the product life cycle (Murman et al., 2002; Mascitelli 2002; Kennedy, 2003).
There is no recipe, though, to value creation. Value is: (1) personal, because something of high importance to a group or person may not be valuable to others; (2) temporal, since it is not static, but evolve according to stakeholders’ change of priorities; (3) systemic and enterprise wide, as the parts, subsystems or company's sectors only add value if they contribute for the whole; and (4) fuzzy at the beginning of the lifecycle, due to the few information available to determine the whole value and, sometimes, even the final client (Kennedy, 2003).
Concerning waste, in manufacturing for instance, Toyota has established a set of seven waste categories that make easier the task of waste finding and elimination. These categories were further adapted to the PD environment (Walton , 1999; Millard, 2001; Bauch, 2004). Exhibit 1 shows the seven wastes countermeasures from the PD perspective (Pessôa, 2006).
Exhibit 1 - Wastes countermeasures on product development
The five lean principles are the countermeasures against waste and through them the set of requirements the project plan must follow are defined (Pessôa, 2005):
Principle 1 - Specify value: Value is the basis for lean thinking. The value, as defined by the final customer, must be materialized by the project deliverables (Mascitelli 2002). Thus the product scope, which includes the “features and functions that characterize the product, service or result” (PMI 2004, 104) must incorporate all and only the customer value. To avoid misunderstanding regarding the specified value, the project objectives and goals have to be unambiguous.
Principle 2 - Identifying the value stream: The value stream is a theoretical and ideal sequence of exclusively value-added tasks (Mascitelli 2002); where a value-added activity transforms the deliverables of the Project in such a way that the customer recognizes the transformation and is willing to pay for it. According to Womack & Jones (1998), Toyota does not have a detailed step-by-step process describing how to do development. Thus, the project plan must be simple, rather highlighting key dates and responsibilities and defining optimized information flows (what, when, sender, receiver and media), in order to prevent excessive data traffic and promote efficient communication. The project network must contain only the activities needed to perform and support the value flow, avoiding unnecessary processes, approvals and transactions.
Principle 3 - Guarantee the flow: Every development value flow obstacle (functional departments, executive gate meetings, fire fighting, changing requirements and management interference) must be eliminated (Mascitelli 2002). The Set-Based Concurrent Engineering (SBCE) is a powerful technique to avoid risk through redundancy and robustness, and to allow knowledge capture (Kennedy 2003). By the use of SBCE, the development team does not establish an early system level design, but instead defines sets of possibilities for each subsystem, many of which are carried far into the design process. These sets consider all functional and manufacturing perspectives, building redundancy to risk while maintaining design flexibility. The final system design is developed through systematic combining and narrowing of these sets, when alternatives are eliminated according to the growth of knowledge and confidence (Kennedy 2003). The discarded alternatives are themselves considered learn opportunities.
Principle 4 - Pulling value: Instead off pushing scheduled activities, which themselves push information and materials through the development process, pull events must be defined. Pull events differ from phase gates by not damming information, but allowing its flow.
Principle 5 - Seek perfection: The development process continuous improvement is achieved by the capability of the process and effective knowledge management. Through the SBCE Toyota performs extensive prototyping at the subsystem level while applying tremendous rigor to how they capture learning: they study both what works and what do not work. This knowledge is systemically documented and disseminated through trade curves, which everyone has ready access and is expected to use it, including management (Kennedy 2003).
Issues to the Lean Product Development
The inherent complexity of the development of complex engineering products is a serious obstacle to value creation and waste reduction. According to concurrent engineering principles, when a product is conceived it already constrains its life cycle processes and the organizations that perform those processes, creating a total perspective where the product plays only part of the whole complexity (Loureiro, 1999). Thus the “total” value includes not only the product's perceived benefits, but also the benefits achieved through the life cycle processes and performing organization. Value for a stakeholder, then, is the total and balanced perception of all benefits provided by the results from the life cycle processes; as a total perception are considered not only the results related to the product, the processes and the performing organization, but also the fulfillment of all functional, cost, schedule and risk requirements (Pessôa, 2006).
The identified issues are related to the PD process, to the lean prerequisites to PD and to the traditional planning methods.
A PD process has to be capable to deal with: (1) product complexity, as customers demand products more and more complex; (2) process complexity, regarding integrated development, process standardization, amount of information involved, etc.; and (3) uncertainty between supposed and verified characteristics and ambiguity due to multiple and conflicting interpretations.
In order to be lean, the PD process must adhere to the lean principles and avoid traps such as (Murman et al., 2002):
- The ‘preconceived solution’: a solution that has worked in the past and that has become institutionalized as a ‘monument’.
- The existence of a powerful advocate with a vested interest in a specific design approach or solution to a problem.
- The tendency to underestimate the difficulties in developing a new technology, particularly if this occurs simultaneously with the development of a new product or system based on that technology.
Finally, traditional planning falls short on lean development due to the following aspects:
- In order to guarantee the ‘schedule stability’ a point and low risk solution has to be frozen early in the process in detriment of others viable solutions (Kennedy, 2003).
- The main objective of planning is the control and not the execution (Laufer, Tucker, 1987). Thus, more importance is given to the activities themselves instead of their results (Kennedy, 2003).
- It incorporates a transformation view, by assuming that translating a plan into action is the simple process of issuing and executing ‘orders’, analogously to a MRP (Manufacturing Resource Planning) (Koskela, Howell, 2002).
- The systemic vision loss caused by successive product and work decompositions (Pessôa, 2006).
A lean method to the development planning
The ideal PD process should work analogously the single-piece flow in manufacturing (Womack, Jones, 1998), representing a value flow from conception to production, without stops due to bureaucracy and loop backs to correct errors. On PD, adding customer value can be less a function of doing the right activities (or of not doing the wrong ones) than of getting the right information in the right place at the right time (Browning, Deyst, Eppinger, Whitney, 2002; Kennedy, 2003). Hence, the focus of lean must not be restricted to activity “liposuction” (waste reduction), but address the PD process as a system (value creation) (Browning, Deyst, Eppinger, Whitney, 2002).
The planning approach described in this section applies the lean principles, based on value creation and waste reduction, to derive a project activity network that is based on a value creation sequenced set of confirmation events that pulls only the necessary and sufficient information and materials from the product development team. The purposed method has four steps (Exhibit 2):
Exhibit 2 - The purposed method.
(1) Value determination: having the product vision as an input, this process defines the Value Breakdown Structure – VBS (Exhibit 3). The VBS differs from the usual WBS, where the latter decompose the work, to make major project deliverables or perform project phases, into smaller and more manageable chunks, and the former deploys the stakeholders’ value into unequivocal and verifiable parameters, called value items. This step substitutes the “Scope Definition” and “Create WBS” processes from PMBOK.
(2) Set-based Concurrent Engineering (SBCE) prioritization: determines the most critical product modules or organizational processes, which will be developed through a set of alternatives. This step contributes to the execution of “Risk Identification”, “Risk Qualitative Analysis”, “Risk Quantitative Analysis”, and “Risk Response Planning” processes from PMBOK.
(3) Pull events determination: No process along the value flow should produce an item, part, service or information without direct request from the afterward processes. The pull events are associated to physical progress evidences (i.e., models, prototypes, start of production, etc.) and are important moments to knowledge capture. Differently from tall gates where information batches are created, pull events guarantee the value flow, make quality problems visible and create knowledge. Steps 3 and 4 execute the “Activity Definition” and “Activity Sequencing” processes from PMBOK.
(4) Value creation activities sequencing: the activities to be performed are defined and sequenced based on the pull events.
Exhibit 3 – Value Breakdown Structure (VBS).
The method evaluation
The method was evaluated according its capacity to fulfill the previously presented needs (Exhibit 4):
Exhibit 4 – The method coverage on the identified issues.
(1) Value determination: this step guarantees the value specification principle; it avoids preconceived or any other solution that does not match the expected value; the focus on value is the basis to planning to execution; finally, analogously to the others steps, it uses and generates historical information that contributes to continuous improvement.
(2) Set-based Concurrent Engineering (SBCE) prioritization: the multiple alternative development prevent the early abandonment of promising solutions and gives room to the coexistence with preconceived and advocated alternatives as well; it helps to guarantee the flow, since reduces rework cycles.
(3) Pull events determination: the pull events are the back bone of the value flow and have the main role to fulfill the pull work principle; by pulling the value delivery they allow the planning to execution.
(4) Value creation activities the pulled value creation activities are the value flow itself; by being put in motion, they are the very planning to execution.
As the basis for a contrived example of development planning, was used the data collected from a finished and successful project, which produced a stall recovery system to be used during flight tests. Exhibit 5 presents a comparative analysis of the original planning and the one resulting from the method application. On this particular example there were better results at each of the four steps.
Exhibit 5 – Lean principles applied to development planning.
Final Words
The research method presented in this paper provides a useful approach to planning to complex engineering products development. Conclusions are that the developed method: (1) fits the product development environment; (2) adheres to the lean principles; (3) faces the traditional planning deficiencies; (4) exploits the improvement opportunities from the studied example.
This work contributes to the Project Management discipline by: (1) the application of the lean principles, based on value creation and waste reduction, to derive a project pulled-activity network; and (2) the presentation of an alternate way to breakdown the project work, through the use of the Value Breakdown Structure – VBS.
