ODDSCO's IPPT, Concurrent and System Engineering Introductory Tutorial

An introductory tutorial about an Integrated Product/Process Team (IPPT) approach or Concurrent Engineering (CE) and Systems Engineering (SE), from the practitioner's perspective.

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.]

Integrated Product/Process Team[ing] (IPPT)

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

Concurrent Engineering

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 application.

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 Methodology

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 periods) are:

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 items.
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 systems.

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

What Makes a "Good" System Engineer?

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 involved.

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 knowledge increases.

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

System Engineering Support Tools

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:

  1. Foster the definition, understanding and practice of world class System Engineering in industry, academia, and government.
  2. Provide a focal point for dissemination of System Engineering knowledge.
  3. Promote collaboration in System Engineering education and research.
  4. Assure the existence of professional standards for integrity in the practice of System Engineering.

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

System Engineering in Small Businesses

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:

  1. Whenever Safety and Health issues are involved with your output.
  2. When product complexity or interaction with existing or other supplier systems is high.
  3. When the customer needs are uncertain or unstable.
  4. When any of project risk aspects will be high, adding risk management to the required activities.
  5. When project duration exceeds six to eight months, increasing likelihood of key personnel shifts.
  6. When you want to baseline your existing processes and gain a more communicable understanding of the project and product for comparison with competitor's entries.
  7. When you want to show proof of capability cited when proposing development of another product as a subcontractor.
    If item 1 is applicable, formality of hardware and software interface specifications is a good idea, especially when you are trying to apply Concurrent Engineering.

    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:

    The ODDSCO Co. Logo<br> (A stylized duck).<br>

    Optants Documented Decision Support Co.
    297 Casitas Bulevar
    Los Gatos, CA 95032-1119
    (408) 379-6448 FAX: (Same, by Arrangement)


    Tutorial Author: jonesjh@optants.com
    Other subjects: consult@optants.com