AFMC Integrated Product Development

BEST PRACTICE

Excerpted from the report, ASDTR905014, “Results of the Aeronautical System Division Critical Process Team on Integrated Product Development”, November 1990. Since this document was published in 1990, references to current acquisition reform initiatives and DoD 5000 policy themes are emphasized in italics. PL Note: The excerpts show a Wright Laboratories focus, but are generally applicable to the Improved Space Computer Program.

EXECUTIVE SUMMARY

Integrated Product Development (IPD) (read Integrated Product and Process Development) is an efficient process of bringing a product from user’s needs to filed operation. The basic principle is to iterate and integrate the design of a product and the design of its manufacturing, operation, support, and training processes with specific focus on achieving lowcost development (read affordability), production, operations and support within the shortest schedule while achieving robust quality of products and services. The IPD approach requires the simultaneous and integrated development and qualification of all the elements of a total system contrasted to a sequential development process. It focuses on establishing Integrated Product Teams (IPTs) at the “doing level” to ensure all functional and special interest groups are “integral contributors” rather than “monitors” in the process. For IPD to be successful, the development process must change what people do, and when they do it, so that they actively participate by creating products that incrementally define the total system. IPD increases the focus on, and “ownership” of, the products and processes, improves horizontal communications, establishes clear lines of responsibility, delegates authority, establishes clear interfaces with industry, and changes the acquisition process expectations so that the activities and success criteria are based on the total product including its manufacturing, support, and training.

BACKGROUND

The benefits of IPD have been convincingly demonstrated in many commercial applications. Aerospace industry has also been changing and significant progress has already been demonstrated. Since implementation of IPD will take place principally in industry, the best mechanisms for helping industry are to remove the inhibitors in the acquisition process and to provide leadership in accelerating the adoption and advancement of IPD practices and methodologies. In fact, the aerospace industry has stated that the government must change the acquisition process for them to be totally successful.

Recognizing the significance of the concept, former ASD Commander, Lt Gen Loh, established a Critical Process Team (CPT) on IPD to integrate the IPD concepts into the acquisition process. The CPT was tasked to define and recommend: (1) integrated development and integrated management processes for the concurrent design and verification of products and their manufacturing and support processes; (2) a process for improving technology transition as it relates to IPD; and (3) incentives for industry to embrace IPD.

INTRODUCTION

IPD brings people representing different functions together at the beginning of development to work as equals in a climate of trust and ownership to incrementally and simultaneously refine the definition of the total product including its manufacturing, training, and support capabilities. This process is governed by an enhanced product definition and control effort and an integrated product and process development effort. Each of these enabling efforts are supported by enabling computer technologies that permit the use of digital data, shared common data bases, 3Dsolid modeling, computerized mockup equivalents (read Modeling and Simulation), etc., to reduce design and fabrication times, promote product and process optimization, and improve the quality of product definition, manufacturing, training, and support data. This is inherently a more efficient and responsive process.

The IPD process will facilitate the management of change and help IPTs solve the customers’ needs by permitting requirements, technologies, and product development to coevolve. IPD can help customers understand the subtleties of their needs and the limits of technology by making product development a problemsolving process among multiple customers and multiple functional experts working as a team.

Endusers involvement throughout the process is critical. As the more detailed definition of the requirements evolve to the design level, interpretation and selection of design specifics among alternatives is of paramount importance to the end users’ eventual satisfaction. Thus, the IPT must be availed to the user’s desire of choice and priority of operation throughout the development cycle Without the user’s involvement, the delivered system may not be fully useful or the user may feel a lack of ownership. IPD can help resolve conflicts in meeting the needs of a wide variety of customers (operator, maintainer, supporter, trainer, etc.).

Keys to success for most development projects lie in the recognition that requirements, technology, and expertise coevolve and in the ability to balance and manage issues in a changing environment. The challenge is to meet the customers’ needs for a wide range of customers who have different or conflicting requirements. These needs must be met within budget (read CAIV) and schedule constraints, and include planning for anticipated growth through flexible product designs (read Open System Approach), manufacturing processes, and support processes.

PRODUCT DEFINITION AND CONTROL

