Category Archives: Lean Engineering

Study Supports Value of Lean Engineering

The Boston Consulting Group and the Laboratory for Machine Tools and Production Engineering RWTH Aachen University recently published The Lean Advantage in Engineering study of Lean Engineering methods and cost/cycle time/quality benefits achieved by adopters.  The study confirmed the value of fail-fast and short iterative cycles in lean engineering in reducing the product target costs.

The BCG have compiled a best practices model of lean engineering that entails 16 practices in four dimensions organized for effectiveness (doing the right things) and efficiency (doing things right):

  1. Product – For effectiveness use strategic positioning, holistic and detailed roadmap, and transparent product requirements. For efficiency use a modularized product design and optimized product range.
  2. Processes – For effectiveness use solutions-oriented design sets and an agile/fast cycle process. For efficiency use flexible workload leveling and sequencing to reduce bottlenecks.
  3. Leadership & Behaviour – For effectiveness use proactive uncertainty management and fact-based/fast-cycle steering. For efficiency use cross-functional collaboration and empowered project management.
  4. Enablement and Tools – For effectiveness use experience and expertise driven development. For efficiency use speed-supporting tools and single source truth.

Lean Champions – What Does Good Look Like

19% of the study participants were judged to be Lean Engineering Champions based on the following distinguishing characteristics:

  • Routinely apply lean engineering methods in most projects.
  • Established lean engineering as the new standard in engineering.
  • Succeed in decreasing development time significantly (as much as 25% faster and up to 6 months faster).
  • On average complete 71% projects within scheduled time,
  • On average complete 74% projects within budget.
  • Two thirds have full transparency into capacity utilization and specify flexible mitigation actions to avoid project disruptions in the medium to long-term.
  • 70% employ a cross-functional knowledge management system to maximize reuse in some cases on a global scale.
  • Leaders in modularization were better at shortening the duration of a development process by 15-20%.
  • Leaders use modularization with standardized interfaces across the full range of product lines and families and differentiate modular product design on the basis of customer requirements.
  • Practitioners of agile development complete 59% projects on time with 35% lower deviation from product target costs where product cost decreased as the number of gate reviews (ie. iterations) increased.

Other Interesting Conclusions

  • Most participants at least considered implementing lean engineering;
  • Participant performance was above the mean in strategic positioning, transparent product requirements, cross-functional collaboration, speed-supporting tools, and single source of truth.
  • Participant performance were below the mean in modularization, optimized product range, solution-oriented design sets, agile/fast-cycle process, sequencing to reduce bottlenecks, fact-based/fast-cycle steering, and experience/expertise-driven development.
  • High levels of maturity in diligently translating customer requirements into a full set of product specifications and early involvement of other functions in the development teams.
  • Low use of product modularization with limited reutilization of existing modules.
  • Engineering processes were typically broken up into five or fewer long phases lasting 6 months or more with feedback provided at intermediate stages as opposed to more frequent feedback iterations.
  • Engineering KPIs were usually available but were not clear or meaningful enough for steering.
  • Design reviews occurred too late to allow for effective steering.
  • Most companies do not have a design library like cross-functional knowledge management system.
  • Know-how is managed locally and lessons learned shared almost exclusively within a function.

What Is The Key Take-Away

Firms that compete in engineered product markets need to take a closer look at how they stack up against emerging lean engineering champions who are achieving  significant competitive advantages in terms of cost, speed, and quality then put in place a medium to long-term improvement program. Alopex Management Consulting can assist firms achieve this very critical strategic objective.

Engineering Productivity

Engineering leaders interested in improving their profitability need to understand how the Theory of Constraints can improve engineering productivity and perhaps most importantly under what business conditions. This post reviews the evolution of throughput methodologies from where they were first applied in the manufacturing environment to newer approaches evolving for engineering, new product development, and R&D where the business goals are improved profitability and new value creation for growth and competitiveness.

Theory of Constraints

Eli Goldratt’s book The Goal (1984) helped a generation of manufacturers understand the operational principles underlying the Toyota Production System and Lean Manufacturing.  Goldratt defined the goal as improved profits and clarified the operational rules for running a plant to be in order of priority throughput, inventory, and operational expense as opposed to pure cost cutting that lead to localized optimums and poor profitability results. He explained how the Theory of Constraints (TOCs) when applied through these operational rules can improve the profitability of a manufacturing operation with stable input demand. The TOC was first applied to manufacturing operations that can be characterized as a repeatable network of dependent events with processes that are subject to statistical fluctuations.  The TOC focusses on system constraints to improve throughput, inventory, and operational expenses in the total production system.  The key conditions that enable the TOC to achieve results in manufacturing are stable demand, moderate to high volumerepeatable processes, and a small range of products.

Unstable Production Environments

Eli Goldratt’s paper Standing on the Shoulders of Giants (published with The Goal) went on to clarify how certain production environments and conditions can become unstable leading to marginal improvement gains from applying TOC.   In this paper Goldratt described the Hitachi Tool Engineering case where the firm had limited success with lean manufacturing because of their unstable production environment conditions.

The three general conditions Goldratt identified that lead to unstable production environments are:

  1. Unstable Demand Per Product
  2. Unstable Overall Load On The Entire Production System
  3. Short Product Life

