Definitions of Systems and Systems Engineering

Now that we have taken what is hopefully is a fresh look at what systems engineers do let’s back up and look at some traditional definitions of a system and systems engineering. I have used these definitions for so long that I have forgotten their original sources and I apologize. There are almost as many definitions of a system and of systems engineering as there are systems engineers so I prefer not to put much emphasis on these definitions but include them for completeness and to make a critical point about defining things with text based definitions.

One source says a system is a collection of objects working together to produce something greater. A system can be tangible, like a rocket or a communications network, or intangible like a computer software program or any combination of tangible and intangible. A system is composed of unique elements and the relationships between these elements. The elements in a system can be highly hierarchical or essentially flat like a network, or again any combination of hierarchical and flat. A system has the further property that it can be unbounded; each system is invariably a part of a still larger system. This characteristic of a system leads to a complication in definitions. Some systems engineers use names like “system of systems” to account for certain types of systems; often those involving complex interactions with humans. From a semantics point of view a term like “system of systems” makes no sense as it’s equivalent to saying a “universe of universes”; but if such terms communicate something important to those working on the development of certain types of systems then the terms serve a useful purpose. Also we have to remember that sometimes customers invent new terms and we have to use them even if we don’t agree. It usually isn’t worth trying to be “virtuous and pure” over such issues.

One pragmatic way to define a system is that it is the design element at the top of the hierarchy being developed by a systems engineer’s team. Thus it’s the collective name of that design element. The system being developed may be part of a larger system but the development team only has to be concerned with the requirements for their system and the interfaces of their system with the larger system, not with what to call the larger system.

Eberhardt Rechtin, in his book “Systems Architecting: Creating & Building Complex Systems”, says the essence of systems engineering is structuring. Structuring means bringing form to function or converting the partially formed ideas of a customer into a workable model. The key techniques are balancing the needs, fitting the interfaces and compromising among the extremes.

Others describe systems engineering as both a technical and management process. One source says “it is a discipline that ties together all aspects of a program to assure that individual parts, assemblies, subsystems, support equipment, and associated operational equipment will effectively function as intended in the operational environment”. One of my favorite definitions is from a U.S. Navy web site.  It says systems engineering “is a logical sequence of highly interactive and iterative activities and decisions transforming operational needs into a description of system performance parameters as well as a preferred system configuration.”  This definition is amusing because it is exactly correct in saying systems engineering is highly interactive and iterative but the reality is that it is logical only to a highly experienced system engineer. Something that is highly interactive and iterative hardly appears logical to someone not intimately familiar with it.

Comparing these definitions with the four tasks for systems engineers defined in Figure 3-3 of the previous post shows that the definitions do not capture all that is implied in the four tasks. From the definitions would a young engineer realize that a system engineer has a role in planning and scheduling a development program; or in verifying the performance of a system design? If this chapter started with the standard definitions of a system and systems engineering would a logical path to the four systems engineering tasks have been easily found? If just the five text words had been used to define the product development cycle instead of the labeled graphical model would it have raised the question of whether the four tasks are rigidly sequential or allowed to overlap in time? Perhaps, but not as easily as it is starting with the graphical model of product development as the five simple sequential tasks or phases of define, design, build, test and produce.

Graphical Models vs. Textual Models

There is a profound principle in the last paragraph above. Textual descriptions of complex ideas are often incomplete and very often lead to different readers having different understandings of the ideas. Labeled graphical models of complex ideas are less ambiguous. This is a critical point for systems engineers to remember and use in their work. Look back at the second figure in the previous post. The thin solid arrows indicate that the outputs of a task are the inputs to the next task. In the development of complex systems each task typically involves different teams. Therefore it is critical that the outputs of one task be easily understood and unambiguous to the teams working on the following tasks. Labeled graphical models are much easier to understand and less ambiguous than textual descriptions for most engineers.

Think back to the “Craftsman” model of product development defined earlier that was successfully used for centuries for simple products. The output documentation from the chief engineer and his/her team was engineering drawings. The workers and managers in the factories responsible for producing the products could clearly understand and use these engineering drawings. Imagine if the chief engineer and his team submitted textual descriptions of their product design to the factories.

Another example of a labeled graphical model being superior to textual descriptions is maps. Imagine going on a driving vacation through your country using just a textual description of the location of towns and the roads connecting them. Just keeping track of where you are with respect to the textual descriptions would become a time consuming task. This is why maps became the standard model for describing geography centuries ago.

One of the reasons development of complex systems often failed to achieve the planned schedule and budget after systems engineering was introduced in the 1950s and 1960s to address  the complexity of modern systems was that some of the documentation produced by systems engineers and passed to design engineers was textual descriptions rather than labeled graphical models. Unfortunately this practice continued when concurrent engineering was introduced and continues today for many organizations. One of the primary objectives of this book is to convince systems engineers to use labeled graphical models wherever possible and avoid textual models wherever a graphical model can be used instead. This is one of the keys to achieving faster and lower cost systems engineering, as will be explained in a later article.

System Engineering and Design Engineering

Accompanying the introduction of systems engineering was the practice of distinguishing between systems engineers and design engineers. It was natural to label the engineers doing the systems engineering work as system engineers. Since functional engineering organizations were typically broken down into mechanical departments, electrical departments or some similar differentiation it was natural to set up systems engineering departments for the systems engineers. This is unfortunate because all engineers do some systems engineering work and all engineers do some design engineering work.  It is true that systems engineering has become a specialty just like other specialties of design engineering and that systems engineers use some processes that are fundamentally different than design engineers. We must keep the various specialties but perhaps we could change the term design engineer. This might help remove some of the undesirable barriers that creep into our organizations that inhibit effective communications. However, using the term design engineer helps define the different rolls of system engineers and the various specialties. Let’s use the diagram from Figure 3-4 to help define the traditional roles and responsibilities of systems engineers and design engineers. The result is shown in Figure 3-5.