Systems Engineering in the Acquisition Process. Systems engineering is the function that controls the evolution of an integrated and optimally balanced system to satisfy customer needs and to provide data and products required to support acquisition management decisions. Systems engineering encompasses the complete, integrated technical effort to define, design, produce, verify, and deploy a life cycle optimized system. Systems engineering controls the entire technical effort to develop the total product including its manufacturing, training, and support. It addresses all “critical” characteristics of the product and its associated manufacturing, training, and support in order to achieve product and process optimization. This is true from the very beginning of a weapon system development or modification, therefore, even the very early systems engineering efforts include all elements of the IPT expertise, e.g., cost, design, manufacturing, support, test, etc. All members of the IPT work from a common baseline and trade studies address all the critical product/process characteristics of the area being studied.

The major products of this early systems engineering effort are integrated requirements, integrated specifications (read performancebased specifications), interface control documents, integrated schedules (read Integrated Master Plan and SchedulelMP/IMS), and technical budgets. These products establish the “boundaries” for the efforts of “product” oriented IPTs who will continue to use the systems engineering process to accomplish the integrated product and process development activities. All members of the IPT must embrace the systems engineering approach.

Translating User Needs and Establishing Integrated Requirements. A major responsibility of systems engineering is to capture the “voice of the customer” in terms that the IPT can understand, which includes the contractor, and is crucial in today’s “insight into” versus “oversight of” the contractor’s effort. This is a necessary, but difficult process. One formal technique for capturing the “voice of the customer” and mapping them into product and process parameters is called Quality Function Deployment (QFD). It consists of techniques for creating and completing a series of matrices showing the association between specific features of a product and customers’ needs. QFD uses teamwork, creative brainstorming, and extensive customer dialogue to identify customer needs and design parameters (read constraints). This and similar techniques have been used with reported advantages of significantly reducing changes as a design enters production and decreasing the time needed to get a design into production.

Requirements must be translated concurrently and in an integrated fashion into optimal product definitions, manufacturing, training, and support processes. Systems engineering must encourage and, in fact, ensure:

(1) all requirements of the life cycle are considered and evaluated,

(2) the crossimpact of various functional disciplines are understood and evaluated with appropriate tradeoffs,

(3) critical risks of various design options are identified and addressed early in the process, and

(4) those responsible for the various functional areas participate with appropriate levels of responsibility and authority.

Integrated Planning and Scheduling. A fundamental change to planning and scheduling is an essential part of the IPD process. The frequently observed practice of maintaining separate plans and schedules for each discipline is replaced by a single integrated schedule. This requires more than combining all existing functional schedules into a single document. Within an overall schedule tied to a capability need date or similar milestone, schedules are eventoriented using exit criteria tied to successful completion of development tasks and incremental product releases. The two documents in current use are the Integrated Master Plan (IMP) and Integrated Master Schedule (IMS).

INTEGRATED PRODUCT & PROCESS DEVELOPMENT

Integrated Technical Reviews. Technical reviews are an integral and essential part of IPD. Technical reviews can range from formal to informal reviews concerned with product and/or verification elements of the development specification. All reviews share the objective of determining the technical adequacy of the existing product and process design to meet requirements.

As the acquisition program moves through the life cycle, the reviews become more detailed and definitive. Technical reviews consider all aspects of the product and process design that are relevant to the progress of a particular phase. The two main purposes of the technical review are: (1) to augment with additional knowledge the integrated product design and analytical activity and (2) to evaluate accomplishment of specified design and verification tasks which need approval before proceeding to the next step in the acquisition process.

Technical reviews are used as the process control mechanism for a program. As such, the specifications form the cornerstone. The specifications are bilateral agreements between industry and the government on the requirements and the process for achieving these requirements as documented in the IMP. Other contractual requirements are captured in the RFP. Technical Performance Measurements (TPMs) are used to establish the entry and exit criteria for each requirement while the eventoriented IMP provides the verifiable success criteria, entry and exit criteria, and other metrics for the process of meeting the requirements. Using these tools readiness for formal reviews are incrementally assessed using the status as entry criteria with the formal review being the final confirmation of readiness to proceed (read “Have the Exit Criteria Been Met?” question that must be answered before exiting the Systems Engineering process). Several key products for use/review in the technical review are the system specification, development specifications, interface control documents, conceptual layouts, buildto packages, training packages, operation packages, support packages, and maintenance packages.