The first two unstable production environments fall within the means of a manufacturing company to manage because the production system can still be characterized as a network of dependent events with processes that are subject to statistical fluctuations.  Full productivity gains are not achieved because of how the production system throughput reacts to the unstable input demand due to dynamic mix of products, too many different products, or how dynamically the input demand of different types of products results in unstable overall load on the system. Goldratt explains how a time-based application of supply chain approach of TOC in a method called Drum-Buffer-Rope system can achieve improved performance for the first two conditions. Goldratt observed that low touch time production environments (Touch Time <<< Lead Time) provide enough margin to still exploit TOC benefits.

The third unstable production environment, short product life, emerged in the 1980s from the increased pace of technological change on manufacturing operations. The turn time (lead time) performance of engineering, product development, and R&D became a factor for product companies bringing attention to knowledge worker productivity.  Goldratt observed that product development systems do not exhibit processes that are ‘network of dependent events with processes that are subject to statistical fluctuations’. Each new product develop effort tend to have a unique network of dependent events with high variability which is consistent with a a project environment. Goldratt also observed that the project environments also exhibits time compression where touch time approaches lead time (lead time ~ 2 to 3 times touch time) of the project which degrades project environment throughput.

Unstable Project Environments

To solve the unstable project environment problem Eli Goldratt went on to develop the Critical Chain method in the 1990s.  The Critical Chain method adapts the TOC to unstable project environments with a particular emphasis on engineering development projects. In much the same format as The Goal his book Critical Chain (1997) explains how the Critical Chain method achieves improved project performance over Critical Path methods. The goal of Critical Chain method is to improve the flow (throughput) in project environments for stable and unstable project demand.  The mental jump from manufacturing production environments to project environments is helped when one considers that most project environments are multi-project environments.  Throughput in a project environment is understood to be the flow of projects (and their activities) of various degree of: sizes, durations, complexity, uncertainty and novelty.

The Critical Chain method seeks to maximize project environment throughput by managing feeding buffers and capacity buffers within the project and drum buffers and capacity buffers between projects.  The Critical Chain methods use of buffers (time & resource) to improve productivity by reducing Work In Process (Design in Process), manage bottleneck resources, not allowing multi-tasking of resources, staggering projects along the constraints, prioritizing projects, and resolve resource conflicts on the system level.

An interesting aspect of Goldratt’s Critical Chain method was how to consider behavioural issues in multi-project engineering environments. The Critical Chain method addresses:

  1. Tendency for engineers to ‘pad their estimates’ to give local safety margins that degrade the efficiency of the project environment by use lumped buffers (rather than activity-by-activity risk buffers) and focussing less on individual activity time performance.
  2. Overcome the tendency to think locally (within the project or a work area) by encouraging global thinking by avoiding multitasking.
  3. Manage ‘student syndrome’, the tendency for humans with time buffers to start their tasks later and waste safety margins.
  4. Manage ‘Parkinson’s law’, the tendency not to finish tasks ahead of time even they have a chance to by removing activity padding.
  5. Minimize the individual project owners pressure to execute first (local optimization at the expense of the global performance) by adopting a priority system.

An excellent review of the Critical Chain method can be found in a 2005 paper by Lechler, Ronan, and Stohr with some useful simplifications that make the method more practical.

Product Development Flow

Donald Reinertsen developed a parallel set of work to Goldratt that explored and clarified much of the underlying principles of lean product development from the perspective of achieving faster time-to-market in the project production environment. Reinertsen’s books Developing Products in Half The Time (1991) co-authored with Preston Smith, Managing the Design Factory (1997), and The Principles of Product Development Flow (2009) explored an economic model for design, queues in product development work, management systems, managing risk, lean engineering principles, and performance metrics more appropriate for the paradigm shift from the traditional utilization based management paradigm to a throughput management paradigm for engineering, product development, and R&D.

Reinertsen also defines Design in Process (DIP) in the project production environment since inventory is measured in terms of information in the knowledge work space. The abstract nature of information inventory and visualizing how it flows through a knowledge based work environment has probably been the single largest factor holding back the broader adoption of lean product development.

Reinertsen clarifies how the project production environment differs from the manufacturing production environment with repeatable network of dependent events with processes that are subject to statistical fluctuations to one with high variability (uncertainty, learning, experimentation), non-repetitive (every project network is different, sometimes completely), and non-homogeneous task durations (most tasks slightly different each time). Reinertsen’s most recent book Principles of Product Development Flow in particular explores the themes of cadence, synchronization, flow control, WIP constraints, batch size, exploiting variability, queue size, fast feedback, and decentralized control to maximized throughput.  Although these works provide a vast array of tools it is difficult to see the big picture framework suitable for practical implementation.

Lean Product Development

Ronald Mascitelli, Timothy Schipper and Mark Swets went onto develop fully integrated lean product development frameworks that operationalized the principles for engineering leaders who are responsible for new product development.  Most importantly they describe how to fully implement a multi-project production environment based on the all the preceding methods but appropriate for actual business environment.

Ronald Mascitelli’s Mastering Lean Product Development (2011) is perhaps the best integrated framework for the engineering, product development, and R&D leader to establish a throughput managed multi-project production environment. Mascitelli’s framework is an event-driven process incorporating practical lean methods to achieve the goals of improved profitability and new value creation for growth and competitiveness.

