Lean Enablers for Systems Engineering
Bohdan W. Oppenheim1, *, Earll M. Murman,2, † and Deborah A. Secor31Department of Mechanical Engineering, Loyola Marymount University, Los Angeles, CA 90045-8145 2Port Townsend, WA 98368
3Rockwell Collins, Engineering & Technology, 400 Collins Road NE, Cedar Rapids, IA 52498 LEAN ENABLERS FOR SYSTEMS ENGINEERING
Received 10 December 2008; Revised 13 June 2009; Accepted 11 November 2009, after one or more revisions Published online in Wiley InterScience (www.interscience.wiley.com)
DOI 10.1002/sys.20161
ABSTRACT
Systems Engineering (SE) is regarded as a sound practice but not always delivered effectively, as documented in recent NASA, GAO, and DoD studies. Lean Thinking is the holistic work system credited for the extraordinary rise of Toyota to the most profitable and the largest auto company in the world. Lean Thinking has been successfully applied in other work fields such as general manufacturing, aerospace, healthcare, and service industries. The emerging field of Lean Systems Engineering (LSE) is the applica-tion of Lean principles, practices, and tools to SE and to the related aspects of enterprise management (EM) in order to enhance the delivery of value (which is defined as flawless delivery of product or mission with satisfaction of all stakeholders) while reducing waste. This paper contains four parts: (1) historical background of the new field of LSE and a review of the fundamental concepts of Lean Thinking; (2) the development process of a new product called “Lean Enablers for Systems Engineering”; (3) a list of the Enablers organized into six Lean principles; (4) summary and conclusions. The Lean Enablers for Systems Engineering is a comprehensive checklist of nonmandatory practices and recommendations formulated as “do’s” and “don’t’s” of SE, and containing tacit knowledge (collective wisdom) on how to prepare for, plan, execute, and practice SE and EM using Lean Thinking. Each enabler has the potential to enhance program value and reduce waste. The Enablers are formulated as a web-based addendum to the current SE Handbook published by the International Council for Systems Engineering (INCOSE), and do not repeat the practices made therein, which are regarded as sound. They should be an equally valuable addendum to other SE handbooks such as NASA, DoD, or company manuals. The enablers’ development followed a classical process: Concept, Alpha, Beta, Prototype, and Version 1.0. This paper reports on Version 1.0 of the enablers, which are regarded as mature enough for dissemination, but which are intended to be a living online document to be continuously improved by interested practitioners as new knowledge and experience are acquired. The enablers were evaluated by surveys in the Beta and Prototype phases. The Prototype version has also been benchmarked with recent NASA and GAO studies. This project has been carried out by two core teams involving 14 volunteers from the LSE Working Group of INCOSE. The teams included representatives from industry, academia, and governments from United States, Israel, and the United Kingdom, with cooperation from the LSE Working Group membership at large. © 2010 Wiley Periodicals, Inc. Syst Eng
Key words: Lean; Lean Thinking; Lean Enablers; Lean Systems Engineering, systems engineering; Lean Product Development
* Author to whom all correspondence should be addressed (e-mail: [email protected];[email protected]).
† Ford Professor of Aeronautics and Astronautics, Massachusetts Institute of Technology, Cambridge, MA (retired).
Systems Engineering © 2010 Wiley Periodicals, Inc.
ABBREVIATIONS
AFIS Association Française d’Ingénierie Système (French Chapter of INCOSE)
AIAA American Institution for Aeronautics and As-tronautics
AR Acquisition Reform (of DoD) CAE Computer Aided Engineering CE Concurrent Engineering CI Continuous Improvement DoD Department of Defense
EADS European Aeronautic Defense and Space Com-pany
EdNet LAI Educational Network
ELOP Elbit Systems Electro-Optics, Israel EM Enterprise Management
FBC Faster, Better, Cheaper
GAO Government Accountability Office GE General Electric
HALT/HASS Highly Accelerated Life Test/Highly Ac-celerated Stress Screen
IPTs Integrated Product Teams
ISO International Standards Organization
INCOSE International Council on Systems Engineering JSF Joint Strike Fighter (F-35)
LAI Lean Advancement Initiative, formerly Lean Aero-space Initiative, formerly Lean Aircraft Initiative LEfSE Lean Enablers for Systems Engineering LEM Lean Enterprise Model
LMU Loyola Marymount University LPD Lean Product Development LSE Lean Systems Engineering
LSE WG Lean Systems Engineering Working Group MAAC Major American Aerospace Company MIT Massachusetts Institute of Technology MoD Ministry of Defense (in the United Kingdom) NASA National Aeronautics and Space
Administra-tion
NBC National Broadcasting Company (TV channel) PD Product Development
PDCA Plan, Do, Check, Act, improvement cycle PM Project Management
RAA Responsibility, Accountability, Authority RASI Responsible, Approving, Supporting, and
In-forming
RFP Request for Proposals RNVA Required Non-Value Added SBIRS Space Based Infrared System
SE Systems Engineering, or Systems Engineer TQM Total Quality Management
U.K. United Kingdom U.S. (US) United States
USAF United States Air Force VA Value Added
WG Working Group 1. INTRODUCTION
This paper presents a group of practices named “Lean En-ablers for Systems Engineering (LEfSE)” based on the
holis-tic Lean Thinking paradigm. LEfSE are intended as a supple-ment to existing SE practices with the objective of improving the overall value delivered by Systems Engineering. In this context, Lean Systems Engineering does not mean less sys-tems engineering, but rather better syssys-tems engineering. Lean Thinking, which originated from Toyota, has been applied in many fields including manufacturing, product development, healthcare, and more. The intent of this paper is to extend the application of Lean Thinking to Systems Engineering.
Section 1 includes a historical note placing Lean in the context of earlier industrial paradigms starting with Total Quality Management, and proceeding Concurrent Engineer-ing and Six Sigma. A summary of the basic principles of Lean Thinking is included. Lean in Product Development (PD) and the emerging field of Lean Systems Engineering (LSE) are then summarized. Also described is the organizational evolu-tion of the team developing the Enablers: from the Lean Advancement Initiative’s Education Network to the Interna-tional Council for Systems Engineering (INCOSE). Section 2 presents the development process of LEfSE including the phases named Conceptual, Alpha, Beta, Prototype, and Ver-sion 1.0. VerVer-sion 1.0 is presented in Section 3 using the framework of Lean Principles. The Beta and Prototype ver-sions have been evaluated by surveys and the Prototype also by benchmarking with recent NASA and GAO publications. Version 1.0 is regarded as mature enough for presentation to the professional community. However, the intent is to con-tinue involving the community of practice in gathering data and experiences and improve the product using formal online change process. Summary and Conclusions are included in Section 4.
1.1. From TQM to Six Sigma and Lean
Lean Thinking, or more briefly Lean, as used in this work is an evolutionary industrial paradigm incorporating elements from earlier paradigms of Total Quality Management (TQM) and Concurrent Engineering (CE) as well as elements of Six Sigma. In common with TQM and CE, Lean focuses on designed-in/built-in quality, Deming continuous improve-ment cycles, and engageimprove-ment of front line workforce in proc-ess improvement. It goes beyond TQM and CE to adopt a value stream focus and a relentless pursuit of waste elimina-tion. While Lean, TQM, and CE all focus on process improve-ment, Lean particularly focuses on streamlining flow between the processes. Sharing with Six Sigma a data driven approach to elimination of process variation, it differs by being more bottom-up in its improvement strategy and less reliant on formalized qualification of improvement experts. As with the other improvement paradigms, successful Lean implementa-tion relies on committed leadership and an enterprise-wide approach across all functions, including systems engineering. Three 1970s era events in the U.S. provided a fertile ground for subsequent dynamic changes of industrial paradigms: (1) the oil embargoes which made small cars attractive to con-sumers, (2) the overtaking of the consumer electronic and auto markets by the higher quality and less expensive Japanese imports, and (3) a widespread perception that the U.S. manu-facturing was falling behind the international competition, particularly in quality. In 1980, NBC TV broadcast a 2-hour
program titled “If Japan can why can’t we?” opening U.S. eyes to a new management paradigm named “Total Quality Management” (TQM) which swept the industry by storm in the early 1980s. Led by Deming [1982]. it was an attempt to adopt the successful Japanese industrial management meth-ods to the U.S. industry. A strong message of TQM was that pursuit of higher quality is compatible with lower costs. Inexpensive and high-quality automobiles and consumer electronic goods imported from Japan made this notion self-evident to U.S. consumers, but not necessarily to U.S. indus-try.
TQM emphasized “total” approach to quality, integrating management, processes and tools, and developing business strategy focused on customer satisfaction. It promoted con-tinuous improvement of all processes, and popularized im-provement tools such as a bottom-up employee suggestion system, quality circles, quick reaction Kaizen teams, and process variability reduction using Statistical Process Con-trol. TQM emphasized the importance of corporate culture based on respect for people and employee empowerment as prerequisites for continuous improvement, and relied heavily on self-motivation of employees. It also promoted designing quality into both products and processes, rather than relying on the final inspection.
TQM received strong support from the U.S. federal gov-ernment, including the Department of Defense [DoD, 1988]. Following the Japanese E. Deming Award, the Department of Commerce initiated the Malcolm Baldridge Award in 1987 as a motivational recognition of the best U.S. companies. The award used a point score which was based on the above TQM elements. The application of TQM to U.S industry had mixed outcomes. While quality improved, especially in the auto industry, profits did not follow proportionately. Even the quality improvements alone failed in many companies that tried TQM [Paton, 1994]. The earlier pessimism in the manu-facturing industry continued, and contributed to the sub-sequent export of nearly 60% of commercial manufacturing to cheaper labor markets.
About 8 years into the TQM period, Costello [1988], in his capacity as Under Secretary of Defense for Acquisitions, presented an alarming report to the Secretary of Defense about serious problems plaguing the U.S. commercial and military industrial base, including foreign competition, poor quality of both products and business management, frag-mented research and development, low quality of public education, and declining numbers of engineers and scientists. Four years later, Costello and Ernst [1992] reinforced this report with a white paper about the state of U.S. industry, recommending wide-ranging improvement of the manufac-turing sector, streamlining regulations, better means for tech-nology sharing, and aggressive support for small business. The lack of widespread business success made TQM vulner-able to criticisms and opened the way to new ideas. Business Week [Byrne, 1997] declared TQM as a “dead fad,” blaming TQM’s “lack of teeth” in implementation. While today the term TQM has receded, most of the key elements of TQM have endured and are integral to Lean Thinking [Murman et al., 2002].
In late 1980s the Concurrent Engineering (CE) industrial paradigm became popular and was proposed as a way to
shorten the weapons system acquisition cycle [Winner et al., 1988]. CE promoted simultaneous and integrated design of product and subsequent phases (manufacturing, assembly, operations, etc.), replacing the traditional disjointed and serial effort. An important component of CE was multifunctional design teams, sometimes called Integrated Product Teams or IPTs, which included representatives from the subsequent phases in the upfront engineering design. CE when effectively implemented with electronic design tools and workforce training led to dramatic reduction in design rework and, consequently, cost and schedule (e.g., see Hernandez [1995]). CE contributed major improvements to U.S. product devel-opment and engineering, and spawned significant new design methodologies (e.g., see Clausing [1994] and Ulrich and Eppinger [2008]). TQM and CE made important contribu-tions to major new aircraft products in the 1990s, such as the Boeing 777 and Cessna Citation-X [Haggerty and Murman, 2006]. As with TQM, CE principles are embedded in current day Lean Thinking [Murman et al., 2002; McManus 2004]. In the early 1990s TQM evolved into another quality initiative called Six Sigma, arguably with “better teeth.” According to Wedgewood [2007], “Six Sigma is a systematic methodology to home in on the key factors that drive perform-ance of a process, set them at the best levels, and hold them there for all time.” Originating at Motorola and relying on rigorous measurement and control, Six Sigma focused on systematic reduction of process variability from all sources of variation: machines, methods, materials, measurements, peo-ple, and the environment [Murman et al., 2002]. Like TQM, Six Sigma aims to achieve predictable, repeatable, and capa-ble processes and defect free production, where parts and components are built to exacting specs. But unlike the moti-vational TQM it achieves this by rigorous data collection and statistical analysis, as well as by rigorous training of leaders.1
Six Sigma was not free of problems. It often was imple-mented with a costly bureaucracy, introducing “the waste of measuring waste” and was criticized for being too top-down, and for displacing two other critically important continuous improvement tools of TQM: Kaizen and the bottom-up em-ployee suggestion system, which Toyota credits for a half of its success [Oppenheim, 2006]. Six Sigma can also be prone to suboptimization by focusing too narrowly on process im-provement for a process that may not be needed. Murman et al. [2002] described this deficiency as “a focus on the job being done right, but not necessarily on the right job.” It was the next step in the industrial evolution, called Lean, that provided the integrated focus on the right job and doing the job right, and also on the corporate culture needed for both. Following a similar path as TQM and CE, the Six Sigma movement spawned new Design for Six Sigma methodolo-gies [e.g., Yang and El-Haik, 2003].
The term Lean as an industrial paradigm was introduced in the United States in the bestselling book, The Machine That Changed the World, The Story of Lean Production published by the MIT International Motor Vehicle Program [Womack, Jones, and Roos, 1990], and elegantly popularized in their 1Following the ju-jitsu language, the Six Sigma leaders are designated by
“belts” of various colors which denote different levels of training and experience.
second bestseller Lean Thinking, [Womack and Jones, 1996]. The authors identified a fundamentally new industrial para-digm based on the Toyota Production System. The parapara-digm is based on relentless elimination of waste from all enterprise operations, involving the continuous improvement cycle that turns all front-line workers into problem solvers to eliminate waste. Lean strives for minimum waste to deliver high quality and defect-free products meeting customer demand just-in-time, at the rate ordered, with minimum inventories, at mini-mum cost, and in the minimini-mum time, and is driven by a unique corporate culture of respect, empowerment, openness, and teamwork. Factories adopting Lean observed direct and dra-matic improvements of operations and increases in profits. Womack and Jones [1996] described six manufacturing case studies that demonstrated reductions of cost, lead time and inventory of up to 90%, with simultaneous improvements in product quality and work morale across a wide range of company types and sizes. More dramatically, leadtime and cost reductions on the order of 30–50% were realized rou-tinely after only a few days of implementation on the factory floor, by simple rearranging of machines into the flow [LEI, 2007]. After the multiyear implementation efforts of TQM, CE, or Six Sigma, this was a revelation. Within a few years, Lean production has become the established manufacturing paradigm pursued by all competitive factories.
Three concepts are fundamental to the understanding of Lean: Value, Waste and the process of creating value without waste captured into the so-called Lean Principles. Box 1 describes these Fundamentals.
In the subsequent text, any enterprise process which fol-lows the six Lean Principles will be regarded as Lean. As a corollary, any practice that enables the Value and follows the Lean process will be defined as a Lean enabler.
As already mentioned, Lean incorporates many of the TQM, CE and Six Sigma principles and practices. However it goes beyond them to adopt a holistic value stream approach and relentless waste elimination. The value stream represents the linked end-to-end activities that turn raw material or information into products and services needed by the cus-tomer. Waste represents those activities that do not directly contribute to customer value. Often these are activities taking place between valued added activities, such as wait time or inspection. Lean strives for optimum flow with no blockages or unplanned rework.2
Toyota’s original “father” of Lean, Ohno [1988], summa-rized it thus: “All we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash. And we are reducing that time line by removing the non-value added wastes.” Ohno classified waste in manufacturing into seven categories: (1) Overproduction; (2) Transportation; (3) Waiting; (4) Overprocessing; (5) In-ventory; (6) Unnecessary movement; and (7) Defects. Several
authors have adapted Ohno’s seven production wastes to Product Development (see the following Lean in Product Development subsection). A number of lean organizations have added an 8th waste to Ohno’s list—the waste of human talent—recognizing that front line workers are the most knowledgeable resource for improvement.
The Toyota Lean extends over the entire enterprise, includ-ing not only manufacturinclud-ing but also design and engineerinclud-ing, supply chain, and all supportive activities [Morgan and Liker, 2006]. In contrast, the initial successes of Lean in the U.S. were recorded mostly in manufacturing [Womack and Jones, 1996]. This created an unintended misperception that Lean applies only to high volume production. An important expan-sion of Lean outside of the manufacturing environment oc-curred in 1993, when, at the urging of the U.S. Air Force, Massachusetts Institute of Technology (MIT) initiated a con-sortium of aerospace and defense corporations and the U.S. military, named the Lean Advancement Initiative3 (LAI)
[LAI, 2007], to pursue research and application of Lean Thinking into enterprise architecting and transformation, en-gineering, product development, supply chain management, change management, and systems engineering. Since that time, LAI produced hundreds of Master’s and Ph.D. theses, publications, conferences, and tools devoted to those Lean applications [LAI, 2007], and a comprehensive book Lean Enterprise Value [Murman et al., 2002]. The latter reference introduced the following definition of “Lean Thinking,” used in this paper:
Lean Thinking: the dynamic, knowledge-driven, and cus-tomer-focused process through which all people in a defined enterprise continuously eliminate waste with the goal of creating value.
The successes of Lean in repeatable manufacturing led to a popular misconception that Lean does not apply to one-off applications such as engineering projects or SE. In such projects, the deliverables and work content of engineering tasks are indeed “one-off,” but the processes and individual tasks should use repeatable logic based on best engineering practices. For example, the established process for a modal analysis of a structure involves the same steps: define geome-try, boundary conditions, and material properties, perform final element meshing, calculate the modal eigenvectors and eigenvalues, compare the latter to the excitation spectrum, identify dangerous modes, design vibration mitigation, and report. Such established processes exist for the vast majority of engineering applications, including SE. Therefore, we pro-pose that the basic principles of Lean Thinking apply to SE.
Lean Thinking has been applied to diverse work environ-ment applications from manufacturing [e.g., Womack and Jones, 1996] to product development [e.g., Ward, 2007] and engineering [e.g., McManus, Haggerty, and Murman, 2007] to supply chain management [e.g., Bozdogan, 2004] to health-care [e.g., Graban, 2008] to educational [e.g., Emiliani, 2004], 2Some might ask how the focus on flow differs from Henry Ford’s moving
line mass production or from “rhapsodized industrial engineering.” Indeed there are common elements. However, there are important distinctions. Lean emphasizes the importance of the front line workers as problem solvers, unlocking the enormous human resource potential for process improvement. Lean also focuses on “single piece flow,” compared to “batch and queue,” which leads to cellular work arrangements.
3Initially named Lean Aircraft Initiative, renamed Lean Aerospace Initiative
in 1997 after the space industry joined the consortium, and in 2007 again renamed Lean Advancement Initiative after the remaining U.S. military services joined.
and to enterprise management [Jones, 2006; LESAT, 2001]. This paper reports on application of Lean to Systems Engi-neering, and how that relates to lean product development. 1.2. Lean Six Sigma
As mentioned above, Lean and Six Sigma both appeared in the post TQM mid 1990s era as seemingly competing process improvement approaches. Six Sigma, identified with Mo-torola and subsequently with GE, gained investor visibility and popularity. Lean identified with Toyota was incorrectly looked upon as limited to high volume manufacturing appli-cations. While Six Sigma focuses on a disciplined, top-down approach to eliminating all forms of variation, Lean focuses on value streams and relentless elimination of waste through optimizing flow. The latter relies on the former to eliminate impediments to flow, and in fact the basic principles of the two approaches are synergistic. By the early 2000 period, most organizations adopted a blended version of the two bodies of knowledge and crafted them to meet their particular needs. Names such as Lean Six Sigma, Lean Sigma, and other less obvious combinations appeared. Today, most organiza-tions have harmonized Lean and Six Sigma. In this paper, we will continue to use the Lean nomenclature, not to exclude Six Sigma thinking, but to treat Lean Enablers for Systems Engineering as integrated body of knowledge based on lean, Six Sigma, high performance work systems and other process improvement approaches.
1.3. Lean in Product Development (LPD)
Toyota is widely recognized as the leader in LPD. Its practices have been described by a number of oft-cited articles and
books: Ward et al. [1995a, 1995b], Sobek [1997a, 1997b], Sobek, Liker, and Ward [1998], Sobek, Ward, and Liker [1999], Liker et al. [1996], Kennedy [2003], Liker [2004], and Morgan and Liker [2006]. Clark and Fujimoto [1991] pub-lished a comprehensive approach to PD, introducing strategic metrics of automotive enterprise performance—lead time, quality, and productivity—and described PD project integra-tion, strategy, planning, managing complexity, integrating problem solving cycles, and the Toyota and Honda project management style which they called “heavyweight.”
The need for Lean Thinking in PD in aerospace programs was manifested by several LAI studies of waste in actual aerospace programs. They have been discussed at length in Murman et al. [2002] and Oppenheim [2004] and are only briefly summarized herein: The amount of waste in govern-ment PD programs has been estimated at 60–90% of the charged time, with about 60% of all tasks being idle at any given time [Browning, 1998, 2000; Chase, 2001; Joglekar and Whitney, 2000; McManus, 2004; Millard, 2001; Young, 2000]. Figure 1 illustrates the amount of wasted effort by individuals and time by work packages in aerospace programs [McManus, 2004]. The right-hand chart in the figure shows that a given task is only being worked on for 38% of its existence. By implication from the left-hand chart, of that 38% time, only about a third of it, or 12–13% of the total task lifetime, has any value-added actions. According to these authors, while the estimates arguably lack scholarly rigor, they are consistent enough across corporations, programs, and years, to yield a comfortable level of confidence. This large amount of waste implies a vast reserve of productivity in PD,
and an opportunity to make significant progress using Lean Thinking.
The waste in traditional PD programs, not necessarily limited to aerospace, results from a number of causes: craft mentality of engineers, poor planning, ad hoc execution, and poor coordination and communication culture [Oppenheim, 2004]. Ward [2007] devotes an entire chapter to “Seeing Waste in Product Development,” grouping them all as “Waste of Knowledge.” Millard [2001] and Morgan and Liker [2006] have adapted Ohno’s seven wastes of manufacturing to PD. The Morgan and Liker version is shown in Box 2. In govern-ment programs, additional reasons for wastes include the government and corporate practices which are contrary to Lean Thinking, which are discussed in Section 2.
Figure 2 illustrates the most frequently observed waste in 27 aerospace PD programs [Slack, 1998]. It is interesting that the most frequently cited waste is waiting for information, while the second most cited waste is over processing. To paraphrase the finding, one person is waiting while another person is over processing the information.
In the 2000s important contributions to LPD were made by the individuals associated with the LAI community: McManus [2004] published a manual for PD Value Stream Mapping; Oppenheim [2004] reformulated the Toyota manu-facturing approach to the field of legacy-based product devel-opment using five Lean Principles; Rebentisch [2005] presented a seminal lecture on LPD which became a starting point for several subsequent studies of the field; Rebentisch and McManus [2007] developed a teaching simulation for Lean Enterprise Product Development, as well as a tutorial on LPD of complex products; Murman [2008] and Haggerty and Murman [2006] comprehensively described the use of Lean in specific aerospace engineering programs, although most of the programs were not set up to be Lean and demonstrated strong Lean characteristics only on post analysis. Lempia [2008] and Egbert et al. [2008] describe two PD programs which were set up using Lean principles. Private contacts of the authors with industry in the U.S. and Europe indicate that many more attempts to implement Lean into PD are ongoing, but no publications are yet available. In summary, at this time LPD is regarded as a body of knowledge which is needed, fast
Box 2. Seven Categories of Waste [Morgan and Liker, 2006]
Figure 1. Waste measured in aerospace programs [McManus, 2004].
Figure 2. Most frequently observed waste in 27 programs [Slack, 1998].
growing, showing emerging successes, but not fully estab-lished yet.4
1.4. Lean Expands into Systems Engineering SE has been called the nervous system of PD [Hitchens, 2007]. It is an inherent part of PD, strongly coupled to it both in time and throughout numerous enterprise nodes. Because of the significant effort to apply Lean Thinking in PD, and because Toyota’s successes in PD, it is not surprising that SE became a challenge for Lean Thinking. The emerging body of knowledge has been named Lean Systems Engineering (LSE).
The birth of LSE is traced to the first meeting of the LAI Educational Network in March 2003. In 2003, the LAI con-sortium invited universities to join the new LAI Educational Network (EdNet). The EdNet stated mission is to collaborate on the development and dissemination of lean curricula, in-cluding incorporation of research findings. Starting with LMU, at the time of this writing the EdNet has grown to 48 universities it the U.S., U.K., Mexico, Europe, and Brazil. The EdNet members soon organized themselves into a number of small working groups, one devoted to LSE, and another to LPD, intending to develop communities of practice in these new fields. Subsequently Murman included the LSE topic in two lectures of a graduate course on Aircraft Systems Engi-neering in the fall of 2003 [Murman, 2003]. The LAI team of Rebentisch, Rhodes, and Murman [2004] laid theoretical foundations for LSE. Additional concepts and case studies were contributed by a panel on LSE at INCOSE 2004 [Rhodes et al., 2004].
These early works defined the synergy of Lean and Sys-tems Engineering as (paraphrased): “Systems Engineering
which grew out of the space industry5 to help deliver flawless
complex systems is focused on technical performance and risk management. Lean which grew out of Toyota to help deliver quality products at minimum cost is focused on waste mini-mization, short schedules, low cost, flexibility, and quality.
Both have the common goal to deliver system lifecycle value to the customer. Lean Systems Engineering is the area of synergy of Lean and Systems Engineering with the goal to deliver the best lifecycle value for technically complex sys-tems with minimum resources.” This synergy gave rise to the subsequent definition of LSE:
Lean Systems Engineering is the application of Lean princi-ples, practices and tools to Systems Engineering in order to enhance the delivery of value to the system’s stakeholders [INCOSE, 2009].
1.5. The Home: The Lean Systems Engineering Working Group of INCOSE
During 2004–2006, the LAI EdNet LSE group met several times and enjoyed interesting discussions; however, not much progress was made. In order to move the LSE project at a faster pace, at the end of 2005 a proposal was made to the International Council on Systems Engineering (INCOSE) to form a new Lean Systems Engineering Working Group (LSE WG), hoping to draw from the collective wisdom of the large membership of SE practitioners that belong to that learned society.6 The proposal was accepted. The first meeting (rather
poorly advertised) drew 30 people, which indicated a high level of interest in the idea of applying Lean Thinking into SE. Since that time, the Group has grown to over 100 indi-viduals, all unpaid volunteers, and is currently one of the largest Working Groups of INCOSE. Most of the members are experienced industrial SEs, but the experience in Lean Thinking was less common. The individuals most experi-enced with Lean acted as leaders in this project (listed in the Acknowledgements).
The use of term Lean in the context of SE occasionally met with concern that this might be an attempt to “re-package Faster-Better-Cheaper7 (FBC)” initiative, leading to cuts in
SE at the time when the profession is struggling to increase the level and quality of the SE effort in programs. Hopefully, this paper will categorically disprove these concerns. The WG challenge was to demonstrate that Lean SE does not mean less SE but better SE, leading to subsequent streamlined program execution.
The LSE WG devoted the first 18 months to conceptual and administrative tasks (creation of website and mailing list, definitions, recommended readings, and formulation of the charter), as well as presentations and panels devoted to vari-ous ideas how to proceed. The dedicated web site contains these results to-date, [INCOSE LSE WG, 2008]. Box 3 con-tains the LSE WG Charter. Since October 2007, the main effort of the WG was devoted to the development of Lean Enablers for Systems Engineering.
4When this paper was readied for final submission, the authors learned of the
new book on PD flow by Reinertsen [2009]. The book formulates 175 principles of Lean PD organized into novel categories. Upon quick reading, there are similarities with LEfSE, as well as ideas which have not been included in the present work. Hopefully, the next release of LEfSE will be able to integrate both LEfSE enablers and selected new principles.
5The modern discipline of SE was developed in the ballistic missile program
by Si Ramo and Dean Woldridge in 1954, with the first formal contract to perform “systems engineering and technical assistance (SETA).” Under this contract, Ramo and Wooldridge developed some of the first principles for SE and applied them to the ballistic missile program—considered the most successful major technology development effort ever undertaken by the U.S. government [Jacobsen, 2001]. Si Ramo told Brown [2009] that he thought the first use of systems engineering in modern times was at AT&T when they had to consider how to assemble a world-wide telephone system. However, AT&T did not consider it systems engineering and did not use that name.
6Over 39 working groups are currently carrying out INCOSE’s goals, which
include the development and dissemination of SE knowledge, international collaboration, development of standards, improvement of professional status of SE practitioners, and encouragement of governmental and industrial support [www.INCOSE.org].
7FBC was the NASA initiative. A similar initiative was named “Acquisition
Reform” (AR) by the DoD. Both were blamed for numerous failures of space systems during the 1990s, which added up to $12 billion losses in space systems. The subsequent study sponsored by a the U.S. Congress [T. Young, 2000] diagnosed that FBC/AR removed much of government oversight, made prior mandatory standards optional, and permitted the contractors to cut Systems Engineering effort and many tests. These cuts, according to the study, led to the failures. The report recommended a stronger role of SE in programs, and a return to the oversight, standards, and testing “as you fly.” The time after this report was published is often referred to as the post-FBC/AR period, which has been continuing until the time of this writing.
2. DEVELOPMENT OF LEAN ENABLERS 2.1. LSE WG Initial and Boundary Conditions SE applies to all engineering domains, but has been practiced under that name mostly in governmental programs. The re-cord of these programs is mixed. The examples of successful programs include: the 60 successful military satellite lunches since the last major failures of the FBC/AR period [Horejsi, 2009], all but two successful space shuttle flights, continued construction of the space station, some well-known inter-planetary flights, some successful missile defense tests, and numerous successes in air, ground, and water-borne systems. These examples indicate that the established SE process can be capable of delivering successful complex systems when practiced properly.8 During the same period, abundant
evi-dence indicates that SE was performed less then satisfactorily in the business sense, as follows. Some of the budget and schedule issues and compromised functionality of NASA and Department of Defense (DoD) missions have reached critical levels, as described in several governmental studies of recent programs [GAO, 2007, 2008a, 2008b]. These references blame, among others, both insufficient level of SE effort in the programs, and “sufficient” but poorly executed SE proc-ess, as summarized in Box 4, and illustrated in Figures 3–6. J. Young [2009], in his report to the Defense Secretary, pub-lished a critique of the active and recently terminated defense programs. Among the major factors causing the program cost growth and schedule delays Young listed excessive and unsta-ble requirements and runaway requirements changes, discon-tinuous funding, notorious “low-balling” of the budget, schedule and risk driven by the desire to get the programs running, immature and exquisite technology, management and execution issues, and “the DoD eyes [being] bigger than its stomach.” The author did not parse the blame between the acquisition system and SE. Several recent rather spectacular failures raised controversies about SE, as follows. The colli-sion of Russian and American satellites [Broad, 2009], which sent uncountable small objects into random trajectories that now jeopardize other space missions, raised the question whether the collision should be blamed on the lack of suffi-cient international cooperation in space or on inadequate SE for the monitoring of space objects in the US alone? A
terminally aged military satellite was destroyed by a missile, arguably in order to avoid the risk of earth contamination [Ferster, 2008], raising the question as to why the satellite disposal problem was not included in the life-cycle SE of the program. The tragic end of the Columbia space shuttle was diagnosed by the investigation board as (paraphrased) the foam did it, but NASA culture allowed it [NASA, 2003]; and the misuse of O-rings in cold weather leading to the Chal-lenger disaster [House of Representatives, 1986] provoke the question as to what degree the organizational culture and effective SE are/should be interrelated. The Coast Guard received 27 boats deemed unusable for service [O’Rourke, 2008], and the matter is now litigated trying to allocate the fault among several disjointed parties (mis)conducting the SE. The list of failed programs is longer and these are only examples. A comprehensive program-by-program study of the effectiveness of SE and of the reasons for both successes and failures remains wanting at this time, and the confounding of SE and the government acquisition system is blurring the picture. In addition, the leaders of the present project shared the perception that the established SE practice, even when technically successful, is often burdened with waste.
In view of these considerations, the team developing the enablers took the following positions:
1. The established SE process9 (defined, e.g., in INCOSE [2007]) is regarded as sound if used and funded prop-erly, but is often burdened with waste; therefore, it should benefit from Lean Thinking. In other words, the team decided to try improving a practice which has a lot of strengths, but is not as good as it can be. Since the work was performed under INCOSE organization, the team used the INCOSE SE Handbook [INCOSE, 2007] as the baseline.
2. The sizeable waste (as indicated in Fig. 1 and defined in Box 2) should be regarded as a vast productivity reserve in programs, to be exploited using Lean Think-ing.
Box 3. Charter of the INCOSE Lean Systems Engineering Working Group
8Even among these successful programs, the demarcation between effective
and ineffective SE is hazy: Some of the satellites launched during the post-FBC/AR period were designed during the FBC/AR period—indicating that the FBC/AR was not all bad; and some of the recent launches designed in the post-FBC/AR period experienced problems—indicating the FBC/AR was not the sole contributor to the failed systems.
9The standard SE process is described in a number of manuals: INCOSE SE
Engineering Handbook, the ISO 15288 standard, NASA and Department of Defense SE Manuals, Defense Acquisition University manuals, and numer-ous manuals created by individual defense and civilian companies. None contains Lean Thinking explicitly, but they do include use of Integrated Product Teams whose origins can be traced to the quality movement. Argu-ably, the manuals describe essentially the same body of knowledge and the same SE process with varying degrees of detail, emphasis, and user friendli-ness. For this reason, and since the present project has been carried under the auspices of INCOSE, the present text only makes references to the INCOSE Handbook v.3.1, 2007.
3. Both SE and Lean represent challenging areas for re-search as they are grounded in industrial and govern-ment practice rather than laboratory, or theory, or mathematics. In addition, many large programs that use SE are proprietary, classified, with discontinuities in execution, so it is extremely difficult to gather explicit data and test hypotheses from such programs. SE case studies are not available in the public domain with sufficient detail to enable development of Lean prac-tices. Where data are available, it is often of inadequate resolution or quality. Therefore, the team concluded that project development had to be based on collective
Figure 4. Schedule overruns for five space programs [GAO, 2008b].
Figure 3. Initial and most recent estimates of the total program costs [GAO, 2008b].
wisdom and experience of the LSE WG members. Webb [2008] named such development “based on tacit knowledge.” In order to reduce subjectivity, the project results were endorsed by surveys, and compared with recent GAO and NASA recommendations.
4. There are benefits to an early exposure of Lean Enablers for Systems Engineering. The list and associated defi-nitions can provide value to the SE community, and introduce Lean Thinking in systems engineering appli-cation and context.
The development of LEfSE followed the established de-sign phases including Conceptual, Alpha, Beta, Prototype, and Version 1.0. A formal online process has been set up for future improvements. These phases are summarized in Box 5 and briefly described next.
2.2. Conceptual Design of LEfSE
Consistent with the tacit knowledge approach, eight invited participants from industry, government, and academia10 met
to develop a conceptual framework for LEfSE. Based on their lifetime experiences, they were asked to identify the practices which deliver best value with minimum waste, the “do’s and don’t’s” of SE and the relevant aspects of EM, applying Lean Thinking to the individual steps of the SE System Life Cycle Process Overview11 [INCOSE, 2007], and aiming for the
asymptote of SE excellence. Constraints such as the present acquisition system regulations and various company policies were to be ignored. In addition, the new enablers should not repeat information already covered in the INCOSE Hand-book, which was regarded as sound but lacking Lean Think-ing.The meeting demonstrated the power of creative team synergy, yielding 16 pages of captured notes.
To the authors’ knowledge, two examples of Lean frame-works existed at the time: (1) The Toyota PD framework of 13 enabling Lean practices organized into People, Process, and Technology categories, each developed into several points [Morgan and Liker, 2006]; and (2) the LAI Lean Enterprise Model [LEM, 1996], 1 page long, organized into 12 overarching enabling practices. Guided by the lengths of these examples, the team initially expected that the final product might be in the form of a list of enablers short enough for graphical presentation as callout boxes in the INCOSE SE Handbook processes: Capture of Customer Needs; Program-matic Success; Requirements; Design Solutions; Effective Process Execution; Implementation; Integration; and Verifi-cation and Validation.
2.3. Alpha Version of LEfSE
The editing of the candidate enablers involved tradeoffs be-tween importance, completeness, brevity, and clarity. Mindful of the fact that SE is not and should not be a functional island but is like a nervous system interacting with the entire body, the team added enablers dealing with critical interfaces be-tween SE and other enterprise management areas: PM, sup-pliers, and developmental engineering. The enablers were added from the following sources: Stanke [2001], LEM [1996], Leopold [2004], Oppenheim [2004], Rebentisch [2005], Morgan and Liker [2006], Rockwell Collins [2007], Figure 5. Examples of reduced buying power and military capability
[GAO, 2007].
Figure 6. Weapon system quality problems and impact [GAO, 2008a].
10See the Acknowledgments for the names of the team members. 11The process chart therein is credited to ISO 15288.
Gittell [2003], and others from the rich menu of the LAI and University of Michigan research products, and individual members’ experiences. The resultant list was judged too long for graphical presentation as callout text boxes in the Hand-book. Also, different SE process steps turned out to require identical enablers; thus this approach would be repetitious. Instead, in the next draft, the team decided to try to edit the enablers as a supplement to the INCOSE Handbook, to be proposed to INCOSE management. The enablers were organ-ized into eight following thematic groupings, strongly influ-enced by Lean Thinking in LPD: (1) Frequently Involve the Customer; (2) Build a Lean Organization; (3) Develop Perfect Coordination Mantra across People and Processes; (4) Pro-mote Smooth SE Value Stream Flow; (5) Front Load Archi-tectural Design and Implementation; (6) Pursue Excellence and Continuous Improvement; (7) Invest in Workforce Devel-opment; (8) Use Lean Tools.
2.4. Beta Version of LEfSE
Numerous iterations yielded 160 enablers, named Beta, which was presented to the LSE WG on January 28, 2008. A survey was designed asking to rank each enabler Importance to the mission/product success “in your recent programs,” and to rank the Use of the enabler “in your company,” using the
scales of 0–5, with 0 meaning “useless” or “not at all,” and 5 meaning “critically important” or “implemented and used routinely,” respectively. The Beta survey also asked for com-ments.
Ten individuals from the WG who are regarded as experts in both SE and Lean responded to the survey with generous comments. In addition, a Major American Aerospace Corpo-ration (MAAC) kindly offered to participate in the survey, providing 19 responses. MAAC allowed employees to fill out the survey on company time, but requested to eliminate 30% of the enablers from the survey in order to reduce the comple-tion time. The MAAC populacomple-tion included mostly SEs rang-ing in seniority from recent hires to 30 years of experience in program management. A few weeks prior to this survey, most of the respondents completed a comprehensive course on Lean.
Graphs of both separate and combined results of the 10 INCOSE and 19 MAAC responses are available for all en-ablers [Plotkin, 2008]. Figure 7 shows a typical graph indicat-ing good agreement between the INCOSE and MAAC results, which is encouraging as the two populations had no common members. Figure 8a presents a summary of the Importance and Use rankings, with the bar heights representing the num-ber of enablers. The average value of the Importance ranking for all enablers was 3.76 and of the Use 2.92. The high
rankings of the Importance for most enablers indicated that the project is useful, and the lower rankings of Use indicated that the project is needed. The qualifiers “in your recent program” and “in your company” used in the survey instruc-tions caused some confusion because many employees were involved in only short fragments of long programs, and sev-eral programs extended over sevsev-eral companies. The instruc-tions were clarified in the Prototype survey as explained below. The majority of the LSE WG members endorsed most of the Beta enablers, but did not like the eight above headings. Instead the classical Lean Principles were suggested as better headings. Ten individuals12 volunteered to carry on the
sub-sequent development leading to the Prototype version. 2.5. Prototype Version of LEfSE
The rankings and comments received from the 29 responses to the Beta survey were used to develop the Prototype version. The enablers with low average Importance rank were deleted. The remaining enablers were regrouped under the six Lean Principles. Four rounds of drafts and negotiations by the team followed. Given the “tacit-knowledge” approach to the devel-opment, the search for consensus during the drafts and nego-tiations was critical for success.13 The work was guided by
the spirit of Lean Thinking: to improve the practice of SE and
EM by promoting flawless mission/product assurance while reducing waste.
The final Prototype included 194 enablers. It was pre-sented to the LSE WG at the INCOSE Symposium in Utrecht, May 16–19, 2008. Several WG members decided to begin Figure 7. Rankings of importance and use of sample enablers (Beta version). (The numbers in parenthesis denote the number of Importance responses from INCOSE and MAAC, and Use from INCOSE and MAAC, respectively.)
Figure 8a. Survey rankings of enabler importance and use (Beta).
Figure 8b. Survey rankings of enabler importance and use (Proto-type).
12See the Acknowledgements for the names of the team members. 13Most of the negative comments resulted from a perceived conflict between
the given enabler and the current industrial practice or government acquisi-tion regulaacquisi-tion. Where the enabler appeared to suggest a better way, it usually prevailed, even if the immediate industrial or governmental implementation appeared difficult. The comments included rewording, different emphasis, deletions, different groupings of enablers, elimination of redundant points, movement to a different position on the list, and cosmetic changes. Some words were changed to accommodate language differences between the U.S. and U.K.
implementing the Prototype enablers in their companies with-out waiting for the final version.
2.6. Endorsement of the Prototype by Survey The LEfSE are intended for industrial practitioners. Ideally, they should be validated by comparing the performance (for example, the value delivered, stakeholder satisfaction, and program cost and schedule) between traditional programs and those following the LEfSE. This, of course, is not practical, because many recent governmental programs take years, some being as long as 20 years or more, because no two programs are repeatable, and also because implementing all LEfSE would be a challenge to most programs. Instead, a quick reaction from the SE practitioners was needed. There-fore, the Prototype team decided to repeat the Beta survey approach asking SE community at large to rank the enablers. A new survey was designed listing all Prototype enablers and asking again for the rankings of Importance and Use of each enabler. However, new instructions and scale were used, in order to clarify the Beta issues, as follows:
• Rank the Importance of the given Enabler to the effec-tiveness of SE based on your professional experience, not necessarily limited to current programs or com-pany.14
• Rank the current Use of the listed practice in the indus-try, again based on your entire experience.
• Use the scale: 2 = strongly agree [with the given enabler Importance or Use], 1 = agree, 0 = neutral, –1 = dis-agree, –2 = strongly disagree.
The Prototype survey was distributed to about 100–150 practitioners of Systems Engineering at large in several west-ern countries; 26 surveys were completed,15 many with
com-ments (i.e., the response rate was about 17–26%). Figure 8b summarizes the Prototype survey results. The Importance in Figure 8b was ranked high, with most enablers ranked at the average of 2, some at 1, and none at 0 or below. In contrast, the Use ranking was the largest at 0, significant at 1, and small fractions at –1 and –2. It was gratifying that the respondents at large ranked the LEfSE Prototype as both important and needed for SE effectiveness. Comparing Beta to the Prototype indicates that the Importance rankings have shifted up in value by about 1 unit (even though their ranking scales were not identical). This confirms that the Prototype enablers are better formulated than the Beta version. Boxes 6–11 in Section 3 list the average Use value for each Prototype enabler.
The low response rate (only 26 completed surveys) is a weakness of the project. For this reason, this paper makes an
appeal to the community to contribute effort to future valida-tion of LEfSE, as described in the following secvalida-tion. 2.7. Version 1.0 of LEfSE and Future Changes The original plan called for keeping the Prototype enablers ranked on the Importance scale at 2 or 1 (with the cutoff value 0.5), and deleting or editing those with rankings of (–2), (–1), or 0. As shown in Figure 8b, all 194 enablers passed the trigger value. The LSE WG Co-Chairs decided that, after cosmetic changes, the Prototype can be released online as Version 1.0 (V.1.0), with the release date of the January 2009 INCOSE meeting in San Francisco.
While V.1.0 represents the end of the intended develop-ment cycle, it cannot be regarded as “final.” Progress in the knowledge of SE and PM, experience learned from the use of LEfSE in actual programs, and future changes in acquisition policies by different governments will require continuous improvements. The following process has been implemented for making future changes.
At any time any INCOSE member can propose a new enabler or an edit or deletion of an existing enabler using a special online form. It is recommended that the submitters be not only SE professionals but also have a good understanding of Lean Thinking. Once the form is activated, other WG members can use it to enter arguments for and against the change proposal. Biannually, an e-mail reminder will be sent to the entire LSE WG asking members to vote electronically on the active change proposals. The majority vote will accept the proposal for the next release of the LEfSE.
At the time of this writing, the LSE WG is planning a broad dissemination of V.1.0 in industry, academia, and local IN-COSE chapters,16 including a release of LEfSE by INCOSE
to the entire membership.17
3. LEAN ENABLERS FOR SYSTEMS ENGINEERING
The LEfSE are organized into the six Lean Principles and listed in Boxes 6–11, one box per Principle. In order to emphasize that the LSE WG regards the SE process [IN-COSE, 2007] as sound, only lacking Lean Thinking, each Principle begins with the following enabler: “Follow all [ap-plicable to the Principle] practices in the INCOSE SE Hand-book. In addition…”; and this is followed by the enablers developed in this project. Most emphatically, all established SE process activities, including decision making, testing, verification, and validation, are fully embraced, as implied in a number of enablers below, consistent with the words from the definition of LSE Value: “... the delivery of a flawless complex system, with flawless technical performance, sat-isfying all stakeholders....”
16A presentation used for workshops has been posted online [INCOSE LSE
WG, 2008] in the pdf format.
17By the time of this writing, workshops have been delivered at 14 venues,
including INCOSE Chapters in Los Angeles (multiple presentations), Seattle, and Israel, AFIS and EADS in France, and seven university and corporate venues. AFIS and Israel decided to organize their own subgroups devoted to future work on LEfSE.
14The words not necessarilylimited to current programs or company were
added to overcome the need to have the survey approved by strict export controls required in some aerospace companies.
15The fact that only 26 surveys were completed was a disappointment. The
primary reason given for refusing to complete the survey was lack of time. Indeed, on average it took 2–3 hours to rank the 194 enablers on two axes, and enter comments. The vast majority of programs require that employees charge their entire work time to specific projects, leaving no time for filling out external surveys. This is a major obstacle in conducting extended surveys.
The majority of the enablers are self-explanatory. A few enablers are explained with comments.
Selected enablers list a few prominent examples of the programs or companies that have applied the given practice. The list of examples is based on the knowledge of the authors and surely is not complete or exclusive. There must be many more programs and companies practicing some enablers. The programs or companies are identified only by name (e.g., Iridium), and these names are listed in the References in {braces} at the end of the listing.
The last column of Boxes 6–11 lists the average Use ranking from the Prototype survey. [The Importance rankings are not listed since all enablers in V.1.0 were ranked, on the average, as (paraphrasing) important or very important.] Se-lected striking observations from the Use values are discussed below.
The Lean Fundamentals reviewed in Box 1 represent a general formulation of the Principles. In this section, addi-tional specific interpretation is provided in the context of LEfSE.
3.1. Value
The initial phase of every program should be devoted to the task of comprehensive unambiguous and detailed under-standing of value to the customer, i.e., of all customer needs, requirements, and interpretations of value. Experience indi-cates that many programs rush through this phase without a robust process, ending in incomplete or incorrect require-ments that burden the subsequent program execution with waste. The enablers listed under the “Value” Principle (Box 6) cover the practices required for developing a robust and effective process of capturing the complete customer value proposition, disseminating it among the program team, align-ing the team, involvalign-ing the customer and other stakeholders in the process, and doing it with sufficient breadth and depth
to avoid later waste. Enabler 1.2.1 lists the definition of value-adding activities, which is fundamental to Lean Think-ing.
Note two striking observations from the Use column: (1) The Lean culture of “right the first time” is not widespread (Use = 0.09), enabler 1.2.1.c; and (2) the understanding of customer culture among program employees is poor (Use = –0.52), enabler 1.2.6.
3.2. Map the Value Stream (Plan the Program) The “Value Stream” Principle promotes excellent planning of the value delivery process, after value has been defined in Principle 1. Poor planning is a notorious reason for wasteful programs. Therefore, Principle 2 contains a comprehensive checklist of the practices for planning of all end-to-end linked streamlined actions and processes necessary to realize value without waste, including the planning for comprehensive decision making. The Principle integrates the planning of SE, PM, and other relevant enterprise activities to avoid the fre-quent waste that occurs at the interface of the disciplines and organizations. It emphasizes the benefits of old-fashioned but powerful colocation of personnel, and the need to use the most experienced individuals during the critical planning and con-ceptual phases, and who should look at a broad range of possible solutions. It promotes precise preparations for sub-sequent program execution: planning of the coordination and communication means between stakeholders throughout the program, preventing subsequent conflicts, especially with suppliers (critically important as modern programs have 60– 90% of value delivered by suppliers), planning effective met-rics to be used during the program management, and tailoring and planning of task precedence and content for smooth flow. It strongly promotes program frontloading. Box 7 lists the enablers.
18SE is a part of PD. In this paragraph, the PD should be understood as denoting all PD activities other than SE, including design, development, manufacturing,
integration, testing, etc.).
19Queuing theory proves that the flow approaching 100% of capacity always slows down asymptotically due to the accumulation of variability, even in the
absence of any bottlenecks.
20“Any fool can make anything complex but it takes a genius and courage to create a simple solution”—Albert Einstein.
Box 8. Lean Enablers for Lean Principle 3: Flow (continued) Box 7. Continued
Note two striking observations from the Use column: (1) Programs do not scrutinize every step to ensure it adds value, and include steps because “it has always been done” (Use = –0.54), enabler 2.2.6; and (2) programs tend to reinvent the wheel rather than reuse proven solutions (Use = –0.13), enabler 2.4.
3.3. Flow
The “Flow” Principle enables the value creation process to flow smoothly and continuously without the waste of stop-ping and waiting, rework, or backflow. In complex programs, opportunities for the progress to stop are overwhelming, and it takes careful preparation, planning, and coordination effort to overcome them. The Flow Principle contains a comprehen-sive checklist of the practices intended to help the flow. They include frequent clarification of requirements, frequent op-portunities for decision making, frontloading the design and implementation, making progress visible to all, using the most effective communications and coordination practices, and effective tools. Most importantly, the Principle elevates the SE responsibility, authority, and accountability for coordina-tion of all technical activities and for the overall technical program success. Box 8 lists the enablers.
It is a sad commentary on the traditional programs that so many common sense enablers have earned the low Use value.
3.4. Pull
The “Pull” Principle is a powerful guard against the waste of unneeded tasks, overprocessed tasks, task rework (not to be confused with legitimately needed and optimized iteration loops), and the tasks that are not needed but are left over from previous programs or company habits. Pull promotes the culture of tailoring tasks and their outputs to meet the legiti-mate needs of the internal or external customer, and rejecting other tasks or outputs as waste. “Legitimate” is always inter-preted in the context of value: “flawless mission assurance and satisfaction of stakeholders.” This does not mean cutting legitimate SE; it means cutting those tasks which contribute to the waste and do not add value. Pull promotes proactive coordination of task scope and modalities between the output creator and the user prior to the task execution, for all trans-actions, to eliminate the waste of misunderstanding, defects, rework, and waiting. Box 9 lists the enablers. Again, the Use values indicate a poor implementation of these common-sense practices.
3.5. Perfection
The “Perfection” Principle strives for excellence and continu-ous improvement (CI) of the SE process and related enterprise management.21 The enablers assist in guarding against
waste-Box 8. Continued
21To reiterate a comment in Box 1, “perfection” refers to continual process
improvement, not continual product or system improvement which can lead to “gold plating.”
ful processes and outcomes, in making all imperfections visible to all—which is motivating to the immediate improve-ment, and in comprehensive capture and use of lessons learned from past programs. The enablers support best means of communication, coordination, and collaboration to enable the CI. The Principle elevates the role of Chief SE to lead and integrate the program from start to finish (the comment listed under enabler 5.5 addresses the controversy about the roles of PM and Chief SE in modern programs). Following an estab-lished Toyota practice, the Principle recommends driving out waste through design standardization, process stand-ardization, and skill-set standardization. It calls for employing
all three complementary CI methods (bottom-up suggestions by employees, quick reaction Kaizen teams for smaller local problems, and Six Sigma for larger challenges)—important in the recent environment where the first two tend to be ignored.Box 10 lists the enablers.
Arguably, the most telling may be enabler 5.2.2, “Promote excellence under ‘normal’ circumstances instead of hero-be-havior in ‘crisis’ situations,’” which earned only the (–0.40) Use ranking. This confirms the anecdotal perception that traditional programs are perpetually in the crisis management mode.
Box 9. Lean Enablers for Lean Principle 4: Pull
3.6. Respect for People
The “People” Principle promotes the best human relations at work based on respect for people: trust, honesty, respect, empowerment, teamwork, stability, motivation, drive for ex-cellence, and healthy hiring and promotion policies. It calls
for a vision which draws and inspires the best people and promotes such excellent human relations. It promotes a learn-ing environment. Finally, it calls for treatlearn-ing people as the most valued assets, not as commodities. Box 11 lists the enablers.
22A frequent practice in recent U.S. governmental programs is to have two program managers: the “Program Manager,” responsible for the program business
success, and “Chief Systems Engineer,” responsible for Systems Engineering. Numerous functional engineers are responsible for various technical areas. In some programs this causes split responsibilities, authorities, and accountabilities, often with imperfect results. In contrast, many U.S. and overseas commercial programs use only one person fully responsible for the entire program success (both technical and business). The person is called by various names, e.g., Chief Engineer (very successful Toyota model [Morgan and Liker, 2006], Product Manager, Product Engineer, or similar. Early U.S. aerospace programs also used extremely successful single-person “Chief Engineer” role (e.g., early Jack Northrop, Howard Hughes, Kelly Johnson of the Skunk Works, early NASA space programs, and others). Murman [2008] discusses some more recent successful programs with a single top manager in the dual technical and business leadership role. Since this document is intended for INCOSE, a Council for Systems Engineering rather than entire program management, the editors have addressed only the technical role of the Chief Engineer, saying nothing whether that person should also be the overall manager of the program, or share the management with a separate business manager person. However, nothing in this document should be taken as promoting the dual-head model. The dual-head model is not required under the U.S. government acquisition policies, and is not promoted in the INCOSE SE Handbook [INCOSE, 2007].
3.7. Benchmarking LEfSE with NASA and GAO Recommendations
The V.1.0 of LEfSE was compared to the recommendations made in the recent studies by GAO and NASA of U.S. government programs, discussed in Box 4. NASA [2007] benchmarked the practices of major aerospace companies in an attempt to capture the key enabling factors and best prac-tices that lead to successful programs. NASA chose industry leaders with “proven outstanding achievements in producing complex systems.23” Box 12 compares NASA’s “key
en-ablers” with LEfSE, and Box 13 compares NASA “best
practices” with LEfSE. It was gratifying to find that both NASA’s “key enablers” and “best practices” are consistent with the LEfSE, but the LEfSE are much more comprehen-sive. Each NASA enabler and practice found several detailed LEfSE enablers. This convergence of thinking provides fur-ther endorsement of LEfSE. Similarly, the GAO [2008b] offered a summary of best practices from recent commercial space programs. Box 14 compares the GAO recommenda-tions to the corresponding LEfSE. Again, the two are aligned, but LEfSE are more comprehensive.
4. SUMMARY AND CONCLUSIONS
Lean Enablers for Systems Engineering (LEfSE) have been presented, together with a historical note about the origin of this project, including a brief history of the emerging field of
Box 11. Lean Enablers for Lean Principle 6: People
23Raytheon Missile Systems, Army Aviation & Missile Research and
Devel-opment & Engineering Center (R&M and Software Engineering Director-ates), Boeing Commercial Aircraft Division, Boeing Satellite Development Center, and Lockheed Missile & Fire Control Systems.
Box 13. Best Practices of Top Performing Aerospace Companies [NASA, 2007]
Box 14. GAO Study of Commercial Best Practices during Program Development, [GAO, 2008b] Box 12. Key Enablers for Successful Programs in Aerospace [NASA, 2007]
![Figure 2 illustrates the most frequently observed waste in 27 aerospace PD programs [Slack, 1998]](https://thumb-us.123doks.com/thumbv2/123dok_us/8680127.2347502/7.918.84.439.86.349/figure-illustrates-frequently-observed-waste-aerospace-programs-slack.webp)
![Figure 4. Schedule overruns for five space programs [GAO, 2008b].](https://thumb-us.123doks.com/thumbv2/123dok_us/8680127.2347502/10.918.486.840.645.1049/figure-schedule-overruns-space-programs-gao-b.webp)
![Figure 6. Weapon system quality problems and impact [GAO, 2008a].](https://thumb-us.123doks.com/thumbv2/123dok_us/8680127.2347502/11.918.82.447.94.358/figure-weapon-quality-problems-impact-gao-a.webp)
