Planning processes and lean philosophy
can they live together?
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. This work presents the requirements a project plan must fulfill to allow LPD. The first part of the paper introduces the lean philosophy and describes the waste and the lean principles on product development. In sequence the preconditions the processes of developing preliminary project scope statement, scope definition, create WBS, activity definition, and sequencing and risk identification, as purposed by A Guide to the Project Management Body of Knowledge (PMBOK® Guide) 3rd Edition, are analyzed according to its compatibility to the lean development. Finally is explained why the traditional project management and the agile project management paradigms do not guarantee to turn the project execution phase into a value flow.
Innovative firms have product development (PD) 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. 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 (De Meyer, Loch & Pich 2002). But it is challenging to produce information at the right time, when it will be most useful (Murman et al., 2002; Thomke & Bell, 2001). 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 (Mihm, Loch & Huchzermeier, 2002).
A common approach is to treat the product development as a project, where Project Management (PM) is essential to organize and lead the efforts. Traditional PM, though, needs good product knowledge as an input and is based on a divide to conquer strategy to breakdown the work packages and define activities. Due to these premises, the more complex, the less effective is the traditional way. Agile PM, by the other hand, presents itself as an alternative: on the planning phase it purposes to only extend the detailed planning into the foreseeable future and to identify the achievements or milestones required to complete the project, rather than the detailed tasks. Even though avoiding long-range commitments, agile PM do not directly solve the breakdown problem. 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 (Kennedy 2003). The Lean Product Development, depicted by Toyota and Honda development systems, besides being a benchmark in automotive industry, has been widely accepted in other sectors with dramatic benefits (Walton 1999). The project planning phase main objective, then, should be to support the execution phase: in this work the Lean Product Development.
This work objective, thus, is (1) to identify a set of preconditions to the planning to lean product development; (2) highlight the necessary changes on the planning processes in order to become adherent to lean philosophy; and (3) answer why the traditional project management and the agile project management paradigms do not guarantee to turn the project execution phase into a value flow. The planning processes analysis scope include developing preliminary project scope statement, scope definition, create WBS, activity definition, and sequencing and risk identification, as purposed by PMBOK® Guide, 3rd Edition.
To achieve this objective, this paper is organized as follows: First, are offered remarks about the lean product development. Next, are presented the preconditions a project plan must be adherent to be itself lean and allow the lean development. Finally, will are discussed the preconditions compliance to traditional and agile planning and will summarize the information in our concluding remarks.
Lean Product Development
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 (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).
Waste on product development
The TPS main goal is to eliminate all the waste from the system. Waste is any activity that consumes resources but do not create value. In manufacturing for instance, Toyota has established a set of seven waste categories that make easier the task of waste finding and elimination. In this work, the ten product development waste drivers categories purposed by Bauch (2004) are used to help the recognition of the planning requirements:
Wait: It addresses that part of processing time when the creation of value remains static and the value stream is considered as “non-flowing”. On development, waiting waste is considered as the idle time due to unavailable information, manpower or computing resources.
Transport: This type of waste occurs due to installations and processes restrictions, which impose great distances to be overcame by materials thorough the process. In development it addresses the inefficient transmittal of information, the unnecessary movement of information (data transfer), the number of handoffs, as well stop and go tasks and task switching.
Movement: This type of waste refers to any human movement due to the lack of direct access to data, people, tools or systems regarding the underlying information system.
Over processing: It is the waste inherent to a non-optimized process, where there are non value-added activities or functions. Within product development it includes unnecessary product features, unnecessary detail and accuracy of information, excessive transactions, inappropriate use of competency, the use of inappropriate tools to accomplish the results and the conduction of excessive approvals, which often slow down the information flow.
Inventory: Inventories do not add value; they fix capital and so consume valuable resources, which could be used better for other value creating actions. During product development they more describe huge amounts of heterogeneous information stored on computer drives and file folders, and which are waiting for further processing by a functional department for release to downstream processes by gates. Another aspects concern stocks or rather data storage in product development and testing equipment and prototypes, which often fix a lot of resources and are under utilized or unnecessary since they do not provide really new information to the development process.
Overproduction/ Unsynchronized processes: It refers to excessive distribution of information lack of synchronization of processes/tasks not only in terms of time, but also the regarding contents, quantity and capacity.
Defects: In the product development environment the quality function do not to focus on parts meeting the specifications but on working out accurate and error-free specifications, functionality and performance of the product. Beside accuracy, the information must meet other attributes such as accessibility, relevancy, timeliness and interpretability.
Re-invention: It includes the lack of re-use of already existing design solutions, processes, methods, products and experienced knowledge from previous projects, which have a high potential to increase the quality and efficiency of product development.
Lack of system discipline: System discipline embraces a set of basic factors whose negative values would result in “disorganization” of the system. It occurs due to unclear goals, objectives, roles, responsibilities, rights and rules; poor schedule discipline; insufficient readiness to cooperate; and incompetence/ poor training. In this context, the meaning of the word ‘unclear’ is just the opposite of ‘clear’ which means few, simple, robust, verified and communicated.
Limited IT resources: The big variety of existing IT components (hardware, software, networks, etc.) within information systems, and the challenge in mapping the whole development process with its results on integrated data models, which should be useable by current and future software tools, are the causes of poor compatibility, capability and capacity (availability).
Requirements for a project plan to lean development
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 (Kennedy, 2003; Browning, Deyst, Eppinger & Whitney, 2002). 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, et al, 2002).
According to PMBOK® Guide (PMI, 2004, 41), the planning phase “defines and refines objectives, and plans the course of action to attain the objectives and scope that the project was undertaken to address”. The project plan is the planning phase main result; it guides execution and provides communication. To allow the Lean Product Development, besides lean itself, the project plan must focus on value creation and eliminate or at least reduce waste on the development environment. The five lean principles are the countermeasures against waste and through them the set of requirements the project plan must follow are defined:
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
According to Womack & Jones (1998), Toyota does not have a detailed step-by-step process describing how to do development. The lean product development work is done by dedicated teams that have the necessary abilities to perform all the project activities at a short period of time, where the design process would operate much like a single-piece flow in a manufacturing system. People allocated to definite but not very detailed tasks allow not only communication, but also cooperation and better use of competencies.
Every project task should be directed toward creating deliverables. An activity on a project is value-added if it transforms the deliverables of the Project in such a way that the customer recognizes the transformation and is willing to pay for it. Although this description sounds similar to the project schedule, the value stream is a theoretical and ideal sequence of exclusively value-added tasks (Mascitelli 2002). Thus, the project scope, which includes “the work that needs to be accomplished to deliver a product, service or result with the specified features and functions” (PMI, 2004, 104), must include only value-added work packages. The project network must contain only the activities needed to perform and support the value flow, avoiding unnecessary processes, approvals and transactions.
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. Everyone receives only the needed information (and nothing more) through the adequate media. Besides optimized, data traffic has to be synchronized to avoid process information overflow.
Principle 3: Guarantee the flow
To guarantee the flow, every development value flow obstacle must be eliminated, some examples are: functional departments, executive gate meetings, fire fighting, changing requirements and management interference (Mascitelli 2002). A new product design would move continuously from concept to production, without stopping due to bureaucratic needs and without backflow to correct mistakes (Walton, 1999).
This needed synchronization (information, work and resource capacity) can be achieved thorough a schedule that corresponds to the value flow and by an efficient authorization system that supports the early definition avoidance strategy. The plan has to clearly define what, when and by whom the work must be done, in a way that each resource role definition is unambiguous. Resources and materials allocation must strictly follow the amount and knowledge/features needed criteria, with no inappropriate use of competencies, tools and methods; must also avoid multitasking and over allocation (Bauch, 2004).
Principle 4: Pulling value
Once there is no totally predetermined way of developing the product, 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, the overall process follows certain logical orders and the experience from the past projects gives the engineers a good idea of the required input information and deliverables outputs (Bauch 2004). To make a pulled plan, then, the higher-level project activities must be linked in a simple way that helps to eliminate waste on their interfaces.
According to Mascitelli (2002), the value as defined by the final customer that pulls the product development, which itself pulls the project planning. Once the scope has been defined, Toyota uses the Set-Based Concurrent Engineering (SBCE). SBCE advances the concept of concurrent engineering to allow decisions to be delayed and design options to remain open until it is absolutely necessary to select a point solution. 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 (Kennedy, 2003).
The development team, thus, 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 (Exhibit 1c). 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.
Exhibit 1 – Traditional, agile and SBCE typical flows.
Principle 5: Seek perfection
This principle is a reminder that the improvement effort never ends, which takes team discipline and an ongoing intolerance of waste. Given a time frame, the amount of complete development cycles is much lesser than the usual frequency of manufacturing cycles, thus the improvement program must take advantage of every opportunity of knowledge learning. 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).
Summary of the requirements
A summary of the requirements and its relation to the lean principles and project management processes that are in the scope of this work is presented on Exhibit 2.
Exhibit 2 – Planning requirements, project management processes and related lean principles.
Traditional and Agile Planning Analysis
According to the planning requirements an analysis of the traditional (PMI, 2004) and agile (Chin, 2004) planning methods was held and the major issues on each of these approaches are highlighted.
Traditional Planning Analysis
Despite the fact that “the Project management plan content will vary depending upon the application area and complexity of the project” (PMI, 2004, 88) and that the team may “apply project management knowledge, skills, and processes in different orders and degrees of rigor to achieve the desired project performance” (PMI, 2004, 77), the collected outputs of the planning process may seem very complex and there is no way to guarantee the value flow has been mapped into the plan. This work focus its analyses on the processes of developing preliminary project scope statement, scope definition, create WBS, activity definition, and sequencing and risk identification, as presented in PMBOK® Guide 3rd Edition.
Issues on Developing preliminary project scope statement and Scope definition include:
- The PMBOK® Guide focus on project management: the product scope definition is beyond its scope and the initial processes have the Statement of Work – SOW as an input (believed correct and complete). So one cannot guarantee that all and only the client's value have been included on the project.
- Due to the stated on the previous item, even though during scope definition a thorough product analysis translates project objectives into tangible deliverables and requirements, the results may not explicitly incorporate the client's value.
- Other traditional approaches, though, include the problem and consequent product scope definition as a critical task to project success (Lewis, 2001; Kerzner, 2000).
Issues on the Create WBS process include:
- The previous stated problems may lead to a not value-added deliverables oriented WBS, which consequently will not include only value-added work packages.
- Once the specified value can encompass several deliverables, the breakdown can lead to loosing subsystems dependencies at lower levels.
Issues on Activity Definition and Sequencing include:
- The work packages breakdown into activities may increase even further the gap between the value and the planned work.
- The divide to conquer approach considers the decomposition of complex products or systems into smaller and simpler parts or subsystems, whose construction is prioritized according a “logical” sequence. To make it possible perfect information availability and timing is implicitly assumed (Kennedy, 2003).
Issues on Risk Identification include:
- In a task-based approach the schedule depends on stability from the start. As a result, many good ideas have to be set aside and many assumptions have to be made for early schedule efficiency (Kennedy, 2003).
- The resulting plan implements the task based approach (Exhibit 1a) (Kennedy, 2003), where:
- A proposal that includes a conceptual view of the product and a rather detailed task-based schedule on how to create it is made.
- This plan is followed until it fails whatever reason and triggers a series of loop backs, plan modifications and resource changes, until the product design finally makes it to manufacturing.
- Because that one is always late and over budget and even with a sub-optimized solution.
Agile Planning Analysis
The agile planning, by the other hand, is more emphatic on the iterative approach. Here the detailed plan must only include the foreseeable future, which is much more adequate to technological and innovative projects, where some project's aspects remain fuzzy during the initial phases. Instead of working on the project scope to determine the budget and the schedule, the opposite way is taken by fixing schedule and making only the compatible scope (Anderson, 2003).
Even though reducing the commitment horizon, it still does not give a consistent alternative to the break down problem and do not suggest any solution to loop backs (though they are shorter, Exhibit 1b).
We have put forward the ten waste drivers on product development and how the five lean principles can act as countermeasures in this case. We argued that a project plan must fulfill a set of requirements to allow the lean product development:
- Value based: The product scope must incorporate all and only the customer value.
- Deliverable oriented: Every project task should be directed toward creating deliverables, which themselves must materialize the value.
- Lean itself: The planning process and the plan itself must promote the waste drivers avoidance during execution.
- Synchronization: the scope and activities definition and sequencing changes must keep the bottom-level dependencies, where the project result is achieved through a stepwise value aggregation effort.
- SBCE compatible: Technical risk avoidance can be achieved through parallel development of alternatives.
- Knowledge capture: The improvement program must systemically take advantage of every opportunity of learning.
Unfortunately neither the traditional planning nor the agile approach explicitly guarantees these requirements. To solve the issues raised, though, there is the need of a new perspective on planning and the adaptation/creation of specific tools and techniques that support the lean development paradigm, which we purpose as a future work.
Anderson, D. J. (2003) Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. Upper Saddle River, NJ: Prentice Hall.
Bauch, C. (2004) Lean Product Development: Making waste transparent. Diploma Thesis. Cambridge, MA: Massachusetts Institute of Technology.
Browning T.; Deyst J.; Eppinger S. & Whitney D. (2002) Adding value in product development by creating information and reducing risk. IEEE Transactions Engineering Management, 49(4):443–458.
Chin, G. (2004) Agile project management: how to succeed in the face of changing project requirements. New York, NY: AMACON.
De Meyer, A.; Loch, C. H. & Pich, M. T. (2002) Managing project uncertainty: From variation to chaos. Sloan Management Rev, vol. 43, no. 2, pp. 60–67.
Kennedy, M. N. (2003) Product development for the lean enterprise. Richmond, VA: Oaklea Press.
Kerzner, H. (2000) Applied project management: best practices and implementation. New Jersey: John Wiley & Sons.
Lewis, J. P. (2001) Project planning, scheduling and control. New York, NY: McGraw-Hill.
Mascitelli, R. (2002) Building a project-driven enterprise. Northridge, CA: Technology Perspectives.
Mihm, J.; Loch, C. H. & Huchzermeier, A. (March, 2002) Modeling the Problem Solving Dynamics in Complex Engineering Projects. INSEAD Working Paper. Fontainebleau, France: INSEAD.
Murman, E., Allen, T., Bozdogan, K., Cutcher-Gershenfeld, J,, McManus, H., Nightingale, D., Rebentisch, E., Shields, T., Stahl, F., Walton, M., Warmkessel, J., Weiss, S. & Widnall, S. (2002) Lean Enterprise Value: Insights from MIT's Lean Aerospace Initiative. New York, NY: Polgrave.
Project Management Institute. (2004) A guide to the project management body of knowledge (PMBOK®) (3rd ed.). Newtown Square, PA: Project Management Institute.
Salzman, R. A. (2002) Manufacturing System Design: Flexible Manufacturing Systems and Value Stream Mapping; Thesis (S.M.) Mechanical Engineering. Cambridge, MA: Massachusetts Institute of Technology.
Spear, S.& Bowen, K. (1999) Decoding the DNA of the Toyota Production System. Harvard Business Review Article, Sept - Oct 1999. Boston, MA.
Thomke, S. & Bell, D. E. (2001) Sequential testing in product development. Management Sci., vol. 47, no. 2, pp. 308–323.
Walton, M. (1999) Strategies for Lean Product Development: A Compilation of Lean Aerospace Initiative Research. Research Paper 99-02. Cambridge, MA: Massachusetts Institute of Technology.
Womack, J. P.; Jones, D. T.; & Ross, D. (1990) The Machine that Changed the World. New York, NY: Rawson Associates.
Womack, J. P.& Jones, D. T. (1998) A mentalidade enxuta nas empresas. São Paulo, SP: Editora Campus.
© 2006, Marcus Vinicius Pereira Pessoa
Originally published as a part of 2006 PMI Global Congress Proceedings – Madrid, Spain