Technical reviews and audits focus on the total product including its manufacturing, support, and training. This approach reflects early baselining of performance requirements and configuration definition data while deferring government configuration control as appropriate (read Clear Accountability In Design (CAID)). Technical reviews and audits culminate with the validation of the Buildto Packages and the Operation, Support, and Maintenance Package (including Training) with the asbuilt/produce products and Developmental Test & Evaluation/Initial Operational Test & Evaluation and factory tests. Incremental reviews of the key products establish the baseline for configuration management.

CONFIGURATION MANAGEMENT

Configuration Management supports the systems engineering process and ensures the integrity and continuity of the product and process designs throughout their life cycle. This process involves the four functions of configuration management (identification, configuration control, audits, and status accounting) and interface control. Baseline management is one of the more important elements of this process. IPD requires control of product and process configuration at all levels, not just drawings as is done today. The government is responsible for the requirements while the contractor is responsible for generating the data to assist in tradeoffs needed to reach a balanced, affordable set of requirements. The contractor is responsible for the design with government assistance in helping to select alternative designs that meet the requirements. This provides for both government and contractor clear accountability in design.

INTEGRATED PRODUCT DEVELOPMENT TEAMS

A key feature of successful implementation of IPD is the establishment of collocated, multifunctional, empowered integrated product development teams (IPDTs) (read Integrated Product Teams (IPTs)). Early involvement of all disciplines (design, manufacturing, configuration management, test, logistics, etc.) working as a team to integrated requirements and schedules significantly reduces the rework in design, manufacturing planning, tooling, and product support planning. Most important is that equal emphasis of both product and process is development is enhanced through the multidisciplined team approach.

Government IPDTs should be organized to develop an integrated properly allocated set of requirements at the performance level, from the weapon system specification down to the lowest indentured specification appropriate for the acquisition, based on the acquisition strategy.

Contractor IPDTs should be organized to translate the performance requirements into a definitive set of design requirements and design criteria and transform those into qualified hardware and software products.

TECHNOLOGY TRANSITION

The concept of IPD can be applied both to the weapon system development process and to the technology, prototype, and manufacturing process developments which enable weapon system advancements. This includes advanced development (6.3A) and Manufacturing Technology (7.8) projects, and related contractor CRAD and IR&D efforts. To achieve this objective, process development technology must be considered and funded in a balanced manner with product technology. If this balance can be attained, the opportunity exists to greatly improve the flow of WRDC and related contractor product and process technology to ASC. Four major opportunity areas have been identified.

The first opportunity deals with the initiation of strategic planning for manufacturing processes as early as possible in weapon system development. Within the ASC/XR planning process for future weapon systems, and particularly as future advanced product technology requirements are identified, balanced consideration should be given to identifying requirements for manufacturing technology development and the industrial base required to create, manufacture and support these advanced product technology features. Also, in order to better support the XR planning function, improvements in the interface with WRDC (read Wright Laboratories) must be established to enable early identification of requirements and subsequent program plans for both WRDC product and process technology and manufacturing technology.

A second major area of opportunity is an enhanced approach to integrating WRDC processes system acquisitions. To realize improvements in this area requires: (1) Identification of ASC product and process requirements to WRDC on a timely basis, (2) A balanced focus on product and process development in WRDC (6.3A) advanced development projects (including joint projects between MANTECH and 6.3A advanced development) and, (3) Improved interaction between WRDC and ASC, particularly during the early phases of an ASC/XR concept development.

A third major area of opportunity involves complete technology transition criteria. Included in this area are metrics for cost, quality, producibility, and supportability considerations as a big part of the SENTAR process.

A fourth opportunity area involves integrated ASC and contractor planning for CRAD/IR&D to include both product and process development. This area deals with the fact that most CRAD and IR&D projects focus on product technology (unless the CRAD project is funded by MANTECH). A balance between product and process developments in advanced technology projects should be sought by focusing more on the process requirements/developments and manufacturing technology developments required to implement product technology advancements. Overall, closer coupling between future Government weapon system requirements, contractor business objectives, weapon system technology requirements, and product and process developments can greatly enhance the payoff from the R&D world. AFMC modification requirements and repair technology developments must also be considered.

File Owner: Vaughn Pleasant, Program Management Specialist

HQ AFMC/DRI

Ph#: (513) 2550418, email: [email protected]

Last Reviewed: Aug 96