Monthly Archives: July 2013

Lean Engineering Framework

1 Reply

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.

Product Design For Uncertainty and Transient Advantage

Leave a reply

Managing uncertainty in new product development is difficult in a rapidly changing world. Firms need to adopt strategies for transient advantage in turbulent markets as recently observed by Rita McGrath.  Product developers can’t wait though for all the answers and absolute certainty that risks missing market opportunities. Firms need to capture as much value as possible from new products yet product development cycles can be long and potentially beyond the timeframe required for a short wave of transient advantage.

Product developers need to give their firms maximum flexibility to exploit transient advantages so to mitigate and exploit uncertainty product developers need to design-in a higher degree of reliability (in uncertain conditions), robustness, versatility, flexibility, evolvability, and interoperability in their product platform and product lines. To be successful product developers need to understand uncertainty and clarify design strategies available to them during the ‘fuzzy front end’ of design.

What are the varieties of uncertainty and what design strategies can be used to manage a diversity of uncertainties?

Uncertainty Continuum

The simple model of known-knowns, known-unknowns, and unknown-unknowns is a useful starting point to understand the varieties of uncertainty but it is not detailed enough for product development. Schlensinger, Kiefer, & Brown’s uncertainty continuum provides a deeper look at varieties of uncertainty mapping along a scale of predictability from the known to the unknown. Their uncertainty continuum maps from the known along a scale of increasing unpredictability as follows:

  • Completely Predictable – You can say with certainty what the outcome of a given situation will be such as with physical laws.
  • Predictable Through Probability – The outcome can be defined to a particular confidence level using statistics but extremes may exceed bounds.
  • Predictable Through Other Analytic Methods – The outcome might be predicted through chaos theory, computer modelling, which is less precise.
  • Predictable Through Pattern Recognition, Experience, and The Like – The outcome might also be predicted based on limited prior experience or from patterns. The emerging world of big data.
  • Not Predictable At All But You Can Say What Can’t Happen – The outcome is not predictable but certain cases can be ruled out.
  • Completely Unpredictable – The outcome is completely unpredictable.

A linear scale is useful to model the range of predictability to classify variables according to how well the value can be predicted for design but it does not provide insight into the severity of events that is important for risk mitigation / opportunity exploitation in product development.

Uncertainty Framework

Another excellent framework for broadly understanding uncertainty of complex systems was proposed by McManus and Hastings (based largely from experience in the US space program) and one of the best I have seen at capturing a holistic view for managing uncertainty in product development. This framework links categories of uncertainties through risks and mitigations/exploitations to system outcomes to be more useful to engineers.

The framework provides a top-down model to structure uncertainty and risk taxonomies to illustrate cause and effect through the relationship – <uncertainty> causes <risk/opportunity> handled by <mitigation/exploitation> resulting in <outcome>. See the paper for excellent cases to understand the framework. I particularly like this framework because it does not just frame effects of uncertainty as a downside risk but upside opportunity that firms can exploit for transient advantage. The framework is also general in nature allowing it to be applied/tailored to any application.

Varieties of uncertainty used by McManus and Hastings are:

  • Lack of Knowledge –  Facts that are not known, or are known only imprecisely, that are needed to complete the system architecture in a rational way. Knowledge in this case may just need to be collected (because it exists somewhere already) or created.
  • Lack of Definition – Things about the system in question that have not been decided or specified.
  • Statistically Characterized (random) variables/Phenomena – Things that cannot always be known precisely, but which can be statistically characterized, or at least bounded.
  • Known Unknowns – Things that it is known are not known. Things are at best bounded, and may have entirely unknown values.
  • Unknown Unknowns – Things that are gotchas that we cannot contemplate occurring with our current understanding.

An improvement combines the uncertainty continuum defined by Schlensinger, Kiefer, & Brown with the front end of McManus and Hastings’ uncertainty framework to more clearly understand how uncertainty maps to risks.

Design Strategies For Uncertainty

Both models provide guidance for design strategy to give firms flexibility for transient advantage.  The uncertainty continuum suggests at the extreme of completely predictable proven design heuristics are appropriate. At the higher extreme of unpredictability a short horizon learning experimental approach such as creaction is appropriate.

The McManus and Hastings’ uncertainty framework is more powerful for designers by linking uncertainty to levers of design.  McManus and Hastings provides a useful list of risk mitigation and exploitation strategies for new product developers to consider. These design strategies help to fill in the middle zone of the uncertainty continuum. McManus and Hastings identify nine strategies:

  1. Margins – Designing systems to be more capable, to withstand worse environments, and to last longer than ‘necessary’.
  2. Redundancy – Including multiple copies of subsystems (or multiple copies of entire systems) to assure at least one works.
  3. Design Choices – Choosing design strategies, technologies, and/or subsystems that are not vulnerable to a known risk.
  4. Verification and Testing – Testing after production to drive out known variation, bound known unknowns, and surface unknown unknowns.
  5. Generality – Using multiple-function (sub)systems and interfaces, rather than specialized ones.
  6. Upgradeability – (sub)systems that can be modified to improve or change function.
  7. Modularity, Open Architecture, and Standard Interfaces – Functions grouped into modules and connected by standard interfaces in such a way that they can ‘plug and play’.
  8. Trade Space Exploration – Analyzing or simulating many possible solutions under many possible conditions.
  9. Portfolios and Real Options – Carrying various design options forward and trimming options in a rational way as more information becomes available and/or market conditions change.

