Abstract. This introductory tutorial provides an overview of Concurrent
Engineering and especially System Engineering because that is the
discipline which led to the synthesis of processes described in the primary
tutorial, Automating FDA QSR Design Controls Compliance making up the Decision
Support Incorporating Documented Evaluations (DSIDE™) process described
in another tutorial (The IPPT supporting Decision Process) in this set.
As a general rule for organizations, existing processes will not all operate
with integrated interaction. That likely is the result of the normal tendency
to as quickly as possible fix each inevitable problem when and where it surfaced,
then call it an improvement and get back to doing important work. Thus, it is
unlikely that inventors of the patches have applied the "systems approach" to
their design. The following descriptions are intended to show how to avoid the
typical "make it now and fix it later" syndrome with early definition of
requirements and use of the recommended decision making process.
Today's commercial product and services problems are becoming larger in scale,
interdisciplinary, and increasingly will rely on Information Technology for
decision making. The complexity of many products and their embedded computer
programs also is rising exponentially, as evidenced by the environmental
regulation and competition driven changes to ordinary(?) passenger automobiles
in the last few decades. This general situation and the more rigorous business
environment requires development of methods for management of complexity in
the commercial area. The FDA Quality System Regulation adds another layer of
issues to address for medical devices development. In a nutshell, this means
using conceptual models as well as Concurrent Engineering "in the large" or
Integrated Product/Process Teams that include distinctly separate corporations
or companies that must act in concert for development of the system at issue.
Fortunately, the U.S. military faced similar problems in the 1950s, so most of
the necessary processes were developed and extensively refined during the
intervening decades. An initial bias, however, is that government sponsored
processes will be inefficient and require too much documentation and formal
review for application in the commercial realm. As will be shown, this can be
overcome by processes tailoring that emphasizes the desired essence and reduces
the boilerplate; by system engineering the processes.
Mostly as a public service, based on the likely ratio of interested visitors to
potential customers and/or clients, this free introductory tutorial covers the
subject sufficiently to partially enable your evaluation of the value of
most available related products and services within your planned approach to
goals fulfillment. (The word "partially" was emphasized to remind you
that knowledge of material from the complete set of tutorials listed on the
home page could be necessary to properly evaluate the ODDSCO offerings.)
At the end of this tutorial is an opportunity to pose question(s) on this subject.
Return to Home Page [Use a Return Link after
any of the listed subsections to quickly reach this option.]
A cross-functional, multi-disciplinary team that is tasked with integrated
product and/or process development is aptly labelled an Integrated Product/
Process Team in defense/aerospace industries. The IPPT can be comprised of
personnel from multiple companies in a hierarchy of responsibilities, which
is the approach used to develop a complex weapon system. With that example,
it is easy to see that Department of Defense policy has strongly encouraged
parallel product and process (IPPT type) design activities for many years.
It is less well known that the parallel product design and process development
concepts known as Concurrent Engineering (also sometimes described as
Simultaneous Engineering) are virtually identical to the classical defense
industry approach called integrated product/process development. Therefore,
the majority of the commercial world (small businesses) neither knows about
IPPT nor that they lack only minor adapting and tailoring for downscaling and
useful application to solve many of their current and upcoming problems.
Because the interrelated, logical sequencing of operations and tradeoffs among
processes and products is difficult to see in complex product projects, one
purpose of this tutorial is to revail that tailorable generic process.
Return to Table of Contents
Those familiar with Industrial Engineering could suggest that Concurrent
Engineering is merely update of the name to acknowledge encompassing the
processes beyond support of manufacturing. As a discipline, Concurrent
Engineering is to Systems Engineering as chemistry is to physics.
Critically important and sufficiently complex to involve specialists, the
one field nevertheless is contained within the larger for the majority of its
Even those who would argue for differences between Concurrent and System
Engineering should agree that the goals of both named approaches are similar
and generally overlapping. The classical approach to System Engineering is a
disciplined, orderly, top-down process for managing project risks while
defining customer requirements, translating those into performance requirements,
selecting a balanced solution to the revealed design problem, verifying that
the solution responds adequately to the problems, and validating that the
solution fulfills the original needs. In other words, because no single person
has adequate detailed knowledge or time to design a complex system, System
Engineering is orchestration of the entire product development process during
a project. However, emphasis is shifting toward the commercial concept of fast
cycle time for product development; toward the realm of Concurrent Engineering.
Concurrence means that more resources will be spent in early concept and design
stages of the development process, to avoid spending far more during rework to
make a product work as intended; to contain overrun of project cost and schedule.
Further, two-thirds of a system's Life Cycle Cost (LCC) is predetermined at
completion of preliminary design, with 80% predictable from the detailed design.
Because product design is inseparable from manufacturing and support processes,
Concurrent Engineering ensures consideration of its impact on their ultimate
costs at all decision points during development. The object is to quickly define
stable specifications by gaining both the agreement of all affected parties and
their commitment to make a conforming product.
The integrated information sharing necessary for concurrence of tasks results
in an integrated approach that facilitates application of Quality Function
Deployment (QFD). (See another tutorial in this set for discussion of
Continuous Improvement Process and Total Quality Management related issues.)
This results in a shorter project development duration to obtain the same end
result, which helps producers to meet the time-to-market needs with something
more substantial than an announcement of a later introduction date.
Total application of Concurrent Engineering requires a dedicated project team,
a "Skunk Works" approach to driving only for success. Small businesses
lack the resources to use any other approach, of course. Even in many larger
commercial companies, the problems must not be perceived as sufficiently complex
because the System Engineering process is not standard. Either it is perceived
as not cost effective because of a known association with government (with
reputation for effectiveness somewhat tarnished) or its functions and benefits
are not known to the managers and executives.
Concurrent Engineering is a relatively useful label, so few companies will
claim that they are not really interested in the improvements that are supposed
to accompany its adoption.
Many companies have found success with a core project team and matrix
organization loan of function-specific people, because fewer resource battles
must be fought with managers who would lose staff and the upper management
comfort level is higher. The team approach, if accomplished with colocation of
at least the core people, certainly assists communications.
A key to success is having experienced production engineers on the development
team, so final output can be built with minimum variability and tested with
common equipment. The robust designs reuse as much as possible and start from
scratch only when necessary to solve a new problem. On-line automatic attribute
monitoring support for real-time process correction may be designed into the
equipment. Money initially saved by leaving production people off the team is
multiplied and lost by extensive rework and missed opportunities for sales when
the first version cannot be manufactured economically without redesign.
Successful projects come from participative designs with the customers and
users requirements held paramount while engineering and project management
staff maintain a life-cycle perspective for the total product.
Return to Table of Contents
System Engineering includes management and execution of the abstract process of
problem identification and definition, system hardware and software conception,
planning and design, system integration and verification, system fielding for
use, and safe disposal at the end of system life.
The approach must be top-down, with requirements allocation to system elements
that balance life-cycle cost and effectiveness to result in a producible system.
System engineers synthesize an system design concepts, perform tradeoff analyses,
and provide hardware and software requirements to specialty designers. During
the detailed design, System Engineers check for probable requirements fulfillment,
resolve hardware and software interface issues, and verify that the product is
ready for a seamless transfer to production. The System Engineering process
involves time, in terms of project phases, and logical problem solving.
These activities are repeated to develop updates to already fielded systems that
increase performance, correct deficiencies, or lower Life Cycle Cost while
maintaining configuration control. The updates may have been foreseen as part
of a Pre-Planned Product Improvement approach to system capability growth.
Project System Engineers maintain technical integrity by establishing full
traceability of design requirements and system verification procedures to
functional performance requirements.
The process involves a profession, although the knowledge base is not as detailed
as specialty design engineering. However, because it involves design of systems
that combine hardware and software to achieve objectives, the approach and mental
perspective often are more important than the specific knowledge base. To show
its criticality, common symptoms of the failure to apply the System Engineering
approach are excessive costs, program schedule slips, and deficient performance.
Typical problems are excessive production and support costs because only design
and development was considered necessary due to optimistic schedules.
As a response to such pressure, complex systems are sometimes delivered before
integration and test of hardware and software are complete. (The schedule was
theoretically met, however, because something was shipped under
the required label. Rework to obtain a satisfactory system in the field, after
delivery to a customer, is very expensive!) Some detrimental effects are
difficult to avoid because customer needs may change and product designs must
be adapted in response. Therefore, flexibility to accommodate the inevitable
changes should be designed into System and Software Engineering processes.
Another problem is the general dissatisfaction that arises from funding System
Engineering at too low a level because then nearly all the outputs from the
process are inadequate. Managers without understanding in this area tend to
blame the individual engineers for producing inadequate documentation while
trying to fulfill impossible schedules. Front end System Engineering work is
to avoid project surprises. It is a "pay now or pay far more later" situation.
No fixed approach to System Engineering exists because a basic tenet is
goal-directed tailoring of processes and tools to scope and scale of the project
at hand. Too little process adds project risk while too much process adds cost.
Tailoring requires judgment based on experience gained during projects that
superficially resemble the current project, as well, so inconsistency is likely.
Names for the phases and procedural steps are not always kept common, which
constrains communications and efforts to baseline and measure the engineering
processes for planning improvement.
Attempts to assign performance metrics to System Engineering are extremely
difficult, moreover, because they are necessarily indirect measures
of effectiveness and because that which is measured as a performance indicator is
that which tends to be done. That is, the indicator can become the implicit
objective, supplanting the original goal.
Names are far less important than your complete understanding of the underlying
concepts, as well. Names that indicate concepts involved in the time phases of
a system's life cycle (its acquisition and utilization
Program Planning -- Determining what management for what projects
will be required to implement system and subsystems development, considering
necessity for Research and Development (R&D) and availability of inventory
Project Planning -- Determining what tasks will be required to develop an individual subsystem for operational use.
System Development -- Implementing project plan by specifying requirements, establishing concept architecture, simulation modeling, prototyping, designing, manufacturing subassemblies, integrating hardware and software into the (sub)system(s), and testing for fulfillment of the specified requirements. Principal output products from System Engineering are system specifications that translate customer needs into system functional and performance requirements, derived hardware/software requirements and general interface specifications, then the procedures for verifying them. The specialty designers produce mechanical drawings, electrical schematics, parts lists, procurement specifications, and change orders to the foregoing.
Production -- Manufacturing or purchasing the subassemblies and building systems, installing software, environmental stress screening (ESS), and acceptance testing for selloff to customer. This includes developing the necessary production facilities.
Distribution -- Delivery and installation of system for users. This includes handling, packaging, transportation, unpacking, installation, setup, and user testing.
Operations -- Application of the system. This includes installation of field changes in hardware, software, and/or operating procedures as part of corrective maintenance or enhancement updates.
Retirement -- Phase-out and removal of the system for disposal on secondary market if usable life remains or as either inert or recycleable scrap if operational value is gone.
For each of the foregoing temporal phases, the framework is relatively
standardized as a distillation of what people actually do when they develop
Names that indicate some of the concepts involved in the logical procedural
steps of the System Engineering process are:
Problem Definition -- Identifying and fully understanding the problem(s)
causing the set of symptoms sufficiently to communicate the situation clearly
to all interested parties.
Criteria Definition -- Develop objectives of solution system and criteria for measuring level of objectives satisfaction.
System Synthesis -- Propose or identify alternatives and deduce consequences of implementating each.
Alternatives Optimization -- Determine the best use of each alternative by modeling or analysis.
Decision Making -- Evaluate and rank proposed options with respect to developed criteria.
Implementation Planning -- Prepare for execution of next phase in project.
The generic processes relate to System Analysis, system development, and
system management. System development concerns requirements definition, system
design, and requirements verification (Requirements Management).
Return to Table of Contents
Considering text of this tutorial, the characteristic which overwhelms all
others is ability to apply a "holistic view," to comprehend and to
maintain the perspective of customers and users despite employer pressures to
put schedule and budget ahead of complete requirements fulfillment (quality).
Skillfully applied System Engineering keeps the program technically honest
because system functions and interfaces are recognized as the means to
accomplish the operational missions rather than the purpose for the design.
System Engineers are the top level problem solvers without parochial bias.
Broad general knowledge of non-technical disciplines within business,
management, and government helps with this.
The systems perspective includes recognition that all systems are subsystems to
a higher system and that they themselves usually contain subsystems which also
are systems from another point of view. The purpose or objectives of the system
of interest must be understood and defined within the context of its larger
system. A member of the larger system usually is the customer for the specific
system of interest. Partitioning of major systems into manageable subsystems is
a high level System Engineering task.
A System Engineer must be able to understand the general application of
technical design specialties and the "-ilities" to the system and
its subsystems. Learning therefore must be continuous, with acquisition of
information that may be useful someday as well as that of immediate concern.
System Analysis activities are often part of the necessary system design tasks.
Knowing that necessity to fulfill system objectives determines when to
convert an informational string of text into a requirement (with the
"shall" word properly employed) is a key to success.
Improper or careless assignments of non-mandatory goals as requirements can
constrain a system from optimally fulfilling its actual objectives. Therefore,
each proposed requirement must be measured for its contribution to mission
accomplishment (quantification and allocation of goals) before inclusion in a
specification. Initial functional requirements should be technology
independent, free of an implementation concept, to the maximum possible extent.
Ability to compose and to design verification of such requirements allows
system engineers to be "generic," to be relatively easily movable
from one project to another unrelated project.
Capability to work as a specialist designer often is recommended. Some think it
is essential for developing expertise regarding the system, because that is
how they have come to their systems work. Some academics express the belief
(surprise, surprise) that a graduate degree is necessary for the advanced
knowledge and experience that will support System Engineering effectiveness.
Contrarily, approach and attitude are of greatest importance. Specialty
knowledge, the technical expertise, is not as essential as the systemic or
global view combined with ability to understand specific system concepts and
to communicate with the design specialists. It depends on the domain of the
primary assignment, which can be related to development of the system
architecture, system development, system modeling and optimization, system
life cycle support, or process improvement. Ability to understand the results
expected from the specialty designers and possible methods for their allocated
requirements verification is adequate. It is understanding what the requirement
means and why it exists, so design options can be evaluated for feasibility.
In-depth, elitist coursework may be intellectually challenging (and thereby
satisfying for those of academic orientation) but of little practical worth
for doing the actual System Engineering process tasks. Ex-military technicians
with some hands-on exposure to complex systems appreciate typical System
Engineering problems without academic training and can support such work or
train to do it. Technical writers and others who have had to work extensively
with design specialists and system engineers can advance from a
paraprofessional level with surprising ease when their interests and abilities
coincide. Deficiency at the concept design architecture development level may
linger longest, but even that is surmountable when teams rather than gurus are
The depth of specialty design understanding for accomplishing System
Engineering process tasks depends on the purpose of the system and knowledge
of other persons assigned to the system design team. When staffing selections
for a system team, one object of the project management should be to provide
maximum coverage of specialties.
The nature of product System Engineering work on projects of substantial
complexity provides good ongoing education to its practitioners, even when
you always is assigned the same job at its inception. You must give help
where you have knowledge and get help where your knowledge is deficient.
On the one hand your expertise grows, while on the other hand your basic
As a generalist, knowledge of all skills but your specialty will be shallow,
putting you at higher risk for layoff during recessions than are the pure
design specialists unless company management realizes that the generalist
knowledge is critical for project teams success.
People skills and awareness of the company culture is a first requirement. As
the Chief Engineer for a project, and often at lower levels, communication
and arbitration skills for compromise negotiation may be more important than
your technical competence in any design specialty. You must smooth conflicts
over scheduling, project priorities, staffing assignments, technical opinions,
and higher level imposed managerial procedures. The standard office politics
and personalities issues rise in importance when tightly integrated, self-
directed project teams are employed. Your basic job is to foster cooperative
interdisciplinary system design solutions. For this, you need not be an expert
in any specialty, but must listen carefully and be able to understand them all
so your top level perspective functional models communicate to all disciplines
and to non-technical persons associated with the project.
Lack of knowledge in critical areas can work to the advantage of the
system because you don't "know" what can't be done. (Specialty
designers may use the spur of a suggested impossibility to remember that new
technology has removed the validity of a long standing "prohibition.".)
Understanding of and ability to use some of the Knowledge Support Subsystem
tools is recommended but also not critical for success. A comprehension of
probability and statistical analysis tools from that group is more important.
Return to Table of Contents
One major source of knowledge transfer and direction in System Engineering by
experienced people is the relatively new International Council on Systems
Engineering (INCOSE). Its charter is to:
System Engineering seems to be the last engineering discipline to profit from
extensive automation. That is not unexpected, due to processing power required
for the necessary Knowledge Support. The main lack is full integration of the
overall software environment with all the necessary tools. The generally
available tools address important but small, constrained subprocesses within
the overall process. Some are based on the requirements management paradigm,
including traceability from source to design and verification specifications.
Some provide a thorough simulation modeling environment based on the functional
requirements for system behavioral analysis. Using some such tools imposes the
specific methodology of their designers invention which may not be suitable for
the project at hand.
Manual process applications such as traditional Requirements Management, even
where supported with relational database and spreadsheet tools, often are
excessively simplified. Analyses lack access to key information so decisions
are made in ignorance of potential impact on system performance. To address
this problem, commercial attempts to develop system level rapid prototyping
support include "executable" functional behavior diagrams, which
automatically simulate the system with its description, are ongoing but
incomplete. The system hierarchy organizational concept is central to this
objective. The notation should support data flows, exception processing, and
performance measurement. Eventually, the entire process will be suitably
automated with Expert System assistance.
Return to Table of Contents
The greatest benefit to smaller businesses is that the System Engineering
process can be tailored for employment by any organization to perform any task
of significance. It is the structured approach that is most helpful, even when
all the bells and whistles required by the military applications are left off.
Even so, there are times when the commercial business will benefit from a
formalized requirements definition:
If you have any questions on this tutorial subject, please contact the author as
listed below. A response will occur and entries in the FAQs section may result.
Return to Table of Contents
This tutorial is presented by:
Tutorial Author: email@example.com
Other subjects: firstname.lastname@example.org