Timothy Schipper and Mark Swets published Innovative Lean Development (2010) to describe an equally powerful integrated framework that leverages fast learning cycles and rapid prototyping for project production environments with high uncertainty.

Agile Scrum

In the digital information age as products have become software driven and in many cases entirely software based the agile scrum methodologies have operationalized software product development emerging in early 2000s. The abstract nature of software development defied reliable engineering management methodologies before the emergence of agile scrum. With agile scrum software productivity is more manageable, efficient, and effective. Software driven products require the integration of the agile scrum methodologies within the project production environment framework just described.

The Lean Start-Up

Up to this point in the post we have looked at how established companies with existing demand can exploit the TOC for improving throughput, inventory, and operational expenses to improve profitability in knowledge work. Finally Eric Ries operationalized new-to-the world lean product development (particularly digital offerings) for start-up founders in his book The Lean Start-Up (2011). This is the extreme unstable demand case.  Ries describes how to measure productivity as validated learning for fast iteration and customer insight to find the scalable business model before cash runs out.  Application of lean principles such as small batch size in the form of minimum viable product, build-measure-learn loop for fast feedback, metrics, and adaptability to find product/market fit. Ries observes that The Lean Start-Up is also applicable within existing companies for use by intrapreneurs who may be creating new value with new-to-the-world products because this is also the extreme unstable demand case.

Productivity Methodology Selection Based On Business Environment

Selecting the right methodology to drive business productivity requires leaders to understand their business environment and the stability of their demand environment. The diagram below helps to characterize application & business environments.

Engineering Productivity TOC

The diagram illustrates that in both manufacturing and engineering that the nature of the work can fall into a range of demand conditions.

A key lesson from this review is that leaders should seek to throttle/smoothen (WIP Constrain) the input demand conditions if productivity improvements results are to be achieved.  All the available methodologies are based on the concept of flow and maximizing throughput and managing inventory (physical or information), and operational expense to achieve business the goals of improved profitability and new value creation for growth and competitiveness. As Goldratt emphasized time and again effectiveness of these methods depend the key underlying condition of stable input demand or constraining the process input demand to ensure stable flow. As demand conditions become unstable lean engineering methods have been developed by Goldratt, Reinertsen, Mascitelli, Schipper, and Swets. Ries has described how new cash flow streams can be created in a lean fashion in the extreme case where demand does not yet exist.

Finally a common theme throughout these works is the fact that cost accounting methods and data tools are ill suited to measure throughput, inventory, and operational expenses to achieve business the goals of improved profitability and new value creation for growth and competitiveness. Goldratt explores this issue at length in The Goal why a blind focus on cost reduction leads to bad performance.  This problem has continued as throughput and TOC methods have evolved in the information age as pointed out by Reinertsen of the invisibility of DIP because of how R&D expenses are recognized at the time the money is spent. Information inventory and intangible assets remain as a problem for cost accounting and business performance management. This will be a topic of future posts.

Managing Engineering WIP

Engineering work in process (WIP) is notoriously difficult to manage because unlike manufacturing WIP you can’t see it. Engineering WIP is information in various forms along the engineering value stream. Value is added to each ‘engineering work item’ at each successive stage up to customer delivery (either internal or external customers). The key goals are managing effectiveness and efficiency of engineering work. Typically management sees input requests and outputs that are often late and overrun but have trouble seeing the causes in-process. Management could take corrective action if they could see engineering in-process WIP more clearly.

Visualizing Engineering WIP

To visualize engineering WIP firms need to establish a simple system to identify ‘in-process engineering work items’ appropriate for each stage of their engineering value stream. These work items act as a proxies for physical items that would be visible in a manufacturing process for instance. Engineering work often varies in size, complexity, and novelty so a simple (ie. small-medium-big, low-medium-high, proven-modified-novel) rating system should also be used to differentiate the scope & nature of each work item without getting too confusing.

A visual WIP flow board should then be established to see where each work item rests on the engineering value stream as it flows along the engineering value stream as illustrated below:

Engineering WIP Flow Visualization

Post-it notes or total work item counts by size, complexity, or novelty identifiers are marked on a white board and updated weekly or at the operating cadence selected for the firm. Managers should distinguish between engineering work items that are ‘active‘ or ‘waiting in queue’. This distinction is critical to see queues, evaluate throughput, and identify capacity bottlenecks in the engineering value stream. The visual WIP flow board allows managers to see engineering WIP in-process and understand the dynamics of their resource allocation performance.

Queues in Engineering Work Flow

A key advantage of the visual WIP flow board is the ability to see where queues form in engineering as illustrated below:

Engineering WIP Constraints

All engineering managers have experienced the effects of queues but often can’t pin-point them with sufficient visibility in any given week to take effective action. Queues begin to form in any stage as capacity utilization increases beyond about 75-80% based on queuing theory (see Reinertsen for an in-depth explanation of why this is so). For example the production support stage in this example. Queues introduce congestion in the engineering work flow that causes delays that can lead to schedule overruns and idle engineers waiting for data in downstream stages.  Queues in earlier stages are more dangerous for engineering delivery performance.