Although several of these strategies most engineers would naturally use but the list may provide some suggested approaches that are not often considered. These nine strategies help to realize a new product design with system outcomes for reliability, robustness, versatility, flexibility, evolvability, and interoperability.

Most of these design strategies add cost to the new product development project and the product itself but the benefit is flexibility. Firms need to weigh the cost benefit of product flexibility in an uncertain world to support a strategy of transient advantage.

Sustaining Systems Thinking in Engineering Teams

1 Reply

Engineering leaders are increasingly concerned about sustaining engineering competency and experience as the baby boomer generation begins to retire taking with it a tremendous volume of knowledge and experience. Complex system based industries such as aerospace and defence, automotive, and shipbuilding are particularly susceptible to the loss of systems engineering competencies gained from a long sequence of increasingly advanced projects delivered between the 1960s to the present day.

A PhD thesis by Caroline Lamb Collaborative Systems Thinking: An exploration of the mechanisms enabling team systems thinking explored how engineering teams approach systems thinking in aerospace systems development.  Motivated by the greying of aerospace engineers in America this study provides a very comprehensive view of how systems thinking can be sustained in the long run following a loss of corporate knowledge (ie. from baby boomer retirements, corporate restructuring, etc).

Although specific to aerospace this research provides some very useful generalized approaches to establish, sustain, and improve engineering teams engaged in complex systems development. This research complements views on teamwork, innovation, and creativity when applied to complex systems.

Collaborative Systems Thinking

Lamb defined collaborative systems thinking as ‘big picture‘ thinking and a necessary skill for complex systems design coupling the analytical side of engineering design with the creative side of engineering design that ensures the final product delivers the desired functionality. In this research the term ‘collaborative systems thinking’ is used to differentiate between systems thinking within teams and systems thinking performed by individual engineers. This differentiation is useful in a generalized context where most would agree today that teamwork is the favoured organizational effectiveness work model.

Generalized Traits of Collaborative Systems Thinking Teams

Lamb reports that generalized traits of collaborative systems thinking teams. Collaborative systems thinking teams:

  1. Engage in more consensus decision making.
  2. Require a team structure with three categories of membership: systems leadership (strong systems thinkers who balance technical and social interactions of the team); technical translators (act as interface between system leadership and functional experts); and functional experts (bring specialized technical knowledge to the team).
  3. Prefer communication by real-time group interactions.
  4. Possess team members who have a higher number of past and concurrent (optimal maximum of three) project experience.
  5. Prefer supportive team environment with enablers of trust, shared understanding of team purpose, and engaging in good discussions that stimulate good ideas.
  6. Have more creative work environments with high decision freedom.
  7. Require both technical and social leadership.
  8. Conceptual design teams are more likely to engage in collaborative systems thinking.

Traits that were not found to have a strong influence on collaborative systems thinking included: team size, collocation, customer base (ie. military vs commercial), measures of technical process use or tailoring, and individual systems thinking.

Systems Thinking Heuristics

Lamb captured a number of heuristics that describe collaborative systems thinking team behaviours. Collaborate systems thinking teams:

  1. Concentrate on the system: “Collaborative systems thinking teams concentrate on the system, on finding an elegant solution. Requirements are secondary to that design. Teams engage in systems thinking when the individuals are genuinely interested and engaged in the task. Fundamentally, the solution comes not when we are concentrating on the constraints, but when we become engrossed with the problems at hand.”
  2. Communicate effectively for the context: “Clear communication is critical to collaborative systems thinking. Teams tend to over use email and other IT tools. Sometimes you just need to walk around and speak with others. After all, you can’t delete a walk-in.”
  3. Ask lots of questions: “The asking and answering of questions brings both parties to new realizations. It helps teams and individuals identify built-in assumptions and move away from what we’ve always done. A team needs the leader to ask the right questions; an individual who is curious, imaginative, knowledgeable, and can help others look at the problem from outside of the box.”

  4. Good process execution needs both standardization and innovation: “Many people are comfortable following guidelines and rules, but process can become brittle. Teams require a balance of individuals that follow the letter of the law and individuals who follow the ‘spirit’ of rules; who reframe problems to get around rules. This is how we innovate and improve.”

  5. Both experience and analysis are important: “In a team setting there must be a balance between experience and analysis. Experience feeds the team’s intuition and frames how each new problem is faced. However, in innovative situations intuition can be a liability, and teams must use tools to find new knowledge and overcome the inertia of past experience.”

  6. History tends to repeat itself: “Engineering mistakes repeat every 7-10 years. This is the time it takes for critical people to rotate off a program and for important knowledge to be lost and rediscovered through failure. Successful programs have a line of succession: a continuity of knowledge through awareness of the past, present, and future. When this continuity is broken is when teams are doomed to repeat failures of the past.”

  7. Engineers are unique individuals: “Team members, especially the smart and innovative, come with ‘warts.’ Team leaders cannot tolerate disruptive behavior, but need to treat each person individually to get their best work and to help them become better engineers and team members.”

Implications

This research provides useful guidelines to assist engineering leaders create the best environment for engineering teams involved in the ‘fuzzy front end’ of product development where uncertainty is high. The research is perhaps less relevant to later execution engineering work.

The research also provides some key insight into team structure and make-up. To sustain systems thinking firms should keep teams formed over the long term to build experience even though individuals may leave or join the group and the team may be assigned to new projects.  The research suggests that to sustain systems thinking a great deal of attention needs to be paid to developing engineering leaders with the combination of technical and social skills to deliver integrated systems.

Social media has some interesting implications on future team based engineering particular where it enables real-time communication if team members are not co-located.