Figure 3-5 The traditional roles of system engineers and design engineers involve responsibilities within each development phase.

 From Figure 3-5 and the description of what takes place during each task or phase we can further define the traditional differentiation between systems engineers and design engineers in simple terms as follows:

·         Systems Engineers Determine

o   What’s to be built

o   How it’s supposed to function

o   Whether it meets its requirements

·         Design Engineers

o   Determine how it’s to be built

o   Make it  operate (integration & test)

It is critical to understand that both systems engineers and design engineers are involved in all five phases as shown in Figure 3-5. To further define the role of systems engineers it helps to look at how they are integrated into a typical organization. That is the subject of the next article.

Introduction to Systems Engineering

Systems engineering is defined in many texts. Rather than repeat the standard definitions at this time it is helpful to define these terms in the simplest possible manner. The reason is that having very simple definitions helps us to consider things from a fundamental point of view, which makes it easier to come up with new insights. Later traditional definitions are presented and comparing the two may give new insights. New insights are needed in order to understand new methods and, eventually, to develop improved methods. This chapter, presented in several articles, defines four fundamental tasks that systems engineers perform, provides definitions of systems engineering, compares the rolls of systems and design engineers and shows how systems engineers fit in a modern product development organization. The four systems engineering tasks are deliberately defined before defining systems engineering or systems engineering processes. Although this seems out of order it helps take a fresh look at systems engineering methods. To set the stage for defining the four tasks of systems engineering we look at the overall product development process or development cycle as it is usually called.

The Product Development Cycle

In the exercises at the end of the last post the reader was asked to define the product development cycle in simple terms a grandmother would understand, assuming the grandmother is not a systems engineer. The purpose of this question is to make the reader think about the fundamental tasks that comprise product development. Sometimes people get into the detail of their work to the point they lose sight of the fundamentals of what they are doing. Figure 3-1 illustrates what the reader might have said.

Figure 3-1 Product development consists of five tasks, or phases, at a fundamental level.

Product development organizations typically define the product development cycle in a much more complex diagram, or set of diagrams, that describe the tasks to be performed in much more detail than shown in Figure 3-1. However, it is important to step back and look at the fundamental tasks, or phases if you prefer, in as simple of terms as possible if we intend to improve the overall process. Starting with the simple flow chart in Figure 3-1 we define the work that systems engineering encompasses, again in simple terms, because our objective is to seek better methods for systems engineering. Note that Figure 3-1 leaves out the object of the verbs. This forces us to think about what it is that we are defining, designing, etc. For example, it’s necessary to define both the product and the program for developing the product. Decisions must be made about what will be designed, what will be tested and what will be produced. These decisions are product dependent and involve systems engineers if only as advisors. We can add some of the top level inputs and outputs of each step in Figure 3-1 as we think about what it is that we are defining, designing, etc. A result for one type of product might look like Figure 3-2.

The tasks shown are performed by a variety of managers, technicians, and engineers; systems engineers, design engineers, test engineers, etc. We seek to define just the tasks performed by systems engineers. Actually systems engineers are involved in all five tasks to some extent. Typically systems engineers are responsible for the specifications and plans that are produced in the “Define” task and contribute to or oversee work in the other four tasks. With these roles in mind we can think about the tasks the systems engineers perform. Recall that here nontraditional terminology is used at to describe the systems engineering work.

Figure 3-2 The outputs of a fundamental product development task are the inputs of the next task

Four Fundamental Tasks for Systems Engineers

A simple but useful terminology for defining systems engineering work is shown in Figure 3-3.

Figure 3-3 Four fundamental tasks performed by systems engineers during the product development cycle.

The four tasks listed in Figure 3-3 are not the only way to define systems engineering tasks, or are these are a complete description, but these four tasks help us understand the fundamentals, if we allow for some flexibility in our definitions. This becomes apparent as we examine in more detail the four tasks in later chapters.

Notice that the first three systems engineering tasks are shown as overlapping in time rather than being sequential in time. This is because these tasks should overlap in time. This is a good point to introduce one complexity in the fundamental task list shown in Figure 3-1, then we can return to defining systems engineering.

Progressive Freeze of Product Development

The product development tasks should not be rigidly sequential but should allow for some overlap in time, as indicated in Figure 3-4.

Figure 3-4   The fundamental product development tasks should be allowed to overlap in time.

Often major product development tasks, or phases, are gated by milestone reviews. This implies that all work must be completed on one phase of the product development before work can start on the next phase. It is not good practice to demand rigid adherence to the gating process. A better approach is to allow some work to begin as soon as the information needed for initiating the task is available. This is called progressive freeze, as discussed in previous  articles, and it adds flexibility to the work that offers benefits that outweigh the small additional risks incurred.

Progressive freeze is practiced by freezing an element of the engineering work, when the risk of freezing the work is acceptable and allowing work on the next phase to begin before the next milestone review. Engineering judgment is used to determine when the risk is acceptable that the continuing work on other elements of the development work won’t change the results of the frozen work element.

A couple of examples help understand the progressive freeze concept. Consider a radio frequency (RF) sensor. Freeze the antenna architecture when the gain, antenna configuration and interfaces are determined; initiate the antenna design in parallel with other subsystem architecture trades. Hold a system design review (SDR) or architecture review, if required, when all subsystem architectures are frozen. Second, consider an infrared sensor. The telescope architecture can be frozen when the aperture size, the form, the optical subsystem f/# and interfaces are determined. The telescope design can then proceed while the focal plane, electronics and cooling architecture trades continue.

There are several benefits from beginning the design early for the RF antenna or the telescope in these two examples. The biggest is the flexibility in scheduling the skilled antenna and telescope designers. Critical skills such as these are often in high demand on several programs. By enabling early starts of the design work involving critical skills it increases the total time period for the design work to be accomplished without impacting the program schedule and helps avoid program delays due to the unavailability of critical skills.

A second benefit is that progressive freeze facilitates sequencing design decisions throughout a design phase. Product development involves thousands of decisions in each phase of the work. Delaying decisions until just before major design reviews complicates decision management to the point that the quality of the work can be threatened. Making decisions as soon as risk allows spreads the decisions throughout a development phase and makes decision management easier. We will return to this issue in a later chapter where we explore design decision management in more detail.

 Another benefit is that should a problem arise in the design that impacts other architecture the architecture changes can be made easily if these trades are still underway. For example, suppose the RF antenna designer discovers that the desired gain margin cannot be achieved within the constraints defined in the architecture trades. If the other trades are still underway it is much easier to decide how to accommodate the problem. It may be that a larger envelope is available or it may be that the lower gain is acceptable with tighter control of noise figure in the amplifier electronics. Finally, allowing more time for the designers to work on a design element may result in a better design. Sometimes engineers need to set work aside for a short period while they mull over a difficult design issue. Sometimes unforeseen difficulties arise in design and having extra time to work out these difficulties helps avoid program delays.

Review of Fundamental Principles for Product Development

Examination of the “lessons learned” from over 50 years of evolving product design methods suggest that there are some basic principles that should be considered when examining new methods or tools for product development. Some are evident in the examples given in the previous posts and others derive from the experience of successful systems engineering teams. I suggest we can summarize these into 12 principles that underlie modern product development methods:

1. The best model for a simple product development is a “Craftsman” model, i.e. a Chief Engineer with total project visibility and responsibility. 
2. Complex products should be decomposed into simpler pieces so that the craftsman model can be applied to each piece.
3. All activities in a product’s development must become one integrated effort.  (Otherwise, #2 cannot be implemented successfully.)
4. Trade-off within single disciplines must be subordinated to trade-offs across disciplines. (Necessary to achieve a “balanced” design.)
5. Authority must be shared among members of a collaborative, multi-disciplined team.
6. Product complexity will continue to increase, leading to the need for more engineering specialization.  (And the need for better systems engineering tools)
7. The complexity of system engineering tools should be matched to the complexity of the product
8. Continuous Process Improvement of product design methods is essential to compete successfully in a global market.
9. A competitive advantage is realized from technology and tools that provide all team members complete visibility of evolving designs, support in identifying and resolving conflicts, and the ability to equally influence decisions.
10. Modern methods are essential to shorting the time to prevent design errors; rather than to find and fix design errors, and thereby facilitate achieving minimum product development cost and schedule.
11. Functional managers must collaborate, share responsibility in measuring team performance, and foster unity of purpose within and among teams.
12. Product development schedules must account for resource contentions within the team and among teams.

The reason the Craftsman model is the best for simple products or simple portions of complex products is that all the information necessary to guide the design is available in the mind of the experienced leader or chief engineer. This is best because it reduces information latency to an absolute minimum. If information latency is minimized then the conditions for minimizing cost and schedule are in place. This means that cost and schedule will be minimized assuming the other principles are also fulfilled. (The principles could be summarized in a shorter list if the principle of minimizing information latency is invoked. However, decomposing this fundamental principle into subordinate principles makes it easier for systems engineers and product development managers to see how the principle should be implemented on their projects.)

The second principle derives from the first and tells us part of how a product development team should be organized to minimize information latency. It says to decompose the product into pieces (subsystems, assemblies, etc.) to the point that a single lead engineer can be knowledgeable enough to guide the development of the piece. This lead engineer must be supported by the needed specialty engineers and must work with other team leaders to achieve a balanced design but the individual should be capable of being responsible for all design decisions on the piece assigned. How all these small teams are organized into an overall integrated team is the subject of principle 3 and the core organizational issue of IPD.

Principle 4 says that one of the responsibilities of systems engineering is to manage the tradeoffs between different disciplines (and teams) so that a balanced design is achieved. For example, compromises are often needed between electrical design and thermal design or between mechanical design and optical design. If the systems engineers allow one discipline to dominate then that discipline will make their portion of the design optimum at the expense of other disciplines; resulting in an unbalanced design which is usually not robust to the variability of use. Principle 5 is a necessary condition for successfully implementing principle 4.

Principles 6 should be self-evident and principles 7 and 8 follow from 6. Principle 9 is derived from examining the question of how we achieve the benefits of the craftsman model for the development of modern complex products with many engineering specialties. For a number of years I used this principle in training systems engineers and had to admit that I did not know how to achieve the goals listed in this principle. New methods emerged in the late 1990s that now enable teams to achieve the goals of principle 9 and these new methods are addressed in Part II of this training material.

Principle 10 says that teams must use methods like peer reviews, progressive freeze, quality function deployment (QFD) and risk management to achieve minimum cost and schedule. This list is meant to be illustrative and is definitely not a complete list of modern methods and communication tools needed for effective systems engineering and product development. None of these methods is difficult but teams must exhibit good discipline to maintain effective use of these tools and inexperienced managers sometimes fail to maintain the necessary discipline.

Principles 11 and 12 are “housekeeping” principles and perhaps could be left off this list but they are added as reminders.

Exercises

Before proceeding to the next series of posts take a few minutes and consider the following questions:

1. Review the product development processes in your organization and rate them against the list of 12 principles stated above on a scale of 1 to 5, with 5 being full satisfaction of the principle. If your organization achieves a score of 50 or above it’s likely that it’s competitive with most of its competitors. If the score is below 50 then there is work to do even before trying to implement the 21^st century methods that will be introduced later.

2. Describe the end to end product development process in simple terms your grandmother could understand (assuming she is not a systems engineer) if she asked “what are the steps in product development”?

Systems Engineering for Defense Acquisition

This guest article by Mike Gangl explains how Government acquisition agencies use modern systems engineering to define new systems. If you are not familiar with some of the DoDAF terminology later articles will explain concepts like Operational Views in more  detail.

Whereas systems engineering is needed to develop any new system or improve on existing products, there are unique activities and nomenclature for those engineers who are supporting US Department of Defense (DoD) acquisition programs. DoD has recognized that the systems they procure are much too complicated to not address quality systems engineering practices. Additionally, if these procured systems do not perform as required or fail in operation, then the consequences may be severe including failed US policies or even injury or death to our military men and women. Therefore, it is important that engineers and program managers who are working on government projects understand the system engineering processes defined by the DoD and how these relate to their own product development SE processes.

The standard by which the DoD acquires new systems, from planes to ships to radios and beyond, is Department of Defense Instruction (DoDI) 5000.02, Operation of the Defense Acquisition System. The latest version is dated December 8, 2008 and a copy can be found at http://www.dtic.mil/whs/directives/corres/pdf/500002p.pdf. Figure 1 of the “5000” process shows the primary stages of the acquisition cycle, which include pre-system acquisition, system acquisition and sustainment. The DoD acquisition community has statutory and regulatory requirements to follow this process to procure new military systems. But there are two important exceptions.

The first exception is for research and development. Government organizations such as the Defense Advanced Research Projects Agency (DARPA) and the military laboratories issue research and technology development contracts to other government agencies and industry contractors. These contracts do not follow the 5000 process. Typically, the systems engineers will receive a Statement of Objectives (SOO) and perhaps a set of target performance requirements. In some cases, such as DARPA with their go-no go criteria, further funds are predicated on achieved performance. This is good since no program manager or systems engineer should sign up to meet hard, budget linked requirements for technologies that are not yet demonstrated. Of course, companies are frequently tempted to do so to win the contract. So it is important that the engineers, even on these technology development projects, follow some form of a systems engineering process and ensure all stakeholders understand risks and mitigation tasks. A company’s profit and reputation depend on it.

The second exception is a more recently popular acquisition approach called Quick Reaction Capability, or QRC. For these types of contracts, the system developer is provided with a set of requirements the military need to satisfy to field an operational capability. A QRC is typically justified to either demonstrate the utility of a new technology or mission, or to satisfy an immediate need of the warfighter. This is especially important in times of war. The largest, most recent example is fielding technologies to defeat improvised explosive devices (IEDs). With a QRC program, the government elects to forgo the 5000 process and have the contractor build and field the equipment on a best effort basis.

Of course, the degree to which the requirements are met still have a significant impact on whether the customer is satisfied. Here, it is extremely important that the engineers maintain some level of systems engineering discipline in a highly accelerated schedule. Managing performance and expectations are even more critical when you are working “under the gun.” A big issue for many DoD acquisition programs in today’s environment is having the Pentagon leverage a 5000 process while imposing a QRC schedule. Everyone wants the latest and best capability. And in time of war, this is amplified. These competing requirements, full acquisition process vs. schedule, are not easily solved and will require continued systems improvements to the acquisition process.

Back on the subject of the 5000 process, it is important to point out some of the key systems engineering products the government is required to produce and how they relate to engineers and their programs. This article does not cover the whole DoDI 5000.02 process since that is a separate, extensive topic. Training can be found through the Defense Acquisition University (www.dau.mil).  Typically, this training is only necessary for government systems engineers. There are three important items for engineers who work on government contracts to develop systems.

The first is the flow of requirements. It is important that a contractor systems engineer understand the way the program requirements have flowed down through the government process. For a typical military acquisition program, the primary requirements are captured in a Capability Development Document (CDD). The CDD contains the government agency’s Key Performance Parameters (KPPs), Key System Attributes (KSAs) and any additional attributes they believe are necessary to have the system satisfy their objectives. The CDD is usually worded in language from the user community rather than from technical personnel. The government organization that is responsible for the acquisition then must procure a system that satisfies these KPPs and KSAs. The systems engineers of the government acquisition organization must translate these CDD requirements into technical and operational requirements. These are documented in a System Requirements Document (SRD). Many government systems engineers now use software tools such as DOORS™ to track the linkage of the CDD to the SRD. Typically, the government may release either a top-level SRD or a complete SRD. The difference is the amount of engineering maturation that occurred to derive the SRD requirements. If the agency doesn’t have all the expertise and time at their disposal they may elect to go with a top-level SRD and work with the contractor to mature the requirements. Prior to entering the Engineering and Manufacturing Development phase of the program, the SRD will be worked into a final System Specification (sometimes called a Weapon Systems Spec, or WSS). The WSS is intended to resolve all To Be Determined (TBDs), To Be Reviewed (TBRs), and no longer contain Threshold (T) and Objective (O) requirements. It is expected that the WSS contains the specific requirements that the government and contractor will comply with during fabrication and test.

The second important DoDI 5000.02 document to understand is the Systems Engineering Plan (SEP). Like Systems Engineering Management Plans (SEMPs) that many contractor companies create, the SEP describes the engineering processes, tools, plans and schedules as determined by the government acquisition engineers. The SEP may be reviewed as high as the Pentagon, depending on the program’s acquisition category. It is considered a living document that changes as the program matures. It takes on different information as the program progresses through development maturity. Although the government continues to own and maintain the SEP they expect the contractor’s program management and engineers to not only contribute to the maintenance of the document but to synchronize any of their own SE processes and plans with it as well. It should be noted that the SEP must be updated and provided at key milestones throughout the acquisition process.

The third important item to reference is the DoD Architecture Framework (DoDAF). This is a series of pictorial and graphical representations of the system being developed. It can be thought of as the documentation of the functional and physical architectures. The top level diagram of the DoDAF is the Operational View -1 (OV-1). This is typically a concept type picture that shows how the system may be operated. Essential elements are shown in the OV-1 along with external elements that the system is expected to interface with. There are additional Operational View documents to further describe these system and external elements and how they are intended to operate.

Additionally, the DoDAF has other diagrams and documents under the major categories of Systems and Services View (SV-x) and Technical Standards View (TV-x). The SV articles should be closely watched since it typically contains specifics on interfaces to external entities and is used to derive Interface Control Documents. Note: there is also a higher level All View (AV) but systems engineers may not find those as beneficial.

The DoDAF is started by the government operational agency to denote what the system is and how they intend to use it. Their most important contribution is the Operational Views. After the government acquisition agency begins their program they will most likely take over the DoDAF and work out the details with the contractor(s) and external entities that include users and interfaces. They may even elect to have the contractor take over the maintenance of the DoDAF, but the government retains responsibility. There are several tools for developing a DoDAF including IBM’s Rational System Architect^©. Vitech’s CORE^© software tool allows the engineer to capture functional and physical architectures in traditional systems engineering methods and has a DoDAF output it can generate. As a minimum a contractor’s system engineers are expected to understand and work with a government generated DoDAF document for their program. They may also be involved with generating and maintaining the DoDAF at some point in the program. It is important to learn and understand the various aspects of this visualization method.

In summary, for the engineer who is working on government acquisition programs, there are specific rules and requirements he/she must follow to ensure compliance with the DoDI 5000.02 development process. The process and documents the government requires are in general good systems engineering practices. The biggest challenge to the systems engineer on a government program is to follow the right systems processes under very challenging schedules. In this aspect, working government programs is no different than commercial.

Evolution of Engineering Methods II

Introduction of Systems Engineering - Following WW II products like cars and airplanes became more complex and the chief engineers could no longer understand everything necessary to achieve a balanced design. This lead to the introduction of specialists in the design of various subsystems or analytical specialties like stress analysis or aerodynamics. For example instead of just mechanical engineers specialists in structural analysis and thermal analysis developed to support the designers. Soon it became impossible for the chief engineer to understand how the engineering data from all the various specialists impacted the overall design. That is when systems engineering emerged and a team of systems engineers replaced the chief designer. It is easy to see that as more and more specialists were needed the engineering design teams grew larger and larger. The large engineering teams of specialists and systems engineers developed some fantastic products such as the Boeing 747, the Space Shuttle and supersonic jet fighter planes.

It became difficult or impossible to co-locate the large teams and the communications needed to keep the systems engineers and the specialists teams current became complex and slow compared to the previous methods. As a result information latency grew along with the complexity of the products and the size of the engineering teams needed to develop the products. This lead to longer and longer development cycle times. The design process became a sequential process with periodic design reviews to evaluate status and design integrity. This evolution took place roughly between 1950 and 1980 and enabled very complex products to be developed. However, the product development cycles were often years long and exhibited undesirable cost and schedule overruns. In addition product quality was sometimes lacking. Examination of this process reveals four fundamental flaws:

1.      Too much time and money passes before design errors are found at design reviews

2.      Integration of knowledge required for product development is greatly complicated by the separation of specialists into functional groups

3.      There are attempts to specify cost, schedule and quality; however, only two are independent.

4.      Products often reach manufacturing before manufacturing processes are fully developed.

Introduction of Concurrent Engineering - New methods emerged in the 1980s and 1990s to address the flaws in the sequential process. These new methods emphasized concurrence. Manufacturing and test processes are developed concurrently with the product design. Concurrent systems engineering and design engineering replaces the sequential development of specifications and design. Concurrency is facilitated by early involvement of manufacturing, reliability, procurement, vendors etc. in the design process. The new methods emphasize preventing problems rather than fixing problems by incorporating verification and validation at each step.

The IEEE Std 1220-1998 document “IEEE Standard for Application and Management of the Systems Engineering Process” defines concurrent engineering as “The simultaneous engineering of products and life cycle processes to ensure usability, producibility, and supportability, and to control life cycle and total ownership costs.” Concurrent engineering is sometimes called integrated product development (IPD) or integrated product and process development (IPPD). Here the IEEE definition of concurrent engineering is used for the product design process and IPD for the way the product development personnel are organized to conduct concurrent engineering. There are no universal agreements for these definitions, or other systems engineering nomenclature, so the reader is again cautioned to be careful in interpreting systems engineering terms from different sources.

Accompanying the development of concurrent engineering in the 1980s and 1990s were techniques for improving product quality. Two such techniques imported from Japan are Quality Functional Deployment (QFD) and Taguchi Design of Experiments. The term robust design emerged to describe engineering methodologies using these quality improvement techniques. Three excellent books on these subjects are:

“Total Quality Development-A Step-By-Step Guide to World-Class Concurrent Engineering” by Don Clausing, ASME Press, 1994

“Quality Engineering Using Robust Design” by Madhav Phadke, PTR Prentice Hall, 1989.

“Strategic Design: A Guide to Managing Concurrent Engineering” by Bart Huthwaite, 1994

Further Improvements in Design Methods - Engineering is inherently an iterative process due to the fact that engineers, just like other workers, make mistakes in their work. Engineering work involves making hundreds of decisions in each task and often involves complex analysis. It is almost impossible to do such work without making some mistakes on the first pass. A result of this fact is that design quality and design cost are linked by the number of design iterations performed. This is shown schematically in Figure 1 for a product of some specific complexity being developed with specific methods and tools.  If a design of quality q is desired then n iterations are needed and the cost will be c for the given set of design tools and methodologies. Notice that the schedule cannot be specified together with specifying cost and quality. If a certain schedule is required then either the cost or the quality can be specified, but not both. All three are not independent variables.

Also note that this simple diagram shows that if an organization wishes to lower costs, or shorten the design cycle, for a given quality it is necessary to introduce new tools, new methods or both. A major factor in determining the cost, quality and schedule relationships is whether the design team uses practices that prevent design problems rather than find and then fix problems. It is much cheaper and faster to prevent problems than it is to find and fix the problems. Two methodologies introduced to facilitate preventing problems rather than fixing problems are peer reviews and spiral development.

Peer Reviews - Rather than depend on design reviews to find problems peer reviews are held as soon as an individual or small team completes a task. Self-checks catch most mistakes but the best way to find errors after performing self-checks is for the engineer to review the work in detail with highly experienced peer engineers. Experienced peers provide an independent and often different experience background that helps reveal errors.

Catching errors at peer reviews allows the errors to be corrected before the results of the work are incorporated in following tasks. Thus little rework is involved in fixing errors found during peer reviews. In contrast errors found at periodic design reviews involve considerable rework because often the erroneous work has been incorporated in several following tasks that must also be reworked. It is this extensive rework due to errors found at design reviews on complex product developments that contributes to cost and schedule overruns.

Figure 1 Design quality is linked to design cost by the number of design iterations performed by relationships that are dependent on the product complexity and the engineering methods used.

If teams are disciplined in holding peer reviews then the design reviews can become more of a status and decision gate review to communicate to managers and customers the state of the design and to check that all required actions are complete per a design review checklist. Further, if any reviewers wish to go into detail on some design point the documentation engineers have previously used in the peer reviews serve for more detailed discussions. This reduces the time and costs involved in preparing for design reviews.

Spiral Development - Instead of designing the ultimately desired and often highly complex system in one step spiral development sets limited objectives for the first development effort, i.e., the first spiral. Lessons learned from the first spiral are then incorporated in the second spiral. Just like peer reviews spiral development recognizes the inherent iterative nature of product design engineering. The nature of spiral development can be understood from the diagram in Figure 1. A highly complex product would have a diagram with a very steep curve relating design iterations to cost. By developing a lower complexity product in the first spiral the relationship is less steep; that is the cost for a given number of iterations is lower. Similarly, the quality is higher for a given number of iterations for the lower complexity product. Thus the quality of the first spiral can be adequate for lower cost than for a more complex design. The same holds for later spirals. The lessons learned on any spiral are applied to later spirals, resulting in more favorable relationships between cost, schedule and quality than if the work is done in one spiral.

Progressive Freeze - Progressive freeze of design decisions is another technique introduced to manage schedule during the development of complex products. It involves freezing a design detail as soon as it becomes likely that further work won’t change it and before the next major design review. This enables more detailed design work to begin ahead of the design review intended to gate such detailed design. This provides schedule and staffing flexibility. More will be discussed about peer reviews and progressive freeze in later posts.

Concurrent engineering, IPD or IPPD, spiral development, and robust design represent the typical engineering processes for product development in use at the turn of the 21^st century and are still widely used. However, the engineering design process has not stopped evolving to match the ever increasing complexity of products. It is the newer methods that are the intended focus of this material. But before introducing these newer methods it is worthwhile to stop and review some fundamentals, which are the subject of the next post.

Engineering Methods for Product Development-I

Evolution of Systems Engineering Methods - Engineering design methods evolved as the complexity of products increased due to the opportunities for more complex products that arose as new technologies and production methods became available. The developments of electronics in the mid-20th century and computers in the late 20th century were major drivers for increasing product complexity and causing the need for more and more sophisticated engineering design methodologies. The concurrent growth of more efficient production methodologies enabled the more complex products to be affordable. A brief review of this history and some of the noted chief engineers is helpful in understanding the modern methodologies. (Today we would call these individuals system engineers but that term didn't appear until the late 1950s or early 1960s.)

Chief Engineer Era - Before the middle of the 20^th century products were relatively simple and large design margins were often used, which facilitated simple engineering methodologies. The principle engineering method was a chief engineer plus some assistants. This model is called the “craftsman” model because it’s like the methods an individual craftsman uses in developing a new product. Let's look at one example. Gordon M. Buehrig was a noted automobile designer from the 1930s to the 1950s. In 1935 the Cord Automobile Company was in trouble and needed a new design. Buehrig and his team developed the Cord 810, shown in Figure 2-1, in about six months, if my memory is correct.

                       

Figure 2-1The innovative Cord 810 developed by chief designer Gordon Buehrig and his small team in just a few months in 1935. Photo Courtesy of Auburn Cord Duesenberg Automobile Museum, Auburn, Indiana

The Cord 810 was the first American front-wheel drive car with independent front suspension. The design had numerous innovations including hidden door hinges; rear hinged hood, disappearing headlights, concealed fuel filler door, semi-automatic transmission in front of the engine, variable-speed windshield wipers and a radio as a standard feature. The Cord 810 was a sensation at the New York Automobile Show in November of 1935 with Cord having rushed to build the 100 cars needed to qualify for entry. This rapid design and initial production temporarily saved the company. The design was recognized for its innovation by the New York City Museum of Modern Art in 1951.

Can you imagine a modern car company designing and producing 100 new cars with many new and even radical design innovations in about six months? Visiting Buehrig and his team's offices preserved in the Cord Museum provides some clues to how it was accomplished. The small team occupied a room with just enough space for the designers and their drafting boards. Buehrig's office was adjacent with only a glass window and doorway separating the two spaces. He was able to see every team member with a single glance and he could be at the side of anyone within a few seconds. This co-location enabled Buehrig to see all of the design information almost instantly and to ask questions and get answers almost instantly. Thus within the design team there was almost no information latency, that is the time between when information is available and when it gets to the individuals that need it for the next steps in their work.

The team was located in the same building as the top management of Cord and the factory was next to the office space and reachable within a minute. If Buehrig's team needed information about production capabilities or a decision from top management they could get the answers needed within minutes or a few hours at most. Of course I don’t know how it really worked in practice but the physical space where this team worked was organized for minimizing information latency and this is the lesson we should take from this story.

A second important contributing factor is the fact that cars were much simpler in the 1930s and a chief designer with Buehrig's talent could understand all the important design criteria and the merits of the design options available to his team, as well as the production capabilities of the factory. This enabled the team to be limited to a few designer/draftsmen and facilitated the speed of information flow. Today’s automobiles are too complex to be developed with such small teams.

Was the rapid design of the Cord 810 an anomaly? No, I could recite many such cases, particularly during WW II and immediately afterward. Many of my stories are about airplane developments since I worked in the aerospace industry. Most people have heard of Lockheed's famous chief designer Kelly Johnson and the Skunk Works.

Kelly Johnson was involved in the development of about 20 airplanes, including the famous P-38, U-2 and SR-71. Skunk Works has become the buzz word for organizations and facilities intended for rapid product development. Johnson's methods are well worth studying and applying today, although it is necessary to take into account the impact of modern computer technology on information flow. I’ll quote just one of his 14 Rules of Management here. Number 3 is “The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems).”

Alexander Kartveli of Republic Aviation is another outstanding chief designer from the 1940s and 1950s with many firsts to his credit; including the first in-flight refueling, first supersonic fighter, first internal bomb bay and first “black box” fighter. His P-47 design, one of the top three US WW II fighter planes was on the drawing board in 1940, Ordered in September of 1940, in production in early 1942 and in service in 1943.

Rather than recite more stories of famous chief engineers I will discuss some principles from a company manual that I had the opportunity to read nearly 30 years ago. I won't give the name of the company as some of the material could still be proprietary.

The company had a grand history of successful and rapid airplane developments. Someone incorporated the “lessons learned” into a manual that was both a history and a compendium of principles for rapid development. The airplane factories from WW II that I have visited had long linear production lines with shops and offices along each side and on mezzanines overlooking the production lines. Thus for a development project where the goal was to build the first flight model it was possible to locate the team in a common space within sight of the area where the plane was being assembled. I'll recite only two of the lessons learned from the manual I read. One was that the engineering team was to be located in sight of the plane and where they could get up and in a few seconds inspect the hardware they were developing. Second, the team was to be co-located in a high walled space so that the progress of each sub-team could be plotted on a large schedule chart and posted high on a wall where everyone could see the progress of each team.

Again we see the attention paid to minimizing information latency. An engineer that had questions about some part of the plane could quickly look at the hardware, if that would yield the answer. Everyone could see each other and if an engineer needed information from another engineer or even from another team it took only seconds to walk to the work space of the engineer with the answers. Posting the progress of each design team so that it was visible to all the teams had two positive impacts. First, there was the peer pressure to not be the team that was holding up progress. Experience had shown that a team that was behind would find ways to catch up with little or no management intervention. Second, the chief designer could concentrate on technical issues rather than managing schedule issues.

From the automobile design example cited above and the principles used for rapid development of airplane designs we see that the pressure for getting products to market fast are not unique to the 21^st century. Twentieth century engineering methodologies adapted to this pressure by organizing and locating engineering teams to minimize information latency. The “craftsman” model of a chief designer plus some assistants worked well because the products were relatively simple and often large design margins were acceptable. The low complexity of the products enabled the chief designer to understand all that was necessary to achieve a balanced design that was manufacturable at acceptable cost. Thus the design process was what we now call a concurrent process; the chief designer knew the manufacturing capabilities and designed to conform to these capabilities. These conditions for product development were no longer true by the 1950s as product complexity had increased so much that engineering specialists were needed and new methods required to manage the larger engineering teams that resulted from adding the specialists. These new methods are defined in the next post.

Why Systems Engineering is Required for Commercial Product Development

This is a guest post by Martin Coe, a systems engineer with extensive experience in the development of commercial products. I extend my thanks to Martin for allowing me to share this with everyone.

Introduction- Why is systems engineering required for commercial product development?  This article answers the question by illustrating the correlation between commercial product development and the application of systems engineering.  More specifically it:

§  Defines the main business objective of commercial product development

§  Introduces a product profit model that illustrates the relationship between this objective and 5 characteristics critical to successful commercial product development 

§  Utilizes the model to illustrate how product profit can be adversely affected if these 5 critical characteristics are not optimized

§  Identifies the relationship between systems engineering and these 5 characteristics critical to successful product development

Commercial Product Development’s Main Business Objective - Regardless of the commercial product being developed or the industry it will be sold, installed or operated in all commercial product development has a common business objective.  That being to ensure each product development project earns a sufficient profit.  While the definition of sufficient may vary among companies, products and projects the constant is that no company can continue to perform product development for any length of time without earning profits from the products they develop. 

Figure 1 is an example of a model that illustrates possible product revenue generated and lifecycle costs incurred over the lifecycle of a product development project.  Since

Profit = Product revenues – Lifecycle costs

we can utilize such a model to track project profits and therefore our progress toward meeting our business objective.

Development of the actual model begins early in a project when the lifecycle costs and size/ shape of the product revenue area are estimated yielding an estimated profit; use of the model occurs during the project when these parameters are measured yielding a profit snapshot; and after product end of life (EOL) when these parameters be confidently determined to yield a final profit value.  

Figure 1 The Product Profit Model tracks life cycle costs and product revenues over the life cycle of a product.

Our focus in utilizing this model is the area under the curve which represents the Total possible product revenue (+$) generated from any product and lifecycle costs (-$) both measured throughout the product development lifecycle.  From the model note:

• At Release for Sale (RFS) the developed product is released for sale and product revenue generation begins
• At End of Life (EOL) product obsolescence/retirement is imminent and product revenue generation ends
• Lifecycle Costs are being incurred throughout the product development lifecycle (the entire length of the x-axis)

How Do We Meet This Objective? As the model illustrates meeting our profit objective means ensuring our total product revenue is maximum and that lifecycle costs incurred over the product development lifecycle are minimum.  As the number of factors affecting product revenue and lifecycle cost during product development are too numerous to manage consolidation to five critical characteristics is pertinent for our discussion.   To maximize product revenue and minimize lifecycle costs optimization of these five characteristics is imperative for any commercial product development project (tradeoffs between characteristics will be needed to optimize the highest priority characteristics for each specific project).

A brief introduction of these five characteristics within the context of product development begins to reveals how the size and shape of the product revenue curve and lifecycle cost value can be adversely affected for any project.

Meeting stakeholder needs

Every effort must be made to completely and accurately identify, define and satisfy project stakeholder needs as reflected in a comprehensive set of product requirements.  Inadequate, missing or poorly defined requirements can affect customer satisfaction (final slope) or market size (plateau).

 

Minimizing Development Time to Market (Schedule)

The time needed to develop a product from concept to release for sale (RFS).   Generally, increasing the time to market increases the lifecycle costs and shorter the revenue generation period (initial slope and less curve width).

Maximizing Product Performance

Product performance, measured from the customer/user perspective, covers many design characteristics such as reliability and quality.  Poor product performance can affect the size of customer base (plateau) or product longevity (final slope).

Minimizing Lifecycle Costs

The total product cost to the developer throughout the product development lifecycle.  Excessive lifecycle costs can affect the product market price (initial slope) and/or size of customer base (plateau) and directly impact profit margin.

Optimizing Risk

Product development risks can be cost, schedule, performance, requirements or programmatic related in nature.  Performing effective risk management throughout product development is an integral part of optimizing these critical characteristics.  Nonexistent or ineffective risk management can affect any or all aspects of the curve.

Figure 2 is an actual product revenue model with final product revenue (+$) and lifecycle costs (-$) defined for a product development project that did not optimize the five characteristics above.  Notice the size and shape of the product revenue curve and its relation to lifecycle cost value.  This product development situation is all too common when these five characteristics are not optimized or worse blatantly ignored during product development.  Ironically the fate of many product profit margins is doomed early in the project (often long before RFS) due to the lack of attention these critical characteristics get during product development.  It is obvious from the model this project does not realize a profit margin and therefore does not meet our business objective.

Figure 2 The Product Profit Model for a product with non-optimized characteristics

Systems Engineering is Directly Related to The Critical Five Characteristics - Any optimization of the five characteristics involves the application of systems engineering methods to product development projects.  If any one of these characteristics is measured, controlled, or managed during product development or special tasks/functions relating to these areas are performed then systems engineering methods are being applied to product development.  The table below clarifies how systems engineering is related to these critical characteristics with a brief list of systems engineering functions.  This is why systems engineering is required for successful development of commercial products.

Critical Characteristic	Related Systems Engineering Function
Meeting stakeholder needs	Voice of the customer, stakeholder analysis, requirements engineering, design verification, design validation
Minimizing schedule	Resource management, project schedule development, project scoping, work breakdown structures, earned value analysis, quantitative analysis
Maximizing product performance	Design for reliability/quality, requirements engineering, system integration, system architecting, software engineering, system analysis
Minimizing lifecycle costs	Lifecycle cost analysis, earned value analysis, business case analysis, engineering accounting
Optimizing risk	Risk management, root cause analysis, process validation, team development, six sigma processes

References

Coe, Martin, “Realizing maximum Product Revenue Utilizing a Product Revenue Model”; 18^th International Conference on Systems Engineering, Las Vegas, NV, August 2005