The queue size – capacity utilization curve also helps to illustrate why maximizing capacity utilization in engineering is bad for schedule performance because in-process queue formation will choke flow.  Most firms today are multi-project organized by matrix so choked flow and congestion can have serious negative consequences from complex inter-project connections. The visual WIP flow board helps management to make the paradigm shift from the traditional ‘maximize utilization‘ paradigm to ‘maximize throughput’ paradigm of lean engineering. Probably the single biggest benefit of the visual WIP flow board is being able to see queues forming before they reach choke flow in order to take timely action. This is also why the visual WIP flow board should be updated weekly at a minimum to capture the dynamics of work flow in engineering.

Engineering WIP Capacity Constraints

To maintain streamlined flow , maximize engineering work efficiency, and avoid congestion/choked flow the amount of WIP in each stage of the engineering value stream should be actively managed. This is accomplished by applying WIP capacity constraints at each stage of the engineering value stream. For example the capacity constraints are defined in the shaded middle row of the visual WIP flow board for each stage of the engineering value stream.

WIP capacity constraints enable engineering managers to control the throughput in engineering. The visual WIP flow board helps to visualize the flow on a day-to-day basis enabling more effective control actions.  When combined with small batch sizes WIP capacity constraints are powerful management control methods. Engineering managers can adjust and set the optimum WIP capacity constraints as they gain experience with the visual tool in practice.

Engineering Throughput Management Levers

How can managers use the visual WIP flow board in practice to take corrective-action? Several management control options or responsive levers are now possible with visual WIP flow board:

  • Work Acceptance Discipline – This is the most critical lever because WIP constraints at the initial stages can ‘throttle‘ the work flow in down stream processes. If too much work is accepted in a short period of time the work the visual WIP flow board illustrates how streamlined flow would become rapidly choked and slow progress along the value stream with waves of underutilization at later stages. By applying ‘go/hold discipline’ management can set engineering up for success along the engineering value stream.
  • Resource Allocation – The visual WIP flow board also helps to see how engineering resources should be allocated to deliver value at each stage. The visual tool inherently allows multi-projects but rather than giving a project view gives a resource view to clearly see capacity constraints for faster resolutions.
  • Resource Organization – The visual WIP flow board provides insight into how engineering resources should be organized to maintain streamlined flow.  The value stream model provides an alternate view of the functional-project ownership problem that many organizations get caught in. Firms may have several business lines that possess separate value streams so managers can identify bottlenecks and allocate resource capacity more effectively to each value stream rather than function or too many projects.
  • Allocating Spare Capacity – Engineering resources that are underutilized will be immediately clear from the visual WIP flow board enabling engineering managers to reallocate their time for short periods to work down queues in other stages. Developing flexible resources is key. Some specialist engineers may be more difficult to move but the visual board helps staff to see how their flexibility will help contribute to the firm business performance but also make their work day less stressful.
  • Targeting Outsourcing / Subcontractors – Stages with perpetual queues are opportunities to target outsourcing or subcontractor efforts. The added overhead and lead time for outsourcing is not appropriate for short term queues and will not be responsive enough to maintain streamlined flow.
  • Engineering Process Improvements – Stages with perpetual queues are also ideal opportunities to target engineering process improvements.
  • Adjusting To Seasonal / Cyclical Variation – By tracking and recording engineering throughput data collected with the visual WIP flow board on a weekly tempo over an annual period management can build better insight into seasonal and cyclical variation. This insight can be useful to resource capacity actions, work acceptance decisions, and outsourcing decisions. All firms experience some form of seasonal work volume effects so the visual WIP flow board can be used to manage short term surges at peak work volumes or scheduling long term development activities during slow periods.
  • Efficient Buffers For Variance & Uncertainty – High task duration variance caused by uncertainty during the ‘fuzzy front end’ of the engineering value stream is key operational difference from manufacturing value streams. Although active risk management and risk reduction methods can be applied to reduce the variation eliminating it outright is not possible nor desirable because it inhibits innovation a key source of value creation. The visual WIP flow board enables engineering management to intentionally build-in capacity buffers to increase throughput.
  • Business Line Value Streams – As firm’s grow and support multiple business lines separate visual WIP flow boards can be established to support resource allocation across the multiple business lines to enable prioritization, de-confliction, and possibly even exploiting differing seasonal cycles for efficiency.

Combined together the visual WIP flow board and active WIP management can dramatically improve engineering efficiency and effectiveness. The improved control realized by such a method can dramatically improve project on-time and on-budget outcomes.

Strategically the visual WIP flow board can also help management to make wise resource investments, partnering decisions, and strategic pivots to fuel growth. Experience with the visual WIP flow board provides management a better feel of how to size and allocate new engineering resources if the firm is growing rapidly. The mix of experience and inexperience can be targeted to stages that present the biggest bottlenecks to growth. Alopex Management Consulting can assist you to implement more effective engineering WIP management for improved business outcomes.

The Fuzzy Front End of New Value Creation

The ‘Fuzzy Front End’ of business is a firm’s new value creation nursery. The ‘Fuzzy Front End’ is the process that starts with the identification of an unmet customer need and the convergence on the optimum solution that a firm can repeatably produce and sell profitably in new or competitive markets. It is also the least understood, most unpredictable, and uncertain business operating process. Firm’s that do this well exploit the new value creation process for sustained growth and new sources of competitive advantage. Firm’s that don’t have an effective new value creation process struggle to survive. Risk adverse managers avoid strategic options that involve business investments in the ‘Fuzzy Front End’.

A key question for management then is how to setup and efficiently/effectively operate a new value nursery that reliability generates sustained growth and new sources of competitive advantage for the firm?

The Fuzzy Front End

The ‘Fuzzy Front End’ is where new opportunities are born, developed, assessed, nurtured, and begin their life as a source of value for the firm. New opportunities are born when an unmet customer need is identified. Often vague or poorly articulated ideas, the unmet customer need requires further development to clarify the new opportunity. Once clarified, a multi-functional team of specialists comprising marketing, product engineering, and designers set about to develop a solution to satisfy the unmet customer need in terms of price, quality, performance, and other appropriate characteristics. The ‘Fuzzy Front End’ is fuelled by creativity, innovation, insight, and customer awareness.

An efficient/effective ‘Fuzzy Front End’ requires the integration of marketing, product development, and business processes. While marketing processes are well understood product development and engineering is often not well understood. The lean engineering framework provides a repeatable process for product engineering to align with the marketing process. Together integrated marketing/lean engineering framework forms an innovation process.  The challenge in achieving an efficient/effective ‘Fuzzy Front End’ rests in the fact that the start and end points are subject to ambiguity. The ambiguity in start and end points is what differentiates the ‘Fuzzy Front End’ process from all other repeatable business processes. Understanding the nature of the start and end points is a critical first step in setting up an efficient/effective new value nursery.

Ambiguous Start Point

Viewed in the context of the lean engineering framework the start point for the ‘Fuzzy Front End’, the unmet customer need, is subject to ambiguity in that a priori the firm can’t be certain that the need is valid or even exists. Sources of ambiguity in the unmet customer need include unstated wants, values, or needs that the customer did not even know that had because no product exists currently in the market today.

Timothy Schipper and Mark Swets in their book Innovative Lean Development say that the goal at the starting point is to express stated/unstated customer needs “accurately and in a form that the design team can understand and directly apply to the project….and this requires a method that allows the team to use the same vocabulary as the users when expressing the values that the solution must apply. The method must also expose the gaps between the problems and potential solutions.”  Schipper and Swets see the ‘Fuzzy Front End’ as a process of closing the user gaps.

Ambiguous End Point

The end point, convergence on an optimum solution, involves decisions, trade-offs, and selection from amongst multiple (if-not infinite) alternatives. The resulting optimum solution is also subject to ambiguity in that a priori the firm can’t sure that the solution with be desired by customers. Sources of ambiguity leading to the convergence on an optimum solution include what price the customer is willing to pay, what combination or set of features hits the customer’s sweat spot, what technologies and building blocks should be selected to form the product, how the product should be manufactured, and how the product should be delivered and services along the entire product life-cycle.

The Process In-Between

The ‘Fuzzy Front End’ process between the ambiguous start and end points is knowledge based work that involves risk, uncertainty, novelty, experimentation, complexity, creativity, and non-routine work. As much as possible the goal is to establish an effective/efficient process although at the detail level may not be as repeatable as operations execution processes that exist in production or service. Various lean product development methods are available for an effective/efficient ‘Fuzzy Front End’ process.

Lean Engineering Framework

The increasing pressure on engineering teams to do more with less is a key theme on this blog. Engineering work must be delivered faster, more efficiently, predictably, with less rework to capture value through improved profitability. In a fast changing world, business urgently requires engineering to deliver disciplined innovation to create new value for growth and increased competitiveness. Engineering leaders grapple with meeting these competing expectations on a day-to-day basis under tight capacity constraints.

Engineering Delivery Paradigm Change

To succeed in today’s business environment engineering leaders must adopt a new delivery paradigm to do more with less. Lean engineering offers a proven paradigm change from traditional engineering.  Traditional engineering seeks to maximize utilization, process large batch sizes, treats variability as bad (killing innovation), treats iteration as bad, and is blind to queues. Engineering delivery performance is poor in the traditional paradigm. Lean engineering seeks to maximize throughput of the constrained engineering capacity, streamline value stream flow, provide flexibility for variability, manage iteration, exploit uncertainty for new sources of value, control scope and reduce batch size, and shorten response time.

When adopting lean engineering firms get frustrated when they try to implement lean manufacturing principles directly to engineering. Lean principles can be applied in a lean engineering paradigm but with modifications that take into consideration the differences in the nature of engineering work from that of manufacturing work.  Some of the common lean engineering methods include:

  • Information Flow / DSM Mapping
  • Engineering Waste Reduction (Information Based)
  • Engineering WIP Constraints
  • Small Engineering Work Batch Sizes With Synchronization, Flow, & Pull
  • Event Driven Design
  • Integrated Process Teams
  • Cadence With Psuedo-Takt Times
  • Strong Project Leadership and Toyota Chief Engineer Model
  • Visual Flow Management

Although these common lean engineering methods produce good results, a deeper understanding of the engineering value stream can help to clarify where some new more powerful lean engineering methods can be applied to deal with today’s business environment.

Lean Engineering Framework

To help understand how the lean engineering paradigm has evolved and matured over the last two decades lean engineering implementors need to clearly distinguish between two very different phases of the engineering value stream. The engineering value stream should be viewed in terms of the  ‘Fuzzy Front End’ phase and the execution phase as illustrated in the lean engineering framework:

Lean Engineering Framework

The ‘Fuzzy Front End’ phase of the engineering value stream begins with the capture of stated and unstated customer needs and seeks to converge on an optimum conceptual solution. The execution phase takes the optimum conceptual solution and defines or specifies the design in a set of deliverable outputs  for the operational value stream to build the product and service value streams to support the customer through the product life cycle. Engineering value stream steps can be aligned with these two phases. The distinction between the ‘Fuzzy Front End’ and the execution phase is critical because the nature of the engineering work in each determines what lean engineering methods are more appropriate to realize the benefits of the lean engineering delivery paradigm.

Fuzzy Front End Phase

The nature of the ‘Fuzzy Front End’ phase work is best described as non-routine, knowledge based work. The starting point is often a moving target because of changing customer preferences, customers may not know what they need, and markets are changing quickly. Work is subject to further risk and uncertainty because the best approach to satisfy the dynamic customer needs is not known. The novelty and complexity of the new product also drives risk. Introducing new technology also adds risk. Designing the optimum solution in the presence of risk and uncertainty involves creativity, experimentation, and alternative exploration. These factors influence the nature of the engineering tasks. Engineering tasks in the ‘Fuzzy Front End’ are highly variable, inherently unpredictable, non-repetitive, of non-homogenous task duration, with variable delay costs. Engineering work in this phase is often more customer ‘project like’ with a unique cluster of variable activities. Notwithstanding these challenges convergence on a design solution must meet cost, schedule, and quality requirements.

There is a continuum of ‘Fuzzy Front End’ variability in which many firms or product lines may differ. At the low variability extreme some firms simply choose to imitate to constrain development risk although they can’t completely eliminate all risk from reverse engineering products. At the opposite extreme firms that seek breakthrough products experience very high variability. Firms can fall anywhere along this variability continuum between these two extremes.

The bottom line for the ‘Fuzzy Front End’ phase is that managing for low process variance and repeatability will not work. Attempting this will kill innovation by missing potentially high value creating alternatives. Proven lean engineering methods more suitable to the ‘Fuzzy Front End’ phase include:

  • Set Based Design
  • Design-To-Cost
  • Fast Learning Cycles
  • Rapid Prototyping, Simulation & Testing
  • Agile Scrum Software
  • Trade-Off Curves
  • Active Risk Management
  • Integrated / Concurrent Teams with 3P / DFMA or DFSS as applicable
  • Freeze Gates with Late Binding
  • Knowledge Capture/Transfer
  • Minimum Viable Product/Product Variety Management
  • Supplier Integration
  • Work / System Chunking For Small Batch Sizing

Execution Phase

The nature of the execution stage on the other hand does lend itself more to principles of how lean manufacturing is applied because engineering work is more routine – detail drawings, testing, drawing release, shop query response, and customer query responses. The engineering execution phase has well-defined start and end points where task variability is much lower.  Execution stage engineering work is procedural, scripted, and rule-based. Engineering tasks are predictable, repetitive, homogenous durations, and with homogenous delay costs.

Managing for low process variance and repeatability is appropriate in this stage. Traditional lean methods are more effective in the execution phase. This also explains why lean implementation success is often reported for drawing processes or testing processes.

Proven lean methods for the engineering execution phase include:

  • Process Streamlining / Traditional Value Stream Mapping
  • Smart Sequencing of Smaller Work Batches
  • Workload Levelling
  • Resource Flexibility
  • Red-Line Change Process
  • Velocity Scheduling

Improvement Emphasis & Balance

The lean engineering framework also provides a good model for engineering leaders to evaluate if they have the right balance in their engineering delivery improvement plan. Failing to properly understand the nature of the ‘Fuzzy Front End’ phase of the engineering value stream will also lead to an overemphasis on execution improvements or an attempt to apply low process variance lean methods to high variability work that will not deliver good results.

Although lean improvements to the execution phase will deliver cost reductions, faster cycle times, and improved quality the execution phase is completely dependent on the effectiveness of the ‘Fuzzy Front End’. This also applies to all the down-stream value streams including manufacturing, assembly, and service. The reason for this is that most of the life cycle costs are ‘baked into’ the selected conceptual design during the ‘Fuzzy Front End’ whether this is done intentionally or not. Therefore depending on where your firm sits on the development variability continuum the impact of improvements targeted on the ‘Fuzzy Front End’ could be very large compared with any savings from the execution phase. Engineering leaders should therefore bring a new perspective of their ‘Fuzzy Front End’ phase and determine if the return on investment from improvement efforts are targeting the right areas.

The lean engineering framework helps engineering leaders to understand the lean engineering delivery paradigm to succeed in today’s business environment. Although not every lean engineering improvement method will be applicable to each firm the framework enables better improvement investment decision-making, ideas for improvement planning, less implementation frustration, and better outcomes.

6 Hidden Demands On Engineer’s Time

Firms never have enough engineering resources to meet business demands yet projects often overrun in cost and schedule.  Today’s engineering work environment is a complex and chaotic mix of market change, multiple projects, and development risk/uncertainty.

Development projects, the bread and butter of most engineering organizations, require robust project and risk management protocols to achieve cost, schedule, and quality goals. Engineering resources are often pulled in different directions with discretionary requests for their time contrary to what business leaders set as priorities and their strategic intent. The gap between reality and perception can be large leading to misunderstanding, misdirected blame, reduced morale, and degraded business performance.

To understand engineering delivery throughput it is essential that business leaders understand the total demand that the firm is placing on their engineers beyond project commitments caused by six hidden demands on engineer’s time.

Total Engineering Workload

A non-supervisory engineer’s normal available work time for direct engineering project work is about 82-86% of total possible work hours or approximately 47 weeks when holidays, vacation, and normal business demanded time (performance reviews, town halls, functional group meetings, training) are taken into account. There are slight differences for country, role, company situation, and their level (determining vacation) but this baseline range is fairly consistent world wide. Overtime and weekends are normally held in reserve for short term capacity surges to address unforeseen issues and is over and above this total possible work time.

The reality for most engineering organizations is a total engineering workload for a non-supervisory engineer is comprised of eight types of activities:

  • Multi-Project Direct Work Tasks & Activities;
  • Development Project Risk / Uncertainty Mitigation & Treatment;
  • Discretionary Business Activities;
  • Multi-Project Inefficiencies;
  • Un-Forecast Back-Door / Walk-In Activities;
  • Process Inefficiencies (Business & Engineering);
  • Rework; and
  • Daily Distractions.

Project schedules are often based on the first two types of activities or the work that one would expect would make-up the majority an engineer’s productive time. This approach can lead to under resourced engineering organizations. The problem is that the six hidden demands can create 15-25% additional work. Only 60-70% of engineering capacity may be going to project work as a result causing schedule and cost overruns as well as excessive overtime to keep up. This work volume disconnect drives the engineering capacity perception / reality gap. To address the gap business leaders and engineering management/staff need to determine the extent to which the six hidden demands are impacting their engineering capacity plan.

Discretionary Business Activities

Discretionary business activities are undertaken for good reasons because they lead to growth or improvement in business performance. Engineers often must support business sustaining activities because of their product/technical knowledge, experience, customer knowledge, and academic credentials.  Bids and proposal support alone can on average demand 3-5% engineering productive capacity. Other discretionary business activities aimed at improving business performance may include enhanced training, continuous improvement, or reorganizations which can also consume several percent engineering productive capacity.

The firm’s industry environment, market cycle, and the degree of market force driven change can also have a significant short or medium term impact on the volume of this discretionary engineering workload. Assumptions about discretionary business activity volumes based on years with little change leads to significant engineering capacity demand under estimation.

Capacity availability problems also often arise from discretionary business activities if they are not timed or integrated well with direct project schedule commitments. Discretionary business activities should be synchronized during project demand valleys avoiding seasonal project demand peaks if present in annual work cycle.

Multi-Project Inefficiencies

Most businesses today are multi-project environments because the extremes of dedicated functional or dedicated project teams are inefficient or impossible to implement with scarce specialist expertise. The number, size mix, complexity mix, and novelty mix all combine dynamically to create a constantly shifting work plan with winning / losing project managers. Multi-project inefficiencies are always bad.

Priority conflicts are a leading source of project schedule delays in multi-project environments. Organizations that operate lean or with labour shortages are particularly susceptible to priority conflict. Furthermore a misalignment between project priority and project manager assertiveness can often put individual engineers into difficult situations that impacts morale and job satisfaction that if left unchecked can degrade the operational effectiveness of the engineering organization and impact overall business performance.

Inefficiencies can also be caused simply by the sheer number of individual projects.  The more projects that individual engineers support the more project related overhead activities they are required to keep up with. Project related overhead activities include stand-up or status meetings, project email information, email responses from them, schedule updates/EACs/ETCs, and customer meetings. This activity can require several hours of work per week to sustain multiplied by the number of projects and depending on the stage of the project can be quite intense. This workload is often budgeted under project management as opposed to engineering so is drain on engineering capacity even though project budgets are fine and the net result is a schedule overrun.

To solve this issue business leadership need to implement engineering WIP constraints by limiting the number and mix of projects in process and establish a company wide priority system. Leadership must resist the temptation to load engineering staff up to 82-86% which causes schedule overruns, cost overruns, and near constant overtime leading to fatigue and increased error rate.

Un-Forecast Back Door / Walk-In Requests

Often business leaders and even engineering managers are unaware of many requests coming through the back door to their staff. Individual engineers want to do their best, satisfy external/internal customers but are left confused and unclear of priorities.   Back door and walk-in requests can lead to project schedule delays. Typical examples of back door  and walk-in requests for engineering advice include engineering support to supply chain, engineering support to production, and customer support requests. Another type of back door and walk-in requests on engineers are management questions or management emergencies. Although good intentioned engineers are compelled to respond or they fear being labelled as non-team players, non-responsive, or difficult employees.

Leadership should test whether these back door and walk-in requests are essential for the business and if so should budget to meet this demand. A separate support group could be established if the volume is large enough to separate support work from project work potentially rotating junior staff through the group for experience. Often engineering support groups are completely overhead but when times are difficult the groups are down-sized and the work load moves back to the project support engineers leading to a re-emergence of schedule and cost overruns.

Process Inefficiencies

Waste and inefficient processes add to total engineering workload. Process inefficiencies can relate to either business or engineering process waste. Focusing on engineering process inefficiencies, forms of engineering waste include:

  • Over production of information;
  • Over processing of information (over design);
  • Miscommunication of information;
  • Stockpiling of information;
  • Generating defective information;
  • Waiting for information; and
  • Unnecessary movement in working to the process.

An excellent discussion on engineering waste can be found in Waste in Lean Product Development by Josef Oehmen and Eric Rebentisch. Lean engineering methods provide solutions to eliminating waste in engineering processes.  Simply redesigning business or engineering processes can free up enough engineering capacity to mitigate the other hidden workload – sometimes in the 10-15% range. Leadership should ensure that a volume of engineering capacity is budgeted for continuous improvement on an annual basis.

Engineering Rework

Engineering rework can also be a large drain on engineering resource capacity sometimes exceeding 5%. Engineering rework is difficult to see in the same way that engineering work in process is difficult to see because engineering work involves information rather than physical parts. Engineering rework is any effort spent in correcting information resulting from engineering mistakes, errors, or change required to manufacture, build, or support a product. Often though the actual presence or need for engineering rework can be subjective where right or wrong are not clear cut but accountability for solving engineering rework rests with engineering staff and engineering management. The degree of product novelty and complexity can drive higher rates of rework. Common defect categories include:

  • Technical accuracy;
  • Technical argument structure & soundness;
  • Engineering approach;
  • Deliverable completeness;
  • Regulatory compliance;
  • Deliverable format, typos, or grammatical errors (least important)

Rework is a form of waste and must be eliminated. Organizations should establish engineering error tracking systems as part of an engineering quality management system to determine trends, volumes, and support root-cause analysis continuous improvement activities to reduce rework. Rework should be measured and addressed in conjunction with engineering process improvement.

Daily Distractions

Finally, the daily distractions that impact everyone in a work environment go largely unnoticed in most firms also drain valuable engineering resource capacity. Daily distractions include: phone calls; emails; office noise; excessive meetings; and social walk-in interruptions.  Even just 15min/day of distractions can add up to 60 hours per person. A good method to address daily distractions is to have quiet times, often in the morning when staff are most productive, where emailing and phone calls are not permitted.

Annual Engineering Capacity Forecasting

In today’s complex work environment business leaders and engineering managers need to  understand the total engineering workload, how it behaves dynamically, and how it can degrade the operating efficiency of their finite and constrained engineering capacity to correctly forecast the needed capacity.  The six hidden demands on engineer’s time can have a significant impact on engineering delivery throughput.

Problem areas are opportunities to free up capacity to use on more productive work and reduce project schedule and cost overruns. The annual business operating plan is the time to take a deep look at total engineering workload, underlying work volume assumptions, and plan improvement work to prepare a realistic engineering workload forecast. Periodic time studies may be worthwhile to uncover the degree to which the six hidden demands on engineer’s time are causing project schedule and cost overruns.

Set Based Design For Lean Engineering

Set based design (SBD) or set based concurrent engineering (SBCE) as it is also known is a powerful lean engineering method. Firms that design complex systems should consider this approach to deliver better designs more efficiently. A caution though that this is an advanced lean engineering method so is not appropriate for new design organizations.

What is Set Based Design

Set based design builds on concurrent engineering principles (multifunctional, co-located team design) by establishing a design space for design optimization to meet a challenging set of requirements. Set based design involves exploring many design alternatives up-front to allow for trade-offs particularly important for integrated systems with competing requirements.

Set based design improves on ‘point design’ with its’ many shortfalls – fixation on first design selected, time delay before feedback, and locked in cost too early in the design process. The differences between point design and set based design can be best understood visually.

Set Based Design

Set-Based Design: A Decision Theoretic Perspective, Paredis, etal, GIT

A key principle underlying set based design involves delaying design decision later in the design process to achieve optimal trade-offs by eliminating inferior or sub-optimal design alternatives. Although counter intuitive while the design decisions are delayed set based design involves front end loading the design stages of the project to develop the design alternatives. The front end loading facilitates early learning, early identification of risks, and early mitigation of risks. A key success factor is the discipline to identify all possible design alternatives up-front without allowing the design to move on with a favourite alternative – creativity, innovation, and practicality under pin this step.

In summary, the main advantages of set based design include:

  • Supporting concurrent engineering which eliminates waste
  • Delays design decisions until later in design process to avoid locking in costs early before important learning can occur
  • Facilitates partitioning of complex designs by functional specialist groups
  • Supports design flexibility particularly with respect to modularization and reuse

History and Applications

Set based design was originally developed by Toyota within the Toyota Production System but not as well advertised as lean manufacturing.  Set based design has been studied since the 1990s but is mainly applied in OEMs. Adopters have mainly begun their lean engineering journey and are exploring advanced improvement techniques. Set based design has been applied in automotive, ship building, EPC, and aerospace.

Moving forward the main challenge to implementation is establishing practical procedures. Most firms establish unique digital or hybrid manual/digital design spaces to handle product design of varying complexity. We are at the stage where a high degree of customization is required to adapt the principles to new product development.