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 fitness to the lean development. Finally some answers are presented to explain 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 as one of their core processes; optimizing this process, regardless if 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.
Traditional PM, though, needs good product knowledge as an input and uses a divide to conquer strategy to breakdown the work packages and define activities. Due to these premises, the more technological the product, 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 does not directly solve the breakdown problem.
So, by effectively using or not giving an alternative to the divide to conquer strategy, both traditional and agile PM, do not reduce the loop backs and the rework caused by the lack of product's subsystems coupling understanding. In order to enlighten the path to a solution, this work analyses the processes of developing preliminary project scope statement, scope definition, create WBS, activity definition, and sequencing and risk identification, as purposed by PMBOK® Guide. The analysis is based on the following premises:
- The Lean Product Development, depicted by Toyota and Honda development systems, is a benchmark in automotive industry and has been widely accepted in other sectors with dramatic benefits (Exhibit 1).
- The project planning phase main objective should be to support the execution phase: the Lean Product Development.
This work objective, thus, is to identify the preconditions the analyzed processes must fit to allow the lean development, and to 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. In order to achieve this objective, this paper is organized as follows: First, we offer remarks about the lean product development. Next, we present the preconditions a project plan must be adherent to be itself lean and allow the lean development. Finally, we will discuss the preconditions compliance to traditional and agile planning and will summarize the information in our concluding remarks.
Exhibit 1 – Samples of the best results from various companies. (Source: Walton, 1999)
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 was k 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 overcome 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: 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 better 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 and 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
According to PMBOK® Guide (PMI, 2004, p 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 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, p104) 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, p104), 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, 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; it 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 2c). 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 2 – 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 does not work. This knowledge is systemically documented and disseminated through trade curves, to which everyone has ready access and is expected to use, including management (Kennedy, 2003).
A summary of the requirements and its relation to the lean principles and project management processes is presented on Exhibit 3.
Exhibit 3 – 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, p88) 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, p77), 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.
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 what is 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 loosening 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 2a) (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, for whatever reason, and triggers a series of loop backs, plan modifications and resource changes, until the product design finally makes it to manufacturing.
- Because one is always late and over budget and even with a sub-optimized solution.
Agile Planning Analysis
The agile planning, on 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 2b).
In this case, we have put forward the ten waste drivers on product development and how the five lean principles can act as countermeasures. 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 for learning.
Unfortunately neither the traditional planning nor the agile approach explicitly guarantees these requirements. To solve the issues raised, though, there is no need of radical changes on planning, instead the lean philosophy demands only a new perspective on planning. There still remains the lack of specific tools and techniques that support the lean development paradigm, which we propose 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.
Chin, G. (2004) Agile project management: how to succeed in the face of changing project requirements. New York, NY: AMACON.
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.
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.
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.
© 2005, Marcus Vinicius Pereira Pessôa & João Murta Alves
Originally published as a part of 2005 PMI Global Congress Proceedings – Toronto, Canada
Hurricane Katrina decimated thousands of buildings in New Orleans, Louisiana, USA, in 2005, including a U.S. Department of Veterans Affairs (VA) medical facility that served approximately 40,000…
Federal Project and Program Management Community of Practice (FedPM CoP) – How Sharing Best Practices Can Lead to Success
Recognizing the value of a community focused on project practice capability and how such a community could help improve the performance of departments across the U.S. federal government, the leaders…
Developing a Project Management Office in the Department of Energy, Energy Information Administration
This case example, a supplement to the report, PMIAA: Strengthening the Government Delivery Foundation, highlights project and program management capability building within The U.S. Energy…
Commissioned and supported with research from PMI, MIT’s Consortium for Engineering Program Management, and others, this report distills how many government agencies have been leading (and continue…