Marcus Vinicius Pereira Pessôa a1 , Geilson Loureiro b and João Murta Alves c a Departamento de Controle do Espaço Aéreo – DECEA, Brazil. b Instituto de Pesquisas Espaciais – INPE, Brazil. c Instituto Tecnológico de Aeronáutica – ITA, Brazil.
Abstract : Innovative firms have product development as one of their core processes; optimizing this process, regardless the product will be mass-produced or custom made, must be a firm’s priority. A common approach is to treat the product development as a project, where Project Management is essential to organize and lead the efforts. The Toyota development system is a benchmark in the automotive industry and has been widely accepted in other sectors with dramatic benefits. This work presents an approach to derive a project activity network pulled by the stakeholders’ requested value. The first part of the paper introduces the value creation in product development. In sequence the issues to planning to lean development are discussed. Finally the four-step approach is presented and the first three steps are explained through the analysis of real project data.
Keywords : Lean development, project planning, value creation.
New product development (PD) can be understood as some kind of information based factory [1]. The goal of the PD process is to create a “recipe” for producing a product [2], which reduces risk and uncertainty at the same time with the target to gradually develop a new and error-free product which can then be realized by manufacturing, sold, and delivered to the customer.
PD is a problem-solving and knowledge-accumulation process. Progress is made and value is added by creating useful information that reduces uncertainty and/or ambiguity [3, 4, 5]. But it is challenging to produce information at the right time, when it will be most useful [6, 7]. Developing complex and/or novel systems 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
[8].
1
Corresponding Author E-mail: mvppessoa@gmail.com

2 M. V. P. Pessôa, G. Loureiro and J. M. Alves
Not surprisingly, overtime, over budget and low quality are commonplaces on
PD projects. A great exception on this scenario, and benchmark on the automotive industry, is the Toyota Motor Company. Toyota has, consistently, succeeded on its
PD projects, presenting productivity four times better then their rivals [9]. 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) [10, 11].
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 [12, 13].
All of these issues point to the need for a formal way to turn operational the
Toyota’s lean practices on PD. This paper proposes an approach 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 paper shows how both accomplish the two elements of creating value [6]: (1) maximizing the value creation by doing the right job and (2) minimizing the waste in the process by doing the job right.
The goal of this paper is to advance the theory and practice of planning projects of PD. The paper contributes a method that helps (1) managers to add value by focusing effort on eliminating the critical sources of risk in their projects and (2) planners to ensure that a proposed process addresses all of the known significant sources of performance risk
After discussing the concepts and methods used to formulate the planning method, the paper shows how to apply the approach using an industrial example, an aircraft stall recovery device.
In the 1950s, 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 [14].
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 [15]. The lean philosophy was presented to the rest of the world by the results of MIT International Motor Vehicle
Program – IMVP [16], 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
[17]. 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 [9].

A Value Creation Planning Method to Complex Engineering Products Development 3
The ideal PD process should work analogously the single-piece flow in manufacturing [15], 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 [9, 10]. Hence, the focus of lean must not be restricted to activity
“liposuction” (waste reduction), but address the PD process as a system (value creation) [10]. Value creation can be divided into three phases: value identification, value proposition and value delivery [6].
The value, as defined by the final client, is the basis of lean thinking. On a program or project, the value is the reason d’être of the project team, which means they must understand all the required product/service characteristics regarding the value that all stakeholders on the program expect to receive during the product life cycle [9, 6, 18].
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 [6].
The value proposition (project plan) implements the strategy to efficiently deliver the value to all stakeholders. It formalizes the program objectives, defines the stakeholders’ relationships and determines schedule and budget. At this moment explicit or implicit trade-offs are made, in order to: (1) include all stakeholders; (2) solve conflicts; (3) include all tangible and intangible values (or anything that might have been forgotten) [6]. Therefore, the program’s activity network must represent the value stream, where all the tasks in a program are directed to creating deliverables, which are themselves pulled by the value stated by the stakeholders [18].
Unperceived or unsolved problems during value identification are the more expensive to solve, causing more waste and rework; and no efficient use of lean practices and tools during value delivery (project execution) can overcame poor decision during the value proposition creation (product design and project planning).
Toyota applies a set of tools and techniques that help on solving these issues
[19]. The approach presented in this paper is aligned to some of them, which affect directly the program activity network definition, they are: trade-off curves, Setbased Concurrent Engineering – SBCE and pull events.
2.1 Trade-off Curves
A trade-off curve is an important tool to solve conflicts among system requirements during the Toyota development process [19]. Besides helping on decision making, it is a simple and practical way to reuse knowledge [9].

4 M. V. P. Pessôa, G. Loureiro and J. M. Alves
2.2 Set-based Concurrent Engineering – SBCE
SBCE is an upgrade of the concept of concurrent engineering used by Toyota.
SBCE allows decisions to be delayed and design options to remain open until it is absolutely necessary to select a point solution [11]. SBCE is a set of simple and repetitive development cycles that achieve high innovation in products and manufacturing systems, avoiding risk through redundancy, robustness and knowledge capture [9].
During SBCE, the development team does not establish an early system level design, but instead establishes sets of possibilities for each subsystem, many of which are carried far into the design process (Figure 1.1). 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 [9]. The achieved knowledge is then captured in the trade-off curves.
Chief Engineer's
Concept Approval
Styling Approval
Figure 1.
Set-based concurrent engineering
Final Approval
2.3 Pull Events
No process along the value flow should produce an item, part, service or information without direct request from the following processes [15]. By pushing work results to the next processes the enterprise creates an inventory no one wants.
On a project the final client must pull the value from the project team [18].
On the Toyota development system, the pull events arte 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. On this context, the planning activity is decentralized, the chief-engineer has a macro schedule containing the pull events dates and each team has their own plans to guarantee the pull event realization and success [19].

A Value Creation Planning Method to Complex Engineering Products Development 5
It is well known that progress in PD is difficult to predict in a project management plan. Risk and rework provides a great complication. PD planners often “plan to succeed,” typically paying little attention to process failure modes and their effects
( i.e.
, rework) [10]. Since PD is a nonlinear process [20, 21], it is harder to determine what value is added and when. Especially in novel PD, design elements are proposed, analyzed, evaluated, and advanced or rejected. The effect of one activity changing its approach and outputs can “snowball” throughout the process, changing other activities’ inputs and assumptions and causing rework. PD processes typically have lots of change and rework [8]. The values of its activities are not predetermined—they are partly a function of the information they use and create, and therefore of the activities that precede them and those that follow [10].
The use of the “original” pull system concept on PD, then, is not possible: there is no totally predetermined way of developing the product, since downstream functions cannot really pull the information from upstream functions as they do not know the final output of the work they are supposed to do, not to mention the final product with all its specifications. However, there is also some predetermination of and in developing processes since the overall process follow certain logical orders and is not performed in an arbitrary manner. Experience from the last projects and especially from other simultaneously ongoing development projects gives a good idea of required input information and output results [1].
The widespread approach to define the strategy to PD is trough project management (PM). Traditional PM planning is based on a Work Breakdown
Structure – WBS, that aims to reduce complexity and increase manageability and control by decomposing work [22, 23]. This approach embodies a transformation view, where production is conceptualized as a transformation of inputs to outputs.
Furthermore, the management-as-planning perspective assumes a strong causal connection between the actions of management and outcomes of the organization.
By assuming that translating a plan into action is the simple process of issuing
“orders”, it takes plan production to be essentially synonymous with action. [24]
These issues have the same effect as MRP on manufacturing, not being able to deal with changes during execution and creating a huge amount of waste on the development system [25].
Thus, one cannot equate added customer value with progress through an arbitrarily defined schedule for several reasons: it may contain superfluous activities for which no value is added, and it may not account for missing activities, rework, or iterations. This is a significant weakness of the Gantt charts and
PERT/CPM network diagrams currently used in industry [26]. No schedule can make effective fine-grained work assignments in a complex environment with even modest variability [25].
Even agile alternatives, such as SCRUM [27] and Last Planner [28, 29], do not fit lean development. They basically decrease the size and increase de amount of iterations, but not embody an alternate to the transformation view, such as flow or value aggregation.

6 M. V. P. Pessôa, G. Loureiro and J. M. Alves
The 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 where: (1) value as stated by the stakeholders is determined, understood and structured; (2) an organization that allows value delivery is defined; (3) the events that will implement the value flow are listed; and (4) the project activities are pulled from the project development teams.
4.1 Value Breakdown Structure Determination
A program does not provide value unless it has all the capacity requested by the stakeholders. These capacities must be translated into identifiable functions and measurable parameters that can be designed, produced and verified.
The Value Breakdown Structure – VBS represents the project value tree, where the value as stated by all the stakeholders is: (1) understood and deployed into a set of unequivocal value items; and (2) translated into measures of effectiveness (ME).
Those measures, unless clearly requested by one stakeholder, will be defined as acceptable ranges (that will be narrowed during SBCE) instead of point values.
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 (Figure 1.2). While the
WBS gives support to the transformation view [24], the VBS is the basis of the value aggregation view.
Work Breakdown Structure Value Breakdown Structure
Figure 2.
VBS and WBS structures comparison

A Value Creation Planning Method to Complex Engineering Products Development 7
4.2 System Value Delivery Organization Determination
On product architecture, the functions to be performed are assigned to physical elements and the interactions among them are defined [30]. On the value delivery architecture (1) the value items are assigned to each product-organization subsystem that will deliver it to the stakeholders; and (3) it is determined whether a particular subsystem will be developed through a set of alternatives, instead of relying on the point based approach.
A product-organization subsystem is any group in the company, whose duty is to deliver some value subset. These groups are organized around product modules or enterprise functions ( i.e.
, production, logistics, etc.
).
Once the use of parallel development on all subsystem may not be necessary, useful or possible a strategy must be defined. This approach proposes that the subsystems which deliver more value and/or have higher risks on delivering this very value (the higher f (value, risk)) are the best candidates to perform parallel development.
4.3 Pull Events Definition
Pull events have three roles: (1) they guarantee that project activities will be pulled and not pushed; (2) they allow combining and narrowing alternatives in SBCE; and
(3) they constitute learning moments. On the purposed approach, the successful end of confirmation task ( i.e.
, reviews, tests, etc.
), which reduce the uncertainty and risk on PD, were chosen as pull events. The iterations among value items and the resulting value creation sequencing are the main drivers of pull events.
Identified value items conflicts are addressed, in order to exploit potential opportunities.
The related value items and corresponding product-organization subsystems define each event scope. The final pull events set must guarantee the right level of confirmation to each value item, according to its importance, criticality and probability of failure. Each event scope must be designed against failures and not just to fit the specification [31]. Imperfect reviews and tests are causes of loop backs and rework.
4.4 Activities Pulling
The purpose of the project activities should be progressively decrease performance uncertainty and risk. The activities are pulled from each value delivery architecture component by the related pull events. Each component must provide all and only the required information, parts, prototypes, etc.
, to enable each confirmation event.
During execution, the confirmation events signal the related subsystems to start their work, avoiding the waste created by early definition/creation of unnecessary information/parts. Thus, a pulled flow of information is created, instead of the pushed flow that is a characteristic from traditional schedules [24].

8 M. V. P. Pessôa, G. Loureiro and J. M. Alves
As the basis for a contrived example of development planning, we use data collected from a finished and successful project, which produced a stall recovery system (Figure 1.3) to be used during flight tests.
1 – Mortar (Mortar, parachute, riser lock, riser cutter)
2 – Trailing cone cutter
3 – EMI/EMC suppressor filter
4- Pilot Control Cockpit
5- Flight test engineer cockpit
Figure 3.
Tailchute system
This section presents the Tailchute data and discusses some insights from the value-to-confirmation table. Then, a hypothetical project planning is presented and discussed.
5.1 Actual Data Analysis
Figure 1.4 shows the set of value items identified from the project contract and specifications and the value confirmation tasks presented on the homologation plan and project schedule. On this value-to-confirmation table, the items were correlated according to the type of review: A - Analysis, I – Inspection, C - Calculus, D -
Demonstration and T - Test. The need for verification of each value item ( f
(importance, severity, probability)) and the total amount of verifications is also shown.
Some insights from the table were: (1) value items, such as “parachute riser length” and “cross section”, were not really values, but point solutions early defined; (2) Some items, such as “parachute deployment” and “load transfer”, received less attention than its importance; (3) other items, such as “pilot (panel)” and “flight engineer (panel)”, were over tested; (4) the correlation between importance and amount of verification was very low (r2 = 0.29).
Some adjustments on this same table, trying to correct some of the perceived discrepancies, led to an r2 = 0.66. All of these suggest that the activity network that supported these events was far from the ideal value creation.

A Value Creation Planning Method to Complex Engineering Products Development 9
Figure 4.
Value-to-confirmation table
5.2 Hypothetical Project Planning
A new problem analysis was made and a value tree was created from the set of four root values: (1) realign the aircraft; (2) provide safe and reliable operation; (3) operate installed on a determined aircraft family; and (4) allow quick and easy maintenance. Though the value items dependencies a Design Structure Matrix –
DSM was used to create the value items sequence with smaller loop backs (Figure
1.5).

10 M. V. P. Pessôa, G. Loureiro and J. M. Alves
Figure 5.
Parameter-based DSM of the value items
The DSM method uses a “n-squared” matrix to depict the information flows from one task to another, the relationship among design parameters or the communication across the project teams. The matrix can be numerically optimized to minimize iterations and maximize the potential for concurrent work. A good description of the method can be found in [32].
The lower left quadrant of the DSM helped on the determination of pulling events. On this quadrant are excluded the dependencies among, to and from the external input parameters of the project (items 5, 11, 12, 13, 16, 17, 18, 20, 21, 23,
24 and 25). The activities were pulled by the resulting future state value-toconfirmation table.
5.3 Lessons Learned and Results
During the case study the greatest challenge was the value items set definition and the determination of the iterations among them. A poor work on this step leads to an incorrect project scope and/or an inconsistent value creation sequence.
According to the development team, some positive results achieved were: (1) a better test and homologation plan; (2) the clear verification event scope definition; and (3) a sequence of activities that really described the work sequence and that allowed the cooperation among the subsystems teams.
The research method presented in this paper provides a useful approach to planning to complex engineering products development. The method can be summarized in

A Value Creation Planning Method to Complex Engineering Products Development 11 four steps where: (1) value as stated by the stakeholders is determined, understood and structured; (2) an architecture that allows value delivery is defined; (3) the events that will implement the value flow are listed; and (4) the project activities are pulled from the project development teams. An application to the development an aerospace project demonstrated that the method improves value identification and proposition.
This work contributes to the PD discipline by the appliance of 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.
Future work includes the analysis of the pulled events effectiveness during the program execution and their effect on control.
[1] BAUCH, C. Lean Product Development: Making waste transparent. Diploma Thesis.
Cambridge: Massachusetts Institute of Technology, 2004.
[2]
REINERTSEN, D. Lean thinking isn’t so simple. Electron. Design, vol. 47, p. 48,
1999.
[3] DE MEYER, A.; LOCH, C. H.; PICH, M. T Managing project uncertainty: From variation to chaos. Sloan Management Rev., vol. 43, no. 2, pp. 60–67, 2002.
[4] SCHRADER, S.; RIGGS, W.M.; SMITH, R. P. Choice over uncertainty and ambiguity in technical problem solving. J. Eng. Technol. Management, vol. 10, pp.
73–99, 1993.
[5] SUTHERLAND, J. W. Administrative Decision-Making: Extending the Bounds of
Rationality. New York: Van Nostrand Reinhold, 1977.
[6] MURMAN et al. Lean Enterprise Value: Insights from MIT’s Lean Aerospace
Initiative. New York, NY: Polgrave, 2002.
[7] THOMKE, S.; BELL, D. E. Sequential testing in product development. Management
Sci., vol. 47, no. 2, pp. 308–323, 2001.
[8] MIHM, J.; LOCH, C. H.; HUCHZERMEIER, A. Modeling the Problem Solving
Dynamics in Complex Engineering Projects. INSEAD Working Paper. Fontainebleau,
France: INSEAD, March, 2002.
[9] KENNEDY, M. N. Product development for the lean enterprise. Richmond: Oaklea
Press, 2003.
[10] BROWNING T.; DEYST J.; EPPINGER S.; WHITNEY D. Adding value in product development by creating information and reducing risk. IEEE Transactions
Engineering Management, 49(4):443–458, 2002.
[11] WALTON, M. Strategies for Lean Product Development: A Compilation of Lean
Aerospace Initiative Research. Research Paper 99-02. Cambridge, MA: Massachusetts
Institute of Technology, 1999.
[12] WARD, A. C.; LIKER, J. K.; CRISTIANO, J. J.; SOBEK, D. K. The second Toyota paradox: how delaying decisions can make better cars faster. Boston: Sloan
Management Review, p. 43-61, spring 1995.
[13] SOBEK, D. K.; WARD, A. C.; LIKER, J. K. Toyota’s principles of set-based engineering. Boston: Sloan Management Review, p. 67-83, winter 1999.

12 M. V. P. Pessôa, G. Loureiro and J. M. Alves
[14] SALZMAN, R. A. Manufacturing System Design: Flexible Manufacturing Systems and Value Stream Mapping; Thesis (S.M.). Cambridge, MA: Mechanical
Engineering, Massachusetts Institute of Technology, 2002.
[15] WOMACK, J. P.; JONES, D. T. A mentalidade enxuta nas empresas. São Paulo:
Editora Campus, 1998
[16] WOMACK, J. P.; JONES, D. T.; ROSS, D. The Machine that Changed the World.
New York: Rawson Associates, 1990
[17] SPEAR, S.; BOWEN, K. Decoding the DNA of the Toyota Production System.
Boston: Harvard Business Review, Sept – Oct 1999.
[18] MASCITELLI, R. Building a project-driven enterprise. Northridge: Technology
Perspectives,2002.
[19] LEAN INSTITUTE BRASIL. Workshop sistema lean de desenvolvimento. Joinville,
SC: Multibrás, 2-3 de fevereiro de 2006.
[20] KLINE, S. J. Innovation is not a linear process. Res. Management, pp. 36–45, July–
Aug. 1985.
[21] NIGHTINGALE, P. The product-process-organization relationship in complex development projects. Res. Policy, vol. 29, pp. 913–930, 2000.
[22] PROJECT MANAGEMENT INSTITUTE – PMI. Practice Standard for Work
Breakdown Structures. Newton Square: Project Management Institute, 2001.
[23] PROJECT MANAGEMENT INSTITUTE – PMI. A Guide to Project Management
Body of Knowledge (PMBOK® Guide). 3a Edição. Newton Square: Project
Management Institute, 2004.
[24] KOSKELA, L.; HOWELL, G. The Underlying Theory of Project Management is
Obsolote. Proceedings of the PMI Research Conference, 2002. Pg. 293-302, 2002.
[25] POPPENDIECK, M.; POPPENDIECK, T. Lean Software Development: An Agile
Toolkit. Addison Wesley, 2003.
[26] BROWNING, T. Modeling and Analyzing Cost, Schedule, and Performance in
Complex System Product Development. PHD Thesis. Cambridge: Massachusetts
Institute of Technology, 1998.
[27] SCHWABER, K. Agile Project Management with Scrum. Microsoft Press, 2004.
[28] BALLARD, G.; HOWELL, G. Shielding Production: Essential Step in Production
Control. Journal of Construction Engineering and Management, Vol. 124, No. 1, pp.
11 – 17, 1998.
[29] BALLARD, G. The Last Planner System of Production Control. PhD Dissertation,
School of Civil Engineering, The University of Birmingham, U.K., May 2000.
[30] ULRICH, K. T. The Role of Product Architecture in the Manufacturing Firm. Res.
Policy, 24, pp. 583–607, 1995.
[31] MILLARD, R. L. Value Stream Analysis and Mapping for Product Development.
Thesis (S.M.). Cambridge, MA: Aeronautics and Astronautics, Massachusetts
Institute of Technology, 2001.
[32] YASSINE, A. A. An Introduction to Modeling and Analyzing Complex Product
Development Processes Using the Design Structure Matrix (DSM) Method. Milan,
Italy: Quaderni di Management, No.9, 2004.