DoD Integrated Product and Process Development Handbook August 1998 OFFICE OF THE UNDER SECRETARY OF DEFENSE ACQUISITION AND TECHNOLOGY WASHINGTON DC 20301-3000 IPPD Handbook Table of Contents Chapter 1 Introduction 1 1 1 2 1 Relevant Terms 2 IPPD Tenets 3 1 2 1 Customer Focus 4 1 2 2 Concurrent Development of Products and Processes 4 1 2 3 Early and Continuous Life-Cycle Planning 4 1 2 4 Proactive Identification and Management of Risk 5 1 2 5 Maximum Flexibility for Optimization and Use of Contractor Approaches 5 Chapter 2 Application of IPPD in the DoD Acquisition Process 1 2 1 Getting Started 1 2 1 1 Identify Activities and Stakeholders 2 2 1 2 Determine Range of Contractor Involvement 3 2 1 3 Define the Program Team Structure 4 2 1 4 Define Team Goals Responsibilities and Relationships 6 2 1 5 Train Participants in IPPD Principles 6 2 1 6 Determine Collocation and Integration Requirements 7 2 1 7 Provide for Communication 8 2 1 8 Define Program Metrics 11 2 1 9 Record Processes Activities and Decisions 11 2 2 Phase 0 Concept Exploration 12 2 2 1 Define Requirements Preferred Concepts 12 2 2 2 Analyze Concepts Conduct Tradeoff Studies and Define System Requirements 12 2 2 3 Define the Program 15 2 2 4 Develop RFP for Phase I 18 2 3 Phase I Program Definition and Risk Reduction 20 2 3 1 Evaluating a Contractor’s Proposal Selecting a Contractor 21 2 3 2 Executing Phase I 22 2 3 3 Transition to Next Phase 22 2 4 Summary of the Application of IPPD in DOD Acquisition 23 Chapter 3 Team Best Practices for IPPD 3 1 3 2 1 Definition of a Team 1 3 1 1 Team Size 2 3 1 2 Team Hierarchy 2 Team Leader 2 i  IPPD Handbook 3 3 3 4 3 5 3 6 3 7 3 8 Team Member Selection and Negotiation 3 3 3 1 Technical or Functional Expertise 4 3 3 2 Problem-Solving and Decision-Making Skills 4 3 3 3 Interpersonal Skills 4 3 3 4 Ability to Work Effectively in an IPPD Environment 5 Team Dynamics 5 3 4 1 Team Charter 6 3 4 2 Team Unity and Issue Resolution 7 3 4 3 Compensation 9 Team Meetings 10 3 5 1 Roles and Responsibilities 10 3 5 2 Agendas 11 3 5 3 Ground Rules 11 3 5 4 Meeting Frequency 12 Team Training 12 3 6 1 Team-Building Training 13 3 6 2 IPPD Training 13 3 6 3 Information Technology Training 13 3 6 4 Product-Specific Training 14 3 6 5 Systems Engineering and Analysis Training 14 3 6 6 Facilitator Training 14 Team Membership and the Government Role 14 Final Thoughts on Team Best Practices for IPPD 16 Chapter 4 Metrics 1 4 1 4 2 Metric Attributes 1 Types of Metrics 2 4 2 1 Progress 2 4 2 2 Product 3 4 2 3 Process 4 4 3 Metric Development Process 5 4 4 General Guidelines for Team Metrics 6 Chapter 5 Integrated Information Environments 1 5 1 Internet 1 5 2 Compatibility 3 5 2 1 Common Interface Standard 3 5 2 2 Continuous-Acquisition and Life-Cycle Support 3 5 3 Security 4 5 4 Electronic Business Applications 5 5 4 1 Federal Acquisition Streamlining Act of 1994 5 5 4 2 Electronic Commerce and Electronic Data Interchange 6 5 4 3 Business Tool Examples 7 5 5 Product Development Applications 7 ii  IPPD Handbook Chapter 6 Modeling and Simulation 9 6 1 Simulation-Based Acquisition 10 6 2 The Simulation Test and Evaluation Process 11 6 3 Defense Modeling and Simulation Office 11 6 4 Prototyping 13 6 4 1 Virtual Prototyping 13 6 4 2 Physical Prototyping 19 Chapter 7 Additional IPPD Tools 7 1 7 2 7 3 7 4 7 5 1 Requirements Definition 1 7 1 1 Quality Function Deployment 1 7 1 2 Requirements Analysis Process in Design for Weapon Systems 1 System Decomposition 2 Defect Prevention 2 7 3 1 Design for Manufacturing Process Capability 4 7 3 2 Design for Manufacturing Assembly 4 7 3 3 Process Variability Reduction 4 7 3 4 Root Cause Closed Loop Corrective Action 4 7 3 5 Robust Design 4 7 3 6 Statistical Process Control 6 Cost Modeling 7 7 4 1 Real-Time Costing 7 7 4 2 Activity-Based Costing 7 Lean Enterprise 8 Appendix 1 - Acronyms Appendix 2 - Sources of Additional Information List of Figures Figure Title Page Figure 2-1 Figure 3-1 Figure 4-1 Figure 4-2 Figure 4 3 Figure 5-1 Traditional Serial Approach versus IPPD and Cost of Change 2 Sample Charter F A-18 Program Team 8 Sample Progress Metric 3 Sample Product Metric 4 Sample Process Metric 5 Internet-Based Network 1 iii  IPPD Handbook Chapter 1 Introduction Integrated Product and Process Development IPPD evolved in industry as an outgrowth of efforts such as Concurrent Engineering to improve customer satisfaction and competitiveness in a global economy In May 1995 consistent with the Department of Defense DoD efforts to implement best commercial practices the Secretary of Defense directed a fundamental change in the way the Department acquires goods and services The concepts of IPPD and Integrated Product Teams IPTs shall be applied throughout the acquisition process to the maximum extent practicable During the summer of 1995 the Office of the Secretary of Defense OSD surveyed over 80 government and industry organizations regarding their IPPD policies and practices Using those survey results OSD published the DoD Guide to Integrated Product and Process Development Version 1 0 dated February 5 1996 hereinafter called the DoD Guide to IPPD The DoD Guide to IPPD was developed to provide a general understanding of DoD’s perspective on IPPD In March 1996 DoD published major rewrites of DoD Directive 5000 1 Defense Acquisition Directive and DoD Instruction 5000 2⎯now DoD Regulation 5000 2-R Mandatory Procedures for Major Defense Acquisition Programs MDAPs and Major Automated Information System MAIS Acquisition Programs The 5000 1 Directive states policies and principles for the management of all DoD acquisition programs and identifies the Department’s key acquisition officials and forums It repeats the Secretary of Defense’s dictum to implement IPPD and IPTs “to the maximum extent practicable ” The 5000 2-R regulation describes the DoD acquisition process for MDAPs and MAIS acquisition programs incorporating IPPD principles It defines IPPD as— A management technique that simultaneously integrates all essential acquisition activities through the use of multidisciplinary teams to optimize the design manufacturing and supportability processes IPPD facilitates meeting cost and performance objectives from product concept through production including field support One of the key IPPD tenets is multidisciplinary teamwork through Integrated Product Teams IPTs This handbook expands upon the government and industry guidance provided in the DoD Guide to IPPD by providing suggestions and examples of specific ways to implement IPPD Like the DoD Guide to IPPD it is non-directive It suggests solutions to difficulties that might be encountered in IPPD implementation and explains tools and techniques that can be used throughout a product’s life cycle It is not however an in-depth application manual for specific tools nor does it attempt to cover all of the tools available—only representative ones from many different categories The reader once aware of such tools and their significance can perform further research using the links Internet World Wide Web URLs or addresses and phone numbers that are included in this handbook as sources of additional or updated information This handbook also is not meant to be definitive on the new acquisition initiatives other than in their relationship to IPPD For example much has been written on topics such as risk management and Cost as an Independent Variable CAIV that will not be repeated here However links to additional information on these topics are provided This handbook cannot force the cultural change necessary to accomplish IPPD this must be done through leadership from the highest levels of management What this handbook can do is suggest methods and specific tools that programs can utilize to implement IPPD For that reason the text is 6 July 1998 1 IPPD Handbook interspersed with specific examples of tools and actual implementation examples from acquisition programs and industry 1 1 Relevant Terms IPPD In addition to the definition stated above the DoD further defines IPPD as A management technique that integrates all acquisition activities starting with requirements definition through production fielding deployment and operational support in order to optimize the design manufacturing business and supportability processes IPPD as a multidisciplinary management technique uses design tools such as modeling and simulation teams and best commercial practices to develop products and their related processes concurrently Integrated Product Teams An Integrated Product Team IPT is a multidisciplinary group of people who are collectively responsible for delivering a defined product or process The IPT is composed of people who plan execute and implement life-cycle decisions for the system being acquired It includes empowered representatives stakeholders from all of the functional areas involved with the product—all who have a stake in the success of the program such as design manufacturing test and evaluation T E and logistics personnel and especially the customer Because the activities relative to a system’s acquisition change and evolve over its life cycle the roles of various IPTs and IPT members evolve When the team is dealing with an area that requires a specific expertise the role of the member with that expertise will predominate however other team members’ input should be integrated into the overall life-cycle design of the product Some teams may assemble to address a specific problem and then become inactive or even disband after accomplishing their tasks The Boeing 777 experience supported the continuation of IPTs throughout the entire program acquisition Having IPT members with experience on the program was a primary factor in providing continuity reducing the program’s overall schedule and requiring minimal program training This handbook addresses program-level or execution-level IPTs Oversight IPTs—Overarching IPTs OIPTs and Working-Level IPTs WIPTs —are addressed in Rules of the Road A Guide for Leading Successful Integrated Product Teams Rules of the Road can be found at http www acq osd mil ar ipt htm Systems Engineering Systems engineering is a problem-solving process used to translate operational needs and or requirements into a well-engineered system solution It too is an interdisciplinary approach although IPPD is broader because it includes not only engineers technical specialists and customers but also business and financial analysts Systems engineering creates and verifies an integrated and life-cycle balanced set of system product and process solutions that satisfy stated customer needs 6 July 1998 2 IPPD Handbook Customer The IPPD approach is driven by the customer’s need The ultimate customer is the operational user of the system As discussed above appropriate members of the user organization participate actively on development teams working to optimize the fielded system’s ability to meet their requirements Stakeholders A stakeholder is an organization or functional activity that has a stake in the decision at hand or the outcome of the program The term stakeholder also is used for the empowered working-level representatives of that organization or functional activity that serve on IPTs As such stakeholders are important decision makers They control the resources and collectively have the know-how to get the job done The term stakeholder is used throughout this handbook in both senses of the word as appropriate Processes Three types of processes are referred to in this document 1 “Top level ” overarching processes such as Systems Engineering and Test and Evaluation These are commonly referred to as functional and their operation is the responsibility of the traditional seats of functional power in an organization The functional organization of these processes establishes and ensures the effective application of a function’s governing generic principles and practices The functional organizations are the keepers of technical purity for their function but do not individually control the IPPD approach 2 “Development” processes or processes that facilitate the making of a product These include the application and tailoring of the traditional functional disciplines with a home office as well as processes that do not have a functional organization office such as integration These processes are not delivered to the customer although the results of their work are and they are driven by the needs of the particular product being developed Examples include Integration Production Computer Support and Modeling and Simulation 3 “Deliverable” processes that will actually be delivered to the customer in order to support the product or perhaps the delivered process is the product Examples include the support training and maintenance processes As with development processes it is reasonable to think of the deliverable processes as products and deliverable processes such as these usually are assigned to an IPT Sometimes the processes are not actually delivered but implemented e g total contractor support is not “delivered” to the government but is used or implemented by the end item user 1 2 IPPD Tenets The DoD Guide to IPPD lists 10 basic tenets for the implementation of IPPD For purposes of this document the 10 tenets are grouped into the following main principles that will be stressed throughout this handbook 6 July 1998 3 IPPD Handbook 1 2 1 Customer Focus Customer focus is accomplished by including the customer in decision making and on multidisciplinary teams Section 2 1 1 and Chapter 3 Conducting tradeoff studies during the requirements definition and development processes also ensures that the design remains consistent with customer needs The specific tradeoff analysis process that is focused on reducing and controlling life-cycle cost while meeting the customer needs is called Cost as an Independent Variable CAIV Sections 2 2 2 and 7 4 Quality Function Deployment QFD Section 2 2 2 and 7 1 1 is also an effective method for defining customer requirements 1 2 2 Concurrent Development of Products and Processes Concurrent development of products and processes refers to the simultaneous development of the deliverable product and all of the processes necessary to make the product development processes and to make that product work deliverable processes These processes can significantly influence both the acquisition and life-cycle cost of the product Process examples include the manufacturing processes needed to fabricate the product the logistics support processes needed to support the product or for a data collection system the process to collect and disseminate the information gathered Emphasizing the design of these processes at the same time the product is being designed ensures that the product design does not drive an unnecessarily costly complicated or unworkable supporting process when the product is actually produced and fielded Not developing the processes concurrently with the product results in utilizing an inefficient manufacturing and support process or causing a redesign of the product which could potentially wipe out any other cost reductions achieved through the application of other IPPD principles From an engineering viewpoint concurrent development of products and processes to satisfy user needs is known as systems engineering In IPPD the systems engineering approach to designing a product is expanded to include all stakeholders—those developing not only the product but all product-related processes as well e g business processes such as financial contracting etc Multidisciplinary teamwork and an emphasis on real-time and open communication are key to accomplishing this concurrent development Multidisciplinary teamwork is implemented in an IPPD environment usually through the use of IPTs Members of an IPT are empowered to make decisions for their respective organizations and keep them informed of the product and process decisions An enhanced communication environment where all program information is in a format available to all stakeholders in real time Section 2 1 1 and Chapter 5 is of primary importance to the effectiveness of the IPTs 1 2 3 Early and Continuous Life-Cycle Planning Early and continuous life-cycle planning is accomplished by having stakeholders representing all aspects of a product’s life-cycle as part of the multidisciplinary teams Early life-cycle planning with customers functional representatives and suppliers lays a solid foundation for the various phases of a product and its processes Key program activities and events should be defined so that progress toward achievement of cost-effective targets can be tracked resources can be applied and the impact of problems resource constraints and requirements changes can be better understood and managed Early emphasis on life-cycle planning ensures the delivery of a system that will be functional affordable and supportable thoughout a product’s life cycle 6 July 1998 4 IPPD Handbook 1 2 4 Proactive Identification and Management of Risk IPPD is not a ”design now-test later” approach to product and process development Proactive identification and management of risk is accomplished in many ways in the IPPD environment By using the multidisciplinary teamwork approach designers manufacturers testers and customers work together to ensure that the product satisfies customer needs DoD endorses a risk management concept that is forward-looking structured informative and continuous The key to successful risk management is early planning and aggressive execution IPPD is key to an organized comprehensive and iterative approach for identifying and analyzing cost technical and schedule risks and instituting risk-handling options to control critical risk areas IPTs develop technical and business performance measurement plans with appropriate metrics Chapter 4 to monitor the effectiveness and degree of anticipated and actual achievement of technical and business parameters Modeling and simulation tools Chapter 6 are used to simulate test and evaluate the product prior to starting production Robust design Section 7 3 5 methods are used to minimize problems in manufacturing and operations Event-driven scheduling Section 2 2 3 2 is used to integrate all development tasks and to ensure that a task is not started until all prerequisite tasks are complete 1 2 5 Maximum Flexibility for Optimization and Use of Contractor Approaches There are many ways to accomplish IPPD IPPD is a management approach not a specific set of steps to be followed The Government acquisition community recognizes that it must allow contractors the flexibility to use innovative streamlined best practices when applicable throughout the program Thus it cannot specify specific steps for the contractor to follow The DoD leadership’s recent instructions that acquisitions will now be performance-driven not processdriven help in maximizing flexibility for the optimization and use of contractor approaches These instructions allow the contractor more latitude in developing bid proposals and conducting their processes For example DoD’s efforts to reduce the use of military specifications and standards allows contractors to adapt their fabrication processes and management techniques for optimal use on the product being developed Chapter 2 presents steps for applying IPPD but these are general instructions to define the approach not an exact procedure More information on DoD initiatives to help optimize the use of contractor approaches can be found at http www acq osd mil ar #activities Or go directly to the Single Process Initiative website at http www acq osd mil ar single htm or the Perofrmance-Based Business Environmant at http www asc wpafb af mil az jacg pbbe pbbe htm The next chapter discusses how IPPD tools and techniques are applied throughout the acquisition process 6 July 1998 5 IPPD Handbook Chapter 2 Application of IPPD in the DoD Acquisition Process The acquisition process is typically divided into five stages the first four formal phases are separated by milestone decision points The five stages are— • Phase 0 Concept Exploration CE • Phase I Program Definition and Risk Reduction PDRR • Phase II Engineering and Manufacturing Development EMD • Phase III Production Fielding Deployment and Operational Support PFDOS • Demilitarization and Disposal DD However not all programs go through the same number of phases The number of phases and decision points are tailored to meet the specific needs of an individual program based on such things as the adequacy of proposed risk management plans and the urgency of the user’s need Tailoring is conducted to minimize the time it takes to satisfy an identified need consistent with common sense and sound business practices The cost to implement product changes increases as a program moves from the earlier to the later phases of its life cycle Figure 2-1 IPPD’s greatest potential for leverage during the acquisition process therefore occurs in the early stages of development when the program is most flexible It is at this early stage that an analysis of life-cycle issues and cost performance tradeoff studies can provide a life-cycle balanced approach and prevent costly changes later in the product’s life cycle For a major program this period would be in Phases 0 and I Accordingly this chapter discusses these phases in detail For a modification or upgrade to an existing program even though it may not have formal DoD acquisition phases and milestones associated with it the sequence of events is the same Therefore regardless of the type of requirement the customer defines—a new system or an upgrade to an existing system—the activities described in this chapter apply This chapter starts with an explanation of how to set up an IPPD program It looks closely at Phase 0 the phase in which IPPD principles are applied to their greatest advantage in a program and Phase I with emphasis on evaluating contractor proposals monitoring contractor tradeoff studies design risk management and demonstration efforts and preparing for the transition to the next phase The chapter does not address subsequent acquisition phases in detail because similar IPPD techniques apply to all subsequent phases 2 1 Getting Started Whatever the phase of development of a program implementing IPPD follows some basic considerations The structure and processes for implementing an IPPD approach need to be defined based on the activities that need to be performed and whether the government or contractors will be performing those activities This involves identifying all stakeholders necessary to accomplish the activities forming IPTs and defining their goals tasks and responsibilities and training all stakeholders in the IPPD approach Metrics need to be defined to measure progress in meeting the program goals After the activities and stakeholders are defined the structure and processes are determined by addressing such issues as collocation 6 July 1998 1 IPPD Handbook High Dollars Number of Design Changes High Low Low CE and PDRR EMD PFDOS and DD TIME IPPD Approach Serial Approach Cost of Change Figure 2-1 Traditional Serial Approach versus IPPD and Cost of Change communication and level the of computer sophistication for efficient information The issues of software interoperability and security also need to be addressed at this time A procedure for recording processes activities decisions and their rationale along with a system for easy retrieval of the information lays a solid foundation for efficient operation and communication in the IPPD environment This process also needs to be developed as one of the early steps in developing an IPPD environment 2 1 1 Identify Activities and Stakeholders The first step in applying IPPD to a program is identifying the activities and the various stakeholders that need to be involved Activities include the specific tasks studies design performance cost tradeoffs contract subcontractor management cost estimating budgeting tracking design integration manufacturing test and evaluation etc that must be performed in order to deliver the product to the customer Activities will vary depending on the type of program—new start or mod Stakeholders include government acquisition personnel customers engineering and test personnel support personnel e g maintainers and logisticians and contractor personnel When there is uncertainty about the need to represent a specific function it should be included initially and removed later if its involvement is not needed 6 July 1998 2 IPPD Handbook 2 1 2 Determine Range of Contractor Involvement Many times a significant amount of open communication and trust is needed in order for IPPD and IPTs to successfully work at the program level In other words every member of the program team government and industry needs to work from the same information and toward the same overall program goals The degree to which this open communication can occur depends on several factors like the competitive nature of a particular program and it must be within the statutory boundaries of acquisition laws As long as these criteria are met the amount of integration across the government industry boundary is unlimited Contractor involvement ranges from providing unofficial advice to actually conducting the research and generating solution options At each stage in a program the appropriate roles of contractor and government personnel need to be determined Often activities may start within the government but transfer later to a contractor Three scenarios describe the range of contractor involvement 1 Contractor as Lead In this scenario two or more contractors are awarded contracts to develop unique solutions to a set of government requirements The contractors propose solutions and the government selects one or more of them to continue into subsequent phases The government manages the contracts and participates in the contractor-led IPTs to the extent permissible by the rules governing competition In some cases this may mean the government simply monitors the performance of the industry teams However there have been successful cases recently where in a competitive situation government team members have been assigned to help contractor-led IPTs Such participation brings the government perspective to the contractor team where government team members actively participate in formulating the team strategy and approach Government individuals participating in such a manner need to follow strict rules to preserve the competitive nature of the contract One such rule is that these government team members must be shielded from any source selection data for competing teams even though these government team members are usually not part of the Source Selection Evaluation Team Even with the rules well-defined finding the right individuals can be difficult because they should be highly qualified with excellent judgment and a solid background in acquisition policies and procedures—individuals whom the contractors will trust to help them Levels of government expertise need to be balanced across the teams 2 Formal Support In this scenario one or more contracts are awarded to collect and assemble data on various potential solutions The government conducts the tradeoff study analyses to determine the most likely solution s if any that warrant continuation through later phases The government remains engaged with the industry teams to gain insight into the data collected and facilitate the manipulation of the data when the tradeoff study analyses are conducted Depending on the government’s follow-on plans there may or may not be competitive considerations in this type of activity Often the industry teams collecting the data are prohibited from bidding on any follow-on work and in these cases there can be open communication with very little worry about competition secrecy If however the industry teams are able to bid on the follow-on work this is a 6 July 1998 3 IPPD Handbook competitive situation and all communications and industry involvement must be handled accordingly 3 Informal Support In this scenario contractors informally support activities conducted using the in-house expertise and resources entirely within the government Industry becomes an interested observer and can provide insight and support as needed by the government Activities described in the following sections could be performed by the contractor or by government personnel as appropriate to the program and the activities being performed 2 1 3 Define the Program Team Structure After the activities and stakeholders are identified the next steps are to decide on a program structure and form the IPTs The IPTs need to be structured in a coherent manner to define the relationship between top-level and sub-tier teams Depending on the type of program at the initiation of Phase 0 some well-defined programs may need the teams to be fully structured while other less-defined programs will just need the teams to be structured around the near-term tasks to be accomplished If the latter a more detailed team structure will need to be built as the program takes on more definition IPTs are usually formed around the key products and processes associated with the program A Work Breakdown Structure WBS is a management tool that identifies and integrates hardware software services data and facilities and is based on key products and processes in a productoriented tree structure If the program has created a WBS it is a useful tool for identifying how the IPTs should be structured It makes sense to concentrate control and responsibility at the most important levels of the WBS particularly around high-risk tasks or those tasks on the critical path One can look to the WBS levels in forming the IPTs making sure however that all life-cycle concerns are addressed in the IPTs If a WBS has not been created the key products and processes that will be required for the program should be identified and organized into logical groupings These groupings provide an alternative structure for setting up the IPTs Furthermore one can consider the staffing that will be required to create integrated multidisciplinary teams and draw up a notional IPT organization complete with numbers of people and tentative responsibilities There may be insufficient personnel to create the initial structure and WBS elements may need to be consolidated and combined or key products and processes regrouped to make the organization fit the available personnel After this process has been iterated one can settle on a reasonable organization for the program that retains as much of the product and process orientation for the IPTs as is practical Since a WBS usually is closely aligned with the cost accounting system aligning IPTs with the WBS often makes it easier for the IPTs to monitor and take responsibility for cost Information on the WBS can be found in MIL-HDBK 881 at http www acq osd mil pm newpolicy wbs wbs html Another option for IPT structure is to use the IEEE Std 1220-1994 on Systems Engineering This standard proposes the use of a Systems Breakdown Structure SBS defined as “a hierarchy of elements and related life-cycle processes used to assign development teams conduct technical reviews and to partition out the assigned work and associated resource allocations to each of the tasks necessary to accomplish the objectives of the project ” 6 July 1998 4 IPPD Handbook For more information on IEEE standards go to http standards ieee org Defining product-oriented IPTs is reasonably straightforward These IPTs are focused on the key deliverable products that the customer expects to receive Defining process-oriented IPTs is not as easy Process IPTs at the program level commonly address two types of processes As discussed in Chapter 1 a development process is used to develop a balanced product but is not actually delivered to the customer e g integration test and evaluation software development or production These critical development processes must be conducted and it may be useful to form IPTs to manage and improve these processes during the development The program office makes this decision based on the size of the task and the importance of the process to customer satisfaction Deliverable processes are actually delivered to the customer e g support training and maintenance processes For some programs the only deliverable may be a process As with development processes the program office decides whether to form an IPT for these deliverable processes Process-oriented IPTs are also sometimes referred to as “functional” IPTs since they are responsible for managing a function like test and evaluation or systems engineering It is important to remember that these IPTs should remain multidisciplinary regardless of the terminology applied to them Care must be taken when using process-oriented IPTs so that their single-function nature doesn't end up recreating the traditional stovepipe approach Team membership needs to include all concerned stakeholders and its goals should be closely linked with the goals of the other teams and the project as a whole Most programs find it appropriate to have both product and process IPTs The most common process IPT is one formed to integrate all the deliverable product outputs of the other IPTs into a coherent and effective system Common names for this IPT include “Systems Engineering and Integration IPT” or “Analysis and Integration IPT ” This team is responsible for the overall integration of the efforts of the individual product IPTs ensuring communication among the teams and effective application of accepted systems engineering principles to the development of the program's product Their product is an integration process measured by the success or failure of the integrated product to meet total system requirements at the optimum balance of cost schedule and performance Specific guidance on a single type of organization to use for all DoD acquisition projects is not possible Every program has unique objectives and operating environments Program managers must determine their unique program goals and constraints and ensure that the program structure is organized around those goals IPT Organization Examples Examples of the integrated product and process structure are the Patriot PAC-3 Missile program and the Joint Strike Fighter JSF program The primary IPTs of the Patriot PAC-3 represent the major products and the major processes required for a successful acquisition of those products Product IPTs Missile Seeker Command and Launch System 6 July 1998 Process IPTs Performance and Simulation Test and Evaluation Production 5 IPPD Handbook The Systems Engineering Directorate of the JSF program is organized around IPTs that range from Airframe and Flight Systems product to Advanced Cost Estimating and Systems Test processes The Standard Missile-3 SM-3 program however has an IPT structure organized according to traditional functional processes This organization is intended to optimize existing contractor infrastructure without disruptions to the program 2 1 4 Define Team Goals Responsibilities and Relationships After the IPT structure is defined and membership assigned the following IPT-related program issues need to be addressed • Define team goals for each specific IPT and common goals for all IPTs • Define the reporting structure and working relationship of all IPTs in relationship to each other • Define the level of empowerment of all IPTs • Define the relationship between government and contractor personnel on IPTs • Define measures by which to gauge IPT performance metrics The first four issues are discussed in Chapter 3 Team Best Practices for IPTs The last one is elaborated further in Section 2 1 8 and in Chapter 4 Metrics The best way to accomplish these actions is to document them in team charters All charters should be signed by the team members and approved by a higher level authority The IPT charters need to be frequently reviewed as an acquisition program progresses to ensure that it remains in line with changing program goals See Section 3 4 1 for further discussion of team charters 2 1 5 Train Participants in IPPD Principles Successful institutionalization and implementation of IPPD within DoD depend on well-trained participants at all levels Industry lessons learned show that initial and continued investment in personnel training positively affects IPPD implementation Participants must have a clear understanding of the DoD philosophy of IPPD the tools available for its implementation and the skills such as team building required for its success Therefore it is imperative that all members who have a stake in the IPPD approach from top-level management to worker-level participants be well trained in IPPD principles Different levels of management need different types of training focused on their part of the approach e g top-level management needs to be trained on methods of empowerment This document is an overview of IPPD and should not be construed as a training guide although it may be used to supplement training Some IPPD and IPT training is best carried out in a classroom setting with qualified instructors In this setting students are exposed not only to the 6 July 1998 6 IPPD Handbook tools of IPPD but also to the development of the team dynamics required to successfully implement IPPD Individual training materials on IPTs and IPPD methods and tools are also available to be used as required and appropriate DoD is developing IPPD training for its acquisition personnel both in the classroom and with individual self-directed interactive CD instruction Team training is discussed in further detail in Section 3 6 Information on training provided by the Defense Acquisition University DAU can be found at http www acq osd mil dau To obtain a copy of the Navy’s IPT Learning Campus CD contact the Navy Acquisition Reform Office at 703 602-5506 or go to http www acq-ref navy mil ipthome html Training Example LPD 17 Amphibious Transport Dock Ship Program To break with traditional ship design methods and to design a new ship in a concurrent engineering process resulting in a fewer number of later-phase changes the Amphibious Transport Dock Ship LPD 17 program manager decided that extensive IPPD training was required The LPD 17 program first conducted IPPD training as a government team and then with the major subcontractors’ team i e Avondale Hughes Bath Intergraph This training included team building skills as well as IPPD principles Key to the success of the program’s training methods was the program manager’s commitment to completing this training prior to the start of any design activity 2 1 6 Determine Collocation and Integration Requirements A cornerstone of the IPPD management technique is the integration of all stakeholders into a cohesive working unit In traditional acquisition and development involving a sequential handoff of tasks location of the various people was not a major concern Today’s IPPD approach makes real-time integration of a program’s various functions essential Exact mechanisms and procedures for enabling team interaction vary The most obvious way to accomplish this integration is collocation of the stakeholders Collocation enables sharing information at the lowest levels learning across functions and team building In the ideal IPPD setup the stakeholders work not only at the same facility but also in the same room In the real world however collocation of all the stakeholders is not always possible—or even desirable Moreover in large programs the number and size of IPTs precludes meaningful collocation As with everything else in the program a cost-effective solution is needed and the cost dollars impact on other programs loss of contact with home office etc of relocating the team members must be weighed against the benefits faster communications better integration quicker response times etc of collocation In practice most programs have found that integrating all stakeholders into a cohesive unit is neither simple nor inexpensive An adequate budget must be available from the start of the program for personnel relocation or for investment in communication assets if collocation is determined to be impracticable Since large distances can separate teams and possibly team members physical collocation of all teams and team members often is not possible Virtual teaming technologies such as teleconferences e-mail Internet homepages and common data bases will be required See Chapter 5 for further information on these types of technologies 6 July 1998 7 IPPD Handbook Another approach is to use a mix of virtual teaming technologies supplemented by periodic onsite team meetings Although there is a cost associated with bringing together IPTs that are not collocated for such meetings the face-to-face interaction for important milestones can be invaluable This approach however can be negatively impacted should reductions in travel funds become necessary due to cuts in program funding Collocation Examples LPD 17 The LPD 17 program office had five shipbuilders collocated with them during the ship’s contract design and specification development stage prior to RFP issuance and Milestone II This collocation aided in the producibility of the contract design package and acquisition streamlining as well as the ship specification efforts The program office was collocated at the site of the chosen prime contractor Avondale along with representatives from the Avondale alliance teammates The team of government LPD 17 and Avondale-alliance personnel is located in the same building working literally side by side Collocation has resulted in significant cycle time reductions Issues are addressed on a real-time basis rather than through the mail system drafting the issue staffing it in some other location and then drafting and mailing a response back Joint Strike Fighter The JSF program charter called for a joint solution to meet the needs of both the Air Force and the Navy Recognizing the importance of developing a consensus among the Services senior leadership staffed the joint program office with equal representation from both Services In an effort to better understand the requirements and ensure optimum use of program resources program leadership collocated both warfighter and technologist in the program office As a result in less than 2 years the program has effectively identified the critical tasks and leveraging technologies necessary to pursue a preferred weapon systems concept that meets both Services’ needs For further information on the JSF program see http www jast mil 2 1 7 Provide for Communication Communication is critical to IPPD success In an IPPD environment all stakeholders need to have access to the most current information on the program With stakeholders frequently geographically separated an integrated set of communication tools to enable team members to communicate in real time is ideal Communication tools range from telephone networks and fax machines to video teleconferencing VTC systems and wide area computer networks⎯the options are expanding every day And all of these options have various costs and benefits depending on the program’s situation Therefore planning related to information management communication networks and methods of formal communications should take place at the beginning of all acquisition development programs 6 July 1998 8 IPPD Handbook Communication can be divided into three areas personal business and product development 1 Personal communications relate to day-to-day communication and exchange of documentation or correspondence between individuals Examples include telephone calls faxes e-mail electronic file transfers and teleconferences with or without video 2 Business communications relate to solicitations Requests for Proposals Quotations RFPs RFQs proposals contracts status reports and other similar types of communications Most of these have traditionally been performed using paper copies Due in part to the Federal Acquisition Streamlining Act FASA of 1994 which requires that business transactions be performed via electronic means most of these transactions now take place electronically Electronic business transactions and information exchanges help make possible the IPPD requirement for real-time availability of information to all stakeholders 3 Product Development communications relate to the exchange of engineering models and data bases—information about the product and process being developed This communication is defined not only as communication between personnel but also as communication between software applications The use of a common shared data base containing information about the product and process being developed is of prime importance 2 1 7 1 Electronic Support for Communication At the high end of electronic support for communication are computerized tools that span the whole life cycle and seamlessly share data across the various functional areas of the program The results of this integration are the greater availability of the data more confidence in the data more ways to use the data and the ability to present the data in forms that are useful and understandable to a wider range of stakeholders Computerized tools due to their complexity need extensive up-front planning that addresses applications the degree of complexity of the system interoperability of the software and the level of security But their complexity also introduces a cost associated with their implementation that needs to be balanced with the benefits they provide A common-sense approach is needed in planning for their use taking into account the types of systems the government and contractors already have in place and both the nearterm and life-cycle costs The discussion below provides some tips on planning related to these computerized communication requirements • Applications Needed The first step in determining the developmental environment is to determine the requirements for electronic data Then one can identify what kind of software applications are needed and whether these applications need to be accessed from a single site or from multiple locations Software applications can range from traditional computer-aided engineering CAE models and simple data bases listing design data performance data functional decompositions risk management information etc to integrated virtual environments Traditional methods often involve manually loading data from one application into another while an ideal virtual environment uses the same data set for all applications Fully integrated computing environments combine data and 6 July 1998 9 IPPD Handbook models from all aspects of a design into one seamless system where individuals from different functions e g designers manufacturers maintainers purchasing agents can access the data in formats tailored to their needs • System Complexity Program specifics such as the complexity of the system the degree of analysis needed to proof the system the relative price of engineering changes and the potential risk events should all be considered when deciding on the level of complexity of the development environment While a more complex environment will cost more to set up the time savings and error reduction⎯and as a result the program savings⎯ can be substantial • Software Interoperability When software tools for management engineering and production first appeared they were extremely limited in their scope and in their ability to interact with other programs In general they only dealt with a single function during a single life-cycle phase and used proprietary data formats on a single stand-alone computer They were expensive to purchase and to update Transferring data from one tool to another often meant translating reentering and verifying data IPPD evolved from concurrent engineering expanding the concept beyond engineers to include business analysts customers and suppliers For all these functions to operate in an integrated manner trusted modern information systems that integrate engineering schedule and financial analysis are required One way to enhance interoperability is to use the same software at all sites An alternative is to use a server at one site with access from wherever needed Because IPTs encompass multiple organizations e g government and contractors the potential exists for software incompatibility between systems at different sites Another option for minimizing software non-interoperability is to adopt standardized protocols such as the Department of Commerce’s Common Interface Standard or DoD’s Continuous Acquisition and Life-Cycle Support CALS standards • Security An IPPD environment utilizing enhanced communications requires built-in security measures that prevent unauthorized access to program data These measures should not interfere with the ability of team members to communicate Because such security measures can be difficult and expensive both in incorporation and in data loss due to a nonsecure system if incorporated late security of communications needs to be considered when setting up the communications network Chapter 5 Integrated Information Environment has more detailed discussion on the advantages of using a common data base system complexity interface standards security of electronic communications the use of the Internet and other paperless business transactions Communication Example Joint Strike Fighter The JSF program which has some geographically dispersed elements uses paperless processes It emphasizes electronic processes as the standard means of communication and exploits the Internet for efficient real-time dissemination of program information including information related to program procurement solicitations For further information on the JSF program see http www jast mil 6 July 1998 10 IPPD Handbook 2 1 8 Define Program Metrics Metrics or standards of measure that form the data base for the application of statistics and mathematical analysis constitute an important tool in the IPPD environment When properly defined and used metrics can permit timely assessments predictive of ongoing processes and the monitoring of resource consumption Metrics should be easily measured exportable simple to use support the program processes and be cost effective The tools and metrics aren’t necessarily different from those used in a non-IPPD environment but the expectations from using them do change Many activities are done earlier and results are seen sooner in the program The metrics should reflect this Metrics are used at all levels of a program’s structure preferably representing key measures of output rather than input or activity metrics Many metrics such as those relating to cost schedule and performance can be used throughout the program’s life cycle while others may be tied to one portion of the program Regardless of when they are used in the program the timeliness of the information—both for calculating the metric and in the information the metric provides—is an important consideration In performance-based contracting the contractor should develop metrics to measure actual performance against contractually required performance The IPTs should have cognizance of these metrics Chapter 4 defines what metrics are describes their essential properties and types and outlines a nine-step process for developing metrics 2 1 9 Record Processes Activities and Decisions Recording IPPD-related processes activities and decisions is essential for program stability and communication integrity Key processes can be recorded as local operating instructions process narratives or other suitable forms Descriptions should be clear concise and allow flexibility within the process Key program and team activities action items and decisions can be documented as meeting minutes a separate program historical file or any other formal system such as an IPPD-focused management information system that allows automated access by all stakeholders Such a system— • Provides an historical record of activities and decisions • Documents tradeoff studies cause-and-effect analyses and similar activities • Promotes team-oriented information and communication • Facilitates evaluation of metrics and lessons learned Effective recording of processes activities and decisions coupled with an efficient retrieval process for the information affords stakeholders and team members a clear understanding of program workings Such information facilitates risk management future decision making and a review of lessons learned The process of documenting decisions also reduces the ramp-up for assigned personnel which is an issue that needs to be considered by organizations with a high percentage of military personnel For example describing all concepts explored and the reasons why they were accepted or rejected makes it possible to reevaluate these concepts as requirements develop 6 July 1998 11 IPPD Handbook 2 2 Phase 0 Concept Exploration In broad terms the objectives of the Concept Exploration phase are fourfold 1 to perform concept studies to investigate different solutions 2 to evaluate these different concepts 3 to perform tradeoff studies and 4 to define the requirements for the remainder of the acquisition program IPPD activities involve organizing the different functions to work concurrently and collectively so that all aspects of the life cycle for the various concepts are examined and a balanced concept emerges During this phase the acquisition program is defined in broad technical and programmatic terms Phase 0 often starts with a very small government group overseeing government and or government and contractor-performed Concept Exploration A government program office may or may not formally exist prior to Milestone I During this phase of Concept Exploration the government must decide what the industry role will be Concept studies may be performed by a contractor Consistent with an IPPD approach any solicitation for contract proposals for these studies needs to request offerors to describe how their processes support the key tenets of IPPD i e customer focus concurrent product and process development life-cycle analysis and the proactive identification and management of risk But the solicitation and resulting contract should not direct an offeror to adopt any particular business management or technical process These key concepts should be reinforced and expanded upon in Phase I and or follow-on contract efforts Although a formal Acquisition Strategy is not required during Phase 0 DoD 5000 2-R Section 3 3 a strategy needs to be sufficiently evolved to envision future opportunities for technical and contracting competition Actions taken should neither impede future competition nor create potential organizational conflicts of interest Additional discussion of this topic is included in the section on Phase 1 2 2 1 Define Requirements Preferred Concepts The acquisition process starts with a Mission Needs Statement MNS and possibly a threat assessment The MNS expresses in broad operational terms the deficiencies in current capabilities and opportunities available to provide new capabilities It should be stressed that the MNS should not specify the needs in terms that could limit its possible solution The threat assessment which is prepared and updated outside of the program acquisition function is most useful as a reality check to ensure that the concept being considered is needed and that it satisfies a valid requirement Using these documents as guidance both government and contractor IPTs should first concentrate on different concepts to satisfy the MNS and then developing these concepts for analysis 2 2 2 Analyze Concepts Conduct Tradeoff Studies and Define System Requirements After the concepts have been developed the next step is to analyze each concept in terms of performance cost schedule and risk and then to conduct tradeoff studies Advantages and disadvantages of each concept should be examined and documented The application of risk management processes planning assessment handling and monitoring is particularly 6 July 1998 12 IPPD Handbook important during Concept Exploration because this is when various program alternatives are evaluated CAIV objectives are established and the acquisition strategy is developed The proactive identification and management of risk is initiated at this point by commencing a risk management process and formulating a risk management plan Because of the pervasive nature of risk and the impact of risk-handling plans on other program plans and actions the IPPD concept of including all stakeholders is fundamental to successful risk management with IPTs playing a key role The tasks associated with each candidate concept need to be detailed sufficiently by knowledgeable and experienced personnel so that critical and high-risk efforts are identified as realistically as possible even though it is very early in the program’s life cycle Risk management in the IPPD environment is based on the systems engineering or concurrent engineering methodology where all aspects of the program from conception to disposal are examined early on in relation to each other Most risk management approaches have in common the practice of integrating design performance requirements with other life-cycle issues such as manufacturing operations and support The risk assessment performed on these candidate concepts and at all subsequent stages of the program is required for all major milestone decisions and contractual commitments and should continue throughout the program so that risk management activities can be included in program planning and budgeting See the Acquisition Deskbook Risk Management Organizational Structure for more information on risk management and IPTs at http www deskbook osd mil Part of the customer focus goal is to give the customer the best value in terms of both performance and cost Cost objectives are established at this stage using an IPPD approach with extensive customer involvement to ensure the objectives are realistic Using CAIV analysis an acquisition strategy can determine high-cost drivers and evaluate whether a change in requirements could yield a significant improvement in life-cycle cost while still meeting mission needs CAIV analysis results in tradeoff studies for cost and performance and the generation of cost performance curves Cost data used should include the costs of potential program impacts due to risk and risk management See the Acquisition Deskbook at http www deskbook osd mil for a discussion of CAIV and Chapter 7 for more information on cost modeling In an IPPD environment modeling and simulation can be used to maximum advantage in acquiring early learning and reducing risk Various modeling and simulation techniques can create virtual prototypes that make it possible to address producibility maintenance and support environmental and other life-cycle considerations in the Concept Exploration phase These techniques can help create affordable multiple concept designs that fully apply IPPD principles by helping in the tradeoff study process See Chapter 6 for more information on modeling and simulation tools Following the tradeoff studies the next task is to document the operational requirements of the item being developed acquired based on the tradeoff studies performed in conjunction with the customer This is traditionally documented as an Operational Requirements Document ORD An ORD contains operational performance parameters for the proposed concept system that defines the system capabilities needed to satisfy the mission need In the IPPD environment the ORD represents the requirements for all phases of the concept or system’s usage and defines these requirements in performance-based terms resulting from the CAIV analysis and 6 July 1998 13 IPPD Handbook cost performance tradeoff studies This whole process is iterative requiring two-way communication with the customer to come up with the right set of top-level requirements New data sometimes emerges during development that forces reexamination of the original ORD requirements e g a particular requirement turns out to be more expensive or harder to achieve than originally thought Once the top-level requirements are defined the program continues conducting tradeoff studies at lower and lower levels throughout the development to ensure that the right answer is achieved at each level To give designers the necessary flexibility to design the best system the ORD should contain the minimum number of requirements necessary and should be described in terms that specify the functions the system must perform without unduly constraining the system design these are commonly called “performance-specification requirements” Getting early and continuous customer input and participation throughout the process of determining system requirements can ensure completeness of the ORD and are essential for defining key performance parameters KPPs which are extracted from the ORD for the acquisition program baseline APB A key performance parameter is that capability or characteristic so significant that failure to meet the threshold can cause the concept or system selection to be reevaluated or the program to be reassessed or terminated More information on KPPs is contained in Section 4 2 2 As identified in Chapter 1 a proven method used to aid in requirements definition is Quality Function Deployment QFD QFD is a systems engineering tool that applies the IPPD approach to accomplish the requirements analysis objectives of Phase 0 QFD is a structured teamoriented planning methodology for translating the top-level customer needs into appropriate requirements at each level of product and process design More information on QFD is contained in Chapter 7 CAIV Tradeoff Study Cost Objective Examples Joint Strike Fighter CAIV was implemented on the JSF program by constructing in-depth requirements cost and performance tradeoff models down to subsystems and major components in order to set requirements and cost goals targets at the same time Only a few key performance parameters KPPs were defined and the customers were involved in the tradeoff studies An aggressive unit cost target was defined as “less than the cost of a current low-cost fighter These unit cost targets were included in the ORD and early RFPs Production cost estimates will evolve based on commonality demos and manufacturing process demos to validate process maturity The program funding was front-loaded to provide funding for the demos other cost reduction tradeoff studies and technology efforts For further information see http www jast mil Space Based Infrared Systems A customer-led IPT for the Space Based Infrared System SBIRS identified the major cost drivers—considering and evaluating customer utility A cost target was set in the ORD and Concept Validation RFP The customer and industry were involved in requirements cost and performance tradeoff studies to develop a set of affordable and achievable key requirements and set the KPPs For Engineering and Manufacturing Development EMD aggressive cost targets 6 July 1998 14 IPPD Handbook were part of source selection Contractor trades with government access will be conducted to minimize Total Ownership Cost TOC An innovative incentive fee splits cost savings per unit between the contractor and the government Approval cycles were reduced and the EMD RFP was streamlined from the expected 1 000 pages to 60 pages Contractors will participate in IPTs for management cost and contracts For further information see http www laafb af mil SMC MT sbirs htm Joint Air-to-Surface Standoff Missile Concept development phase studies Air Force Navy customer input and acquisition inputs formed the basis for early cost targets in the Joint Air-to-Surface Standoff Missile program A Contractor Day was held to request and obtain industry input All of this was used to set both development cost and unit cost targets The unit cost target in the ORD and RFP contained both objective and threshold unit cost values that were less than 50 percent of historical predictions In addition a bumper-to-bumper warranty is included in the unit cost target to cover TOC A procurement cost commitment curve is being used for early units with incentives for costs lower than the curve The Government will have on-line access to the contractor system for cost tracking For more information go to http www safaq hq af mil acq_ref stories jassm html 2 2 3 Define the Program Both the system or product requirements and the process for acquiring the hardware and software to satisfy these requirements i e the Program need to be developed The major tasks to be accomplished are identified along with a schedule by which to accomplish them In an IPPD environment providing an integrated plan and corresponding schedule helps the team members understand the work of their team within the context of the total program The acquisition strategy for the program includes activities that focus on identifying risk and riskhandling options and the development of life-cycle cost LCC or total ownership cost TOC objectives It also includes development of an integrated logistics support approach that enhances the overall value of the delivered product Additionally issues such as the type of contract the method of competition budget requirements and industry capabilities should be considered at this stage In an IPPD environment each of these items or issues is interconnected with the others and a balanced optimal solution will require consideration of all factors Such consideration can influence program success or failure—a significant reason for involving all the stakeholders including business contracts and budgeting personnel in the IPPD environment 2 2 3 1 Planning Tasks to be performed need to be organized in a way that enables the concurrent development of products and processes The IPPD philosophy incorporates the planning of engineering activities as well as other key management and functional processes such as manufacturing and support In an IPPD environment the process of defining the tasks should involve all stakeholders For example in the generation of a Test and Evaluation Master Plan TEMP contracting personnel need to consider the procurement of test assets the system designers need to design with testability in mind budget personnel need to plan for the required government- 6 July 1998 15 IPPD Handbook furnished equipment GFE and government-furnished material GFM to support test and the program office needs to ensure that the test strategy and key related events are reflected in the overall system acquisition strategy Thus these functions need to be included on the IPT developing the TEMP Any proposed task plan can be evaluated as an indication of the commitment to an IPPD approach For instance key manufacturing and supportability planning tasks should show up early in the program One way of defining tasks and activities to reflect an IPPD approach is the use of an integrated master plan Within an IPPD environment the integrated master plan provides an overarching framework against which all the IPTs can work It documents all the tasks required to deliver a high quality product and facilitate success throughout the product’s life cycle Cost schedule specific dates and non-essential tasks are not included in this plan During the initial stages of Concept Exploration the integrated plan is preliminary and its purpose is to provide an understanding of the scope of work required and the likely structure of the program It is constructed to depict a likely progression of work through the remaining phases with the most emphasis on the current and or upcoming phase especially the period to be contracted for next The integrated plan also serves to identify dependencies which may be performed by different organizations such as various contractors sources of Government Furnished Equipment GFE laboratories test resources etc within different portions of the total effort A preliminary integrated plan is developed principally by the government but includes industry inputs obtained through open communications with potential sources during the pre-solicitation phase of the acquisition When a solicitation is issued the government does not normally issue its entire integrated master plan to contractors It does however need to identify required delivery dates to support portions of the effort not required of the contractor as well as when the future contractor can expect deliverables provided by the Government including GFE from its other contractors Under Secretary of Defense for Acquisition and Technology policy is to maximize efficiency of defense acquisitions by maximizing contractors’ and subcontractors’ utilization of their commercial product facilities components and processes technical management and business whenever they meet DoD requirements and minimize DoD-unique requirements The Government issues a Statement of Objectives SOO or some other system requirements document that describes the functional performance requirements for the desired product The preparation of the integrated master plan the “how to do it” for the portion of the work required under a contract is left to industry respondents for inclusion in their proposal so that industry has the maximum flexibility to determine innovative streamlined solutions to the government requirements The program office and government integrating IPT should keep abreast of each major contractor’s integrated master plan but the integrated master plan should not be “placed on contract” as the delivery requirements of the contract should sufficiently define the contractors’ obligations to deliver products As the program is defined the integrated master plan is iterated several times each time increasing the level of detail and confidence at which all essential work has been identified The specific format for this plan is not critical however it usually reflects an Event Accomplishment Criteria hierarchical structure—a format that greatly facilitates the tracking and execution of the program In an IPPD approach functional and life-cycle inputs are required to integrate the product and associated processes produced by the program Without formal documentation such as an 6 July 1998 16 IPPD Handbook integrated master plan these inputs may be lost when personnel change Such a plan also defines and establishes the correct expectations 2 2 3 2 Scheduling Event-driven schedules and the participation of all stakeholders are the IPPD principles involved in developing a program schedule All stakeholders have to work against the schedule and all tasks need to be accomplished in a rational and logical order allowing for continuous communication with customers Necessary input conditions to complete each major task are identified and no major task is declared complete until all required input conditions and tasks have been satisfied When documented in a formal plan and used to manage the program this event-driven approach can help ensure that all tasks are integrated properly and that the management process is based on significant events in the acquisition life cycle and not on arbitrary calendar events Deriving the program schedule presents an opportunity to identify critical risk areas As IPT members estimate the times to complete specific tasks events that may cause delays will become apparent These events are potential areas of risk that the IPT should consider for further analysis One way to produce such a schedule is to develop an integrated master schedule based on an integrated master plan With an integrated master plan the integrated master schedule further helps the IPT members understand the links and interrelationships among the various teams The integrated schedule begins as an integrated master plan with dates—the starting points are the events accomplishments and criteria that make up the plan At a minimum an integrated master schedule shows the expected start and stop dates for each criterion in the plan but each criterion may be broken down into lower-level tasks that will be used to manage the program on a day-to-day basis The schedule can be expanded downward to the level of detail appropriate for the scope and risk of the program Programs with high risk show much lower levels of detail in the integrated master schedule in order to give the visibility to manage and control risk The more detailed the integrated master schedule however the greater the cost to track and update the schedule Under acquisition reform initiatives the dates in the integrated master schedule usually are not made contractually binding in order to allow the flexibility to take full advantage of event-driven scheduling In an IPPD approach an integrated master schedule performs the same job it always has—to track schedule variations But with an IPPD approach and when the integrated master schedule is tied directly to the integrated master plan the schedule also tracks the activities that provide functional and life-cycle inputs to product development In this role it provides a crosscheck not only that the inputs were obtained but that they were obtained at the right time Commercial standards EIA 632 and IEEE 1220-1994 can also be consulted for more information on developing master plans and schedules at http www eia org eng allstd index htm http standards ieee org 2 2 3 3 Managing Risk All acquisition programs involve risk The successful management of a program is defined by how that risk is managed The key to managing risk is an ongoing integrated risk assessment in which all aspects of a program hardware software test support fielding manufacturing 6 July 1998 17 IPPD Handbook human resources etc are examined for risk Doing this requires the involvement of all stakeholders in an IPPD environment This risk assessment becomes the basis for a risk management approach which may be articulated in a formal plan or in informal briefings or other documentation In either case risk management planning is a continual effort Program risks should be regularly assessed and the risk handling management approaches developed executed and monitored throughout the acquisition process DoD considers IPPD to be the focus of risk management It facilitates consideration of risks across functional areas and detailed investigation of critical areas and processes over the life of the program IPTs composed of all stakeholders continually review these critical areas to identify events that may adversely affect cost schedule or performance In support of a program’s risk management approach the IPTs should address critical cost schedule and performance risk areas and periodically reevaluate the program to identify new risk areas The risk management process is a formal up-front program planning process that assesses technical and programmatic complexity identifies associated risk and recognizes that risk drives the resources required to execute a program The risk management approach addresses all phases of the acquisition program from contracting and purchasing to technical issues covering the life cycle from development to disposal The IPPD fundamentals— multidisciplinary teamwork event-driven scheduling and total life-cycle planning with an emphasis on the customer’s needs—provide the necessary mindset and representation to accomplish an effective risk management program Detailed guidance concerning DoD risk management is contained in Paragraph 2 5 2 of the Defense Acquisition Deskbook which is available at http www deskbook osd mil and in the newly published Risk Management Guide published by the Defense Systems Management College Ft Belvoir Virginia 22060-5566 Additional information about risk management in the IPPD environment is titled “ASC Handbook for Integrated Risk Management” and is available from Aeronautical Systems Center ASC FMC Building 11A 1970 Third Street Suite 6 Wright-Patterson AFB OH 45433-7213 or at http www wpafb af mil az_public abb htm 2 2 4 Develop RFP for Phase I Once the program is defined and a balanced approach is derived from appropriate cost performance schedule tradeoff studies the next step is to develop an RFP Both contract language and contract incentives need to be written to encourage an IPPD approach without contractually imposing a series of approved recommended or best practices for applying IPPD Imposed practices become standards by implication and contractors would be hesitant to deviate from them for fear of being found contractually nonresponsive The desired contractor should already have established an IPPD culture and should not need steps for implementation RFPs consider all of the functional area requirements that have resulted from thorough valueadded tradeoff study analyses and discuss risk management and cost objectives The goal is to determine the minimum essential requirements that must be described in the RFP to enable the contractor to develop the best product Each proposed requirement must be evaluated for its value cost associated risks and alternative methods to achieve the same goal An integrated requirements evaluation typically finds that fewer requirements are needed than have 6 July 1998 18 IPPD Handbook traditionally been requested In the new environment of contracting using performance specification requirements rather than product specifications RFP requirements are stated in performance specification terms rather than in stipulated design parameters and “how-to” requirements embodied in detailed instructions or process specifications Care must be taken to build incentives into the RFP so that both the government and the contractor can benefit from implementing IPPD Since the development contractor will soon become a part of the team it is wise to allow prospective bidders to comment on the RFP while it is still in draft form Such participation can further refine the government’s goals and requirements by identifying contractor-known obstacles cost drivers and alternatives The final RFP should also explicitly state that contractors are allowed and encouraged to propose alternatives to any RFP requirement and any improvements to the product specifications When alternatives are proposed cost benefit analyses and associated risks should be conducted to determine their merits These alternatives may be unique to a specific contractor’s approach It is important for the government to inform potential offerors about the government’s IPPD concept of operation In the spirit of acquisition reform the government should not mandate processes however the offeror should be aware of how the government conducts business The government ascertains how the contractor’s product and process approach reflects a balanced life-cycle focus This information can be relayed by several methods including an executive summary attached to the RFP Commerce Business Daily announcements or a separate attachment to the solicitation A primary aspect to be evaluated in the offeror’s proposal is the approach presented to accomplish IPPD The government’s method of evaluating the offeror’s IPPD approach is part of the source selection process Therefore Section L the Instructions to Offerors should adequately identify the information that offerors are to provide in their proposals This is necessary for the government to evaluate how the offeror intends to integrate each critical process into an overall integrated management approach Offerors may include their integrated master plan and integrated master schedule to represent their approaches but to the extent required at all solicitations should require these only at higher levels of detail sufficient for evaluation of the approach rather than at greater detail levels which will evolve after award Along these lines the criteria in Section M the Evaluation Factors for Award should reflect the relative importance of IPPD Each program should tailor this language to fit the specific acquisition As a general approach the RFP should ask the bidders to explain how they intend to implement the IPPD principles in their program From this input the government can get a good idea of how well the contractor understands the principles of IPPD It should be noted that the blanket endorsement of every tenet may indicate a contractor’s lack of knowledge about IPPD Nearly every IPPD tenet must be assessed and applied selectively to the particular situation presented Contractors who fail to indicate that they will use common sense to tailor the application of IPPD to their environment may have missed the point The following paragraphs offer samples of RFP language referencing one aspect of the IPPD approach—defect prevention—as an example In this example the government is concerned with how the contractor will address the balance between the manufacturing process product design cost and risk during development 6 July 1998 19 IPPD Handbook Sample RFP Language Defect Prevention Example The following language is provided as guidance for the Statement of Work SOW or Statement of Objectives SOO “The government’s objective is for the supplier to define and mitigate the manufacturing process risks associated with the design solution through the development of producible designs capable fabrication and assembly processes and associated controls This includes activities such as the following 1 Developing and implementing an approach for the identification of key product characteristics Key product characteristics are the features of a material or part whose variation has a significant influence on product fit performance service life or manufacturability 2 Identifying manufacturing process risks e g the risks related to developing stable and capable processes to minimizing the need for engineering changes to preventing defects associated with the evolving design solution and developing and implementing appropriate design alternatives and risk reduction efforts ” The following language is provided as guidance for Section L “Propose and discuss any defect prevention practices to be employed for this acquisition To facilitate government evaluation methods provide rationale for each such method indicating how it helps to meet the SOO paragraphs on defect prevention Describe how key product characteristics will be identified and how existing manufacturing process capabilities are considered in the assessment of manufacturing process risks associated with the evolving product design Define how manufacturing process risk assessments are fed back to product design efforts to ensure that producibility considerations are included in the evolving product design ” The following language is provided as guidance for Section M “Proposed approaches will be evaluated based upon 1 The extent to which they employ disciplined structured processes versus ad hoc or anecdotal to identify and mitigate manufacturing process risks e g the risks related to developing stable and capable processes to minimizing the need for engineering changes to preventing defects 2 The extent to which the processes for identifying key product characteristics and identifying mitigating of manufacturing process risks are integrated with the overall systems engineering process 3 The extent to which the proposed approaches reflect the integration of manufacturing process risk reduction efforts into the planning for this program “ 2 3 Phase I Program Definition and Risk Reduction During Phase I Program Definition and Risk Reduction PDRR the most promising concepts investigated in Phase 0 are advanced the risks associated with these concepts are analyzed and the program requirements are refined sufficiently to enable the development of the most-favored design in Phase II Engineering and Manufacturing Development The following sections contain a discussion of the most important activities that take place and how IPPD tools and principles are applied during this phase’s activities 6 July 1998 20 IPPD Handbook There are usually two ways to conduct PDRR sole source or in a competitive environment More and more the PDRR phase is used to give competing contractor teams the opportunity to refine their concepts and generate substantiating data for their approach to meeting the customer’s requirements The government then conducts a source selection to evaluate the different approaches and selects one to continue into Phase II Engineering and Manufacturing Development 2 3 1 Evaluating a Contractor’s Proposal Selecting a Contractor Since IPPD is relatively new to some contractors they may be tempted to propose a theoretical IPPD approach with which they have no first-hand experience Or they may simply restate the IPPD evaluation criteria without making the internal cultural changes needed to operate using an IPPD approach A true representation of the contractor’s capabilities is of an even greater concern in an IPPD environment because more authority will be granted to the contractor with less contractual oversight The government’s evaluation approach needs to ensure that the contractor truly understands and can apply the IPPD approach It is important that the government evaluation team performs a thorough evaluation of each proposal becomes familiar with IPPD techniques and methods and what can realistically be done and looks closely at contractor past performance Things to look for in the proposal include— • A convincing system to collect and distribute information about the program reference Chapter 5 • A tailored application of the IPPD tenets that makes sense for the particular situation reference Chapter 1 • A management approach that shows the operation of empowered IPTs the effective delegation of authority and responsibility and the realistic involvement of all stakeholders reference Chapter 3 • A rational program and IPT structure that reflects the products and processes being delivered such as one based on the WBS reference Section 2 1 3 • A well-conceived program plan that shows the interaction of all required functional skills and life-cycle influences reference Section 2 2 3 1 • An event-based schedule that ties directly to the program plan reference Section 2 2 3 2 • A risk management process that is integrated into the program management system reference Section 2 2 3 3 • An integrated set of metrics and management tools that will be used to manage the program reference Section 2 1 8 and Chapter 4 • The effective and efficient use of modeling and simulation and virtual prototyping reference Chapter 6 • An integrated approach to cost modeling that can operate in near real time reference Chapter 7 6 July 1998 21 IPPD Handbook A good understanding of IPPD by the contractor team that prepared the proposal is not necessarily a guarantee that the rest of its company will support IPPD To assess the contractor’s potential it is good to review past performance records to see whether and how well the contractor has implemented IPPD on any similar programs 2 3 2 Executing Phase I The best leverage to encourage IPPD performance after the contract is awarded is an incentive or award fee that is based partially on the implementation of the IPPD tenets Use of this approach should be part of an integrated contractual strategy that is designed to encourage and reward the elements of performance that are most important to the customer In this environment the role of IPPD performance is therefore a supporting one The contract deliverables e g a ship a plane a process are what the customer really desires from the contract IPPD is important because it can increase the chances of customers getting what they want when they want it and at the price agreed to A program that chooses to reward IPPD performance must however structure the incentive in such a manner that the rewarded performance actually contributes to the delivery of the product or process required by the contract Creating this incentive structure can be difficult and it is useful to discuss it with industry either during the pre-solicitation phase or by having the bidders propose an incentive arrangement in their proposals Soon after the contract is awarded or even earlier in a noncompetitive situation the government and contractor need to discuss plans to execute the contract in terms of work scope schedules and resources This is referred to as a performance measurement baseline Since the goal is mutual understanding with identification of risk as a critical element various IPTs provide input to the baseline At the program manager’s discretion the appropriate-level IPT then participates in an Integrated Baseline Review Once the integrated plan including the performance measurement baseline is in place its execution is managed using the contractor’s earned value management method More information on Earned Value Management and the Integrated Baseline Review can be found at http www acq osd mil pm 2 3 3 Transition to Next Phase The transition of a program from one phase to the next is a good time to reassess the status of the program’s IPPD implementation Moving from Concept Exploration to PDRR or from PDRR to EMD will change the relative importance of the IPPD tenets For example in Concept Exploration the program may have placed great weight on customer involvement proactive risk management and early life-cycle planning requirements In PDRR where the work is increasingly detailed other tenets such as robust design and event-driven scheduling increase in importance although IPTs will continue to identify and analyze risk areas IPTs will spend considerable effort monitoring mitigation plans that are designed to reduce risk that was identified in the Concept Exploration phase This change in program emphasis may require adjustments to program guidance or additional refresher-type training for IPT leaders and members Each case is different but it is helpful to review the tenets and ensure that each is getting the attention warranted for the new phase of the program 6 July 1998 22 IPPD Handbook As the program transitions to later phases the IPPD structure and composition of the IPTs also may need to be revisited for appropriateness For each phase the activities to be accomplished during the phase need to be defined and the stakeholders required to accomplish these activities need to be identified The stakeholders should then form the IPTs that are built around the activities A redefinition of IPT objectives to correspond with the objectives of the new phase may trigger a change in the IPT organization Moving from Concept Exploration to PDRR is the starting point for the first full-up IPT organization on the program This is the point at which the initial IPT which led the concept exploration establishes and staffs IPTs for each of its major products and processes This also coincides with the formal creation of a Program Office The change from PDRR to EMD may not be so dramatic but IPT functional memberships still may have to be adjusted and IPT charters will still need to be reviewed for EMD application One change usually seen in any program delivering hardware is the creation of an IPT charged with Producibility and Production Planning and or Implementation The transition from EMD to Production Fielding Deployment and Operational Support will normally be the first time the Program Office will begin to shrink in size IPTs that were heavily tasked during the development and test efforts will find that their responsibility transitions to a sustainment role More logistics expertise and less engineering support will be needed Some IPTs may even disappear completely with their residual tasks being assumed by another existing team or a newly formed follow-on team The IPPD tenets will again shuffle in importance as the development emphasis moves to a focus on efficient manufacturing and cost-effective support This is where the early IPPD work can really pay off IPPD organizations are supposed to be flexible and responsive If they all were in fact like that changes driven by moving from one phase to the next would be anticipated and phased in as needed and there would be no unique change caused by transitioning Unfortunately very few organizations are that proactive Programs should force themselves periodically and at every transition point to reexamine their IPPD implementation and make the necessary adjustments to keep them current and active Before a program can proceed to the next phase risks must be well understood and risk management approaches well developed A variety of techniques exist to aid in the IPPD approach to managing risk To ensure an equitable and sensible allocation of risk between government and industry a contracting approach appropriate to the type of system being acquired should be used for all phases of the system’s life cycle Objectives and thresholds for cost schedule and performance should be refined as the program matures consistent with operational requirements 2 4 Summary of the Application of IPPD in DOD Acquisition IPPD is a methodology and a set of processes and tools that are continuously being developed and refined This chapter has presented many ideas and examples for the application and development of IPPD within Phases 0 and 1 of the acquisition process Most of the concepts and tools discussed carry over into the subsequent acquisition phases 6 July 1998 23 IPPD Handbook The following are the most important issues related to the successful implementation of IPPD • The early participation of all necessary disciplines and stakeholders including the customers to completely define the requirements and analyze the products and processes as they are developed • A commitment at all levels to a multidisciplinary team organization that is appropriately structured empowered and held accountable • Early investment in a seamless information infrastructure that is accessible to all parties involved integrated across all development acquisition functions and has adequate safeguards to ensure data security • An emphasis beginning early in development on exploration of alternative design concepts • A risk management program integrated into all activities of program planning and throughout all program phases • A continuous focus on life-cycle requirements Two closing points are worth noting before we move on to a discussion of teams First IPPD is not something that can be created and then left to function on its own It takes continuous attention and constant reinforcement Second for a variety of reasons a program may not be able to implement every IPPD practice as thoroughly as it would like In this situation the program should implement as much as it can then keep the pressure on to continuously improve the IPPD environment The remaining chapters of the handbook Chapters 3 through 7 contain information on teams and tools useful throughout the life cycle 6 July 1998 24 IPPD Handbook Chapter 3 Team Best Practices for IPPD This chapter focuses on building a cohesive product process team or Integrated Product Team IPT that functions efficiently and effectively The important thing to remember is that each IPT in IPPD has a mission to develop and deliver a product and its associated processes At the program level IPT characteristics include— • Responsibility for a defined product or process • Authority over the resources and personnel • An agreed schedule for delivery of the defined product • An agreed level of risk to deliver the defined product • An agreed upon set of measurable metrics This chapter supplements two other documents on IPTs published by OSD Rules of the Road— A Guide for Leading Successful Integrated Product Teams was published in November 1995 Intended for use within OSD it addresses the two highest levels of IPTs Overarching IPTs and Working-Level IPTs The DoD Guide to IPPD published on 5 February 1996 covers Program IPTs which exist at the Program Management Office PMO level and below 3 1 Definition of a Team Jon R Katzenbach and Douglas K Smith have defined the characteristics they believe a group of people must meet to be considered a team A team is a small number of people with complementary skills who are committed to a common purpose set of goals and approach for which they hold themselves mutually accountable 1 DoD Directive 5000 1 describes an IPT as follows The Integrated Product Team IPT is composed of representatives from all appropriate functional disciplines working together with a Team Leader to build successful and balanced programs identify and resolve issues and make sound and timely recommendations to facilitate decision-making Katzenbach and Smith further characterize teams as “…people with complementary skills who are committed to a common purpose set of performance goals and approach ” IPTs should contain members who represent all the stakeholders necessary to ensure that all customer requirements and functional concerns are represented and addressed up front in the developmental process Finally and most important for obtaining a quality product from an IPT Katzenbach and Smith note that team members should “hold themselves mutually accountable ” If team members feel a personal responsibility only for the portion of the product that they themselves produce then the group consisting of those individuals is not a team In contrast a team that has been 1 Jon R Katzenbach and Douglas K Smith The Wisdom of Teams Creating the High-Performance Organization Harvard Business School Press 1993 6 July 1998 1 IPPD Handbook energized with a common purpose and fellowship tends to generate the atmosphere of trust and cooperation necessary to make the whole greater than the sum of its parts 3 1 1 Team Size Katzenbach and Smith define a team as “a small number of people ” ideally no more than 12 This school of thought is supported by an IPPD survey that DoD conducted in 1995 in which 50 percent of the respondents said the best team size was 10 or less—another 25 percent said 20 or less Katzenback and Smith also state that when assembled groups of people become too large to function as a single team they tend to break up into smaller informal groups that then become separate teams from the rest of the group Because they are informal groups they may have a tendency to become disconnected from the main program unless the team leader carefully monitors them One solution is to set up the IPT structure at the start so that team size stays within reasonable boundaries thus avoiding the risk of informal teams being created Another approach is to recognize when informal teams are forming and if it makes sense to formally incorporate them into the program structure with a charter budget assigned responsibilities etc Yet a third option is to allow them to operate separately but watch them closely to ensure that they do not become “Independent” Product Teams This last option takes the most effort and is least desirable since it requires the Leader to manage this group slightly differently from the rest of the program The most important thing to remember however is that having the appropriate stakeholders on the team is the essential ingredient for an IPT The team should not be limited by an arbitrarily set target number for members but it should be limited to the minimum number of stakeholders needed to accomplish the work In addition the larger the team the greater the leadership skills required to manage the team For very large or joint programs this could possibly involve a large number of people 3 1 2 Team “Hierarchy” Keeping the teams to a manageable size often requires a sort of “hierarchy” of teams The term hierarchy is used here not in the sense of “power structure ” but in the sense of creating a tree structure team of teams The term hierarchy in this sense does not apply to the status of the teams or team members but rather to the relationships among the teams and how these relationships correspond to the product and process definition responsibility Most programs have at least two levels of IPTs a top level or system IPT and sub-tier IPTs for each of the major products or processes that make up the program In a large program the breakout of responsibilities can lead to several layers of IPTs each with its charter and clearly defined product or process An example is an aircraft program where there may be four or five levels of IPTs in parallel with the product breakout—top level is the Weapon System followed sequentially by the Air Vehicle the Avionics the fire control system etc —similar to the WBS The final decision of IPT organization belongs to the Program Manager who makes this judgement after consultation with the members of his or her team 3 2 Team Leader Each team must have a team leader who is usually selected by the Program Manager Director In programs with two or more levels of teams the team leader is the link to the next higher-level team The team leader should be the best-qualified person for the job based on experience and 6 July 1998 2 IPPD Handbook interpersonal skills Rank or position should not be considered a criterion for selecting a team leader however large differences in rank will most likely cause a team leader of junior rank to defer to senior ranking members Team leaders must ensure that junior team members are not silenced or intimidated by more senior members The duration of an appointment as team leader will vary with the type of team being formed Teams with a short or fixed life span are likely to have only one leader On long-term teams however the role of the leader and hence the person filling the position may change as the product matures The following are some responsibilities of the team leader • Lead the team • Negotiate staffing and participate in team member selection • Ensure balanced participation within the IPT • Ensure that decisions are made when required • Resolve disputes • Reinforce IPPD and IPT principles • Support and reward IPT members • Ensure integration with other teams • Ensure compliance with the team charter • Ensure that team members are trained 3 3 Team Member Selection and Negotiation IPT members are selected based on a number of criteria but most important they should be a stakeholder in the product or process being developed i e they should be from a functional discipline that has a stake in the outcome Selection of team members for IPTs often lies outside the direct control of the IPT leader—member selection usually occurs in a negotiating process between the team leader and the functional leaders When a large program has many levels of teams or when it is competing with other programs for team members limited availability of personnel and constraints on the personnel system can encumber the selection process It is human nature to want the “best” people on your team—those all of their technical problemsolving and interpersonal skills finely honed In reality however there are generally not enough “bests” to populate all the teams Teams may have people assigned to them for whom the team leader and the functional leader have to have an understanding of the individual’s shortcomings Together the two leaders need to establish how they will each counterbalance these shortcomings with their own flexibility in time and resources until the individual does meet expectations required to be a fully functional member of the team In the mean time if the team leader is well-trained and can create a positive energetic environment he or she can improve the performance of most team members Furthermore a candidate team member’s enthusiasm and willingness to participate can frequently overcome weaknesses in other areas 6 July 1998 3 IPPD Handbook The functional leader also needs to consider if a candidate team member is a good link to their functional equivalent in the next higher IPT When issue resolution needs to progress to higher levels it is important that the team member has communicated the issue to both his or her functional leader and the functional equivalents on the higher-level teams Such team members understand their responsibility to their functional hierarchy as well as to the IPT It is obviously important to select people who have the time to meet and conduct the probable work of the team Some of the people who are critical to system design or the process under study do not always have the time necessary The team leader needs to negotiate with the functional leaders to help them allocate time to the team— all affected functional areas need to be represented on the team for it to function properly In reality there probably will be instances when some functional leaders are unable to provide representation to an IPT Different phases of a program need different expertise and the team leader must compensate if the expertise is not immediately available in a team member In any case IPT assignments should be discussed and negotiated with functional leaders to get the best personnel mix on the team or ensure the expertise is available Additional selection criteria are discussed in the following sections 3 3 1 Technical or Functional Expertise When a system is being developed a variety of stakeholders are required in order to incorporate all essential functions on the teams It is important to include logisticians customers manufacturers maintenance personnel and others as well as engineers to ensure that all needs are met Without proper representation of the necessary functions a team can produce less than optimal products or possibly even unsuitable results Program managers or IPT leaders should determine in advance the technical qualifications needed in potential team members to accomplish the IPT’s task assignment One way to approach this is to assess the risk in the different areas of the program and seek more experienced personnel for assignments in the higher risk areas 3 3 2 Problem-Solving and Decision-Making Skills Problem-solving and decision-making skills are often difficult to assess without knowledge of the person’s previous work performance This is an area where the functional leader should be able to advise the team leader for the purpose of assigning a person to the team However in many cases the leader must simply take the time and opportunity to closely observe an individual team member at work and in interaction with other members Unlike the technical or functional expertise described above assessing a team member’s ability to solve problems and make decisions is difficult and will probably become apparent only when there is a need to conduct tradeoff studies or make decisions on how to proceed with the program To augment or reinforce these skills training in problem-solving and decision-making skills can be provided 3 3 3 Interpersonal Skills Strong interpersonal skills of members assist the team in communicating effectively Although interpersonal skills seem an inherent trait of a person good communication skills can be taught 6 July 1998 4 IPPD Handbook at the time of team conception and applied throughout the life of the team In addition constructive conflict may be channeled into potential solutions to problems through the ability of members to relate to each other and draw on the expertise each member brings to the table 3 3 4 Ability to Work Effectively in an IPPD Environment In addition to being committed to an IPPD philosophy and its successful implementation in the program IPT members should be able to operate in a somewhat free-form and flexible environment often with more than one “boss ” This is a really important characteristic to bear in mind because some people need a great deal of structure and try as they may do not flourish as effective IPT members Again this ability or lack thereof may not be apparent until some time into the program but a team leader must be cognizant of the potential problem 3 4 Team Dynamics After the IPT organization is defined and membership assigned the team dynamics need to be developed by taking the following steps • Define team goals for each specific IPT and common goals for all of a program’s IPTs Team goals should reflect program objectives and be geared toward the product the team is responsible for delivering Remember that the product may actually be a process see Process discussion in Sections 1 1 and 2 1 3 By specifying performance objectives for the team in terms that are clearly understood by all a venue is created that allows for clear communication and constructive criticism These objectives should lead to common goals that are defined in unambiguous terms Once objectives and goals are defined the IPT members should begin to focus their thoughts as a team • Define the reporting structure of and working relationship among all IPTs In addition to reporting within and among the IPTs team members also have a responsibility to report back to their functional organization’s leadership and management • Define the level of empowerment of all IPTs The IPTs need to have authority in line with their goals and objectives in order to make decisions for the product that they are responsible for delivering The team as a whole needs to be empowered to make decisions within the authority defined in the team charter see below IPT empowerment however is not a blank check to do whatever the team desires Every team must operate within some constraints and these limits on authority must be identified and defined up front For example all IPTs in a program have certain cost and schedule constraints Additionally an IPT may be constrained by the need for its product to interface with other parts of the program product or to adapt to an existing system that is already fielded These constraints are simply reflections of the real world of acquisition but if they are not identified for all to see IPT members may not understand their level of authority to accomplish their goals and objectives In addition to team empowerment individual team members must be empowered by their respective functional leadership managers to make decisions When authorities outside of the team membership have the power to make decisions that affect the team-chartered 6 July 1998 5 IPPD Handbook responsibilities the IPT concept is severely compromised This does not mean that team members must abandon their organizations’ interests and goals rather they must be thoroughly cognizant of their organizations’ objectives and empowered to speak for their organization—even to commit the organization during team decision making This authority also requires that team members keep their functional organizations apprised of team actions It also means that a team member will often have to consult with their functional leadership management before committing to a major team decision Team members who have the authority to make decisions must be willing and able to do so when required and accept the responsibility for reporting those decisions back to their functional leadership management A perceived lack of empowerment is not uncommon according to more than one DoD survey Team leaders should address concerns with the functional leader s of the members involved or with the next higher IPT to solve the problem If this does not work and team members have to operate without empowerment then the team is not an IPT but just a traditional working group operating outside the IPPD concept • Define the relationship between government and contractor personnel Along with defining the relationship of an IPT to the other IPTs on the program there is a need to address the relationship between government and contractor personnel on the same team In order to understand this relationship it may be necessary to have some open honest discussions between the two groups Prior to this discussion the upper level management of the two teams will most likely need to have an agreement that can then be factored into the discussion of the two groups Each must understand what the other’s critical objectives are For example a legitimate critical objective for contractors is to return a profit to its company Government team members must recognize this as a prime motivator for their contractor counterparts on the team A critical objective for the government is almost always to deliver the defined product at the price and schedule agreed to By combining these two motivators the IPT objective becomes on-time delivery of the specified product at cost and in an efficient manner that provides a fair profit for the contractor The addition of the “fair profit” motive to the government objective can help ensure a very critical team-wide sensitivity to any unplanned or unnecessary work on the contract There may be other differences between contractor and government needs—some objectives may be coincident while others may be exclusive The way to address these differences is to focus on common rather than separate interests These interests need not interfere with the goals of the team The challenge is to adapt them so they reinforce the team goals The success of an IPPD organization is attained when all parties involved benefit from the organization’s output Further information guiding government personnel participating on contractor-led IPTs is contained in Section 2 1 2 3 4 1 Team Charter The best way to minimize team misunderstandings is to document the team dynamics in a team charter for each IPT An IPT charter should include the following items • The mission and objectives of the team including top-level schedule if applicable • The metrics by which the team’s progress will be evaluated 6 July 1998 6 IPPD Handbook • The scope of the team’s responsibilities • The relationship of the team with other teams reporting structure interfaces • The authority and accountability of the team empowerment • The resources available for the team • A team membership list by function organization All affected stakeholders and their management should help develop the charter and the Program Manager Director approves it This participation or buy-in to establish the IPT and document the roles and responsibilities of the IPT helps cultivate a cooperative and collaborative working environment and eliminates or at least mitigates many of the problems that could be encountered when operating in an IPPD environment Examples of such problems are as follows • Lack of direction or vision that causes an IPT to constantly try to define its objectives • Power struggles between the IPTs and management or organizations outside the IPT • Infighting among IPTs because of ill-defined roles and responsibilities The team goals should be written to minimize conflicts resulting from misunderstandings or hidden agendas Conflicts of interest and goals among the team members should be resolved early in the development of team charters Examples of conflicts include the natural conflicts between customers and contractors or among multiple contractors with conflicting business interests Once established IPT charters need to be frequently reviewed as an acquisition program progresses to ensure that they remain in line with changing program goals Figure 3-1 is an example of an IPT charter 3 4 2 Team Unity and Issue Resolution The key to good teamwork is the successful realization of team unity The team acts as one understanding the strengths of each of its members and using this knowledge to pursue the team’s mission and the success of the program Because of the many different traditionally competing functions involved in IPPD teams team unity could prove a challenge In some cases members may attempt to maximize their functional area at the expense of the system under development In other cases functional representatives may feel they have personal experience that outweighs group consensus In these instances the IPT leader will be faced with a situation that needs to be resolved early in order to avoid dysfunction in the IPT 6 July 1998 7 IPPD Handbook IPT Name Level of IPT IPT Mission Objectives Provide an overall description of the mission Describe specific objectives required to accomplish the mission Metrics Describe specific metrics that measure objectives described above Scope of Team’s Responsibilities Provide a description of the work to be accomplished can be SOW Include key requirements schedule output s required such as communications requirements like periodic informal reports etc and budget cost authority Scope of Team Members’ Individual Responsibilities Leader’s Responsibilities please list Member’s responsibilities please list Team Membership by Discipline Function Name Function Competency Workyears Customers Interfaces Identify all agencies and names of key people Authority Accountability Identify key authority and accountability required to accomplish successful IPT activity This includes cost schedule and technical performance Review and Approval Process Date of Approval ________________ Will be reviewed annually Submitted by___________________ Approved by Team Leadership signature signature signature Figure 3-1 Sample Charter F A-18 Program Team 6 July 1998 8 IPPD Handbook The power of team unity pulls together the knowledge skills and attitudes of each individual At the same time the discord that so often impedes group meetings is suppressed to ensure positive momentum toward group consensus and the selection of win-win solutions to problems Though it is an ideal and often difficult to fully achieve team unity does contribute to the optimization of a team’s capabilities when the following principles are followed • All team members must be stakeholders in the mission of the group • All members must be empowered and capable in their functional discipline • All members must feel free to make suggestions • Members must trust one another especially when sensitive issues surface • The team must desire consensus and remain focused on team goals • All members must actively seek win-win solutions to problems True consensus occurs when all the team members can live with the solutions although they may not be everyone’s first choice To facilitate this process of consensus building team members must try not to be locked in by old paradigms They should strive for innovation—to “think outside the box”—and should not be afraid to voice concerns Thus an operating rule that many IPTs find useful is “Don’t shoot the messenger ” To gain the most from the IPT environment a team must find out about “bad news” immediately That way the team has the maximum potential to correct the situation while it is still manageable IPTs must seek out any negative data concerning their product and should encourage members who discover a problem to bring it to the IPT as soon as possible whether or not the member believes it can be controlled Therefore a team member who brings negative news to the team cannot be attacked rather the team member should be praised This is not the traditional organization’s approach to bad news A strong commitment from the team leader and each team member is required to ensure that the IPT has good open communication While team unity is strongly encouraged an IPT should not become so focused on its own product that the members forget to coordinate and integrate with the other elements of the system This is when an “Integrated” Product Team becomes an “Independent” Product Team Team members must recognize that their responsibility is to deliver a product that contributes to the optimum total system and that building the world’s greatest widget is useless if it doesn’t support the rest of the system Therefore when an issue does arise for which the team cannot reach consensus that issue should be taken to the next higher level in the hierarchy of teams—the next tier up In general this would be to the team that is the customer for the sub-tier team’s product Unresolved issues can go up the chain for resolution however every effort should be made to arrive at consensus decisions at the lowest team level possible 3 4 3 Compensation A quick way to undermine the success of the team is to reward individuals in a way that discourages them from helping other team members Traditional systems such as suggestion programs ranking employees for pay raises and individual performance appraisals can subtly 6 July 1998 9 IPPD Handbook discourage teamwork and encourage individuals to watch out for themselves Compensation and pay raises must be linked to team performance In addition the team leader can ensure that the personnel who contribute most to successful teamwork get the recognition and rewards due to them While compensation for civilian personnel is usually monetary methods for compensating military personnel need to be consistent with the military system such as awards and decorations or training opportunities for individual professional development Compensation Example F A-18 The F A-18 Program Team rewards its members based on competency and the accomplishment of team-related objectives Indeed team-related work objectives carry the most weight Generic factors for team performance workplan objectives are as follows For Team Member For Team Leader • Meets team deadlines with quality product • Meets under budget • Keeps team informed • Logical clear concise task delegation • Committed to the team and team goals • Encourages innovation • Respects programmatic issues • Uses team effectively in decision making • Provides competency expertise • Meets team deadlines • Timely annual performance inputs Extracted from the F A-18 Program Team PMA265 Program Operating Guide 15 November 1996 3 5 Team Meetings Team meetings need to be structured for efficient and effective decision making Individual roles and responsibilities agendas ground rules and the frequency of meetings need to be determined upfront in team planning Suggestions for these are given in the following sections 3 5 1 Roles and Responsibilities Team meetings need to have a team leader Meetings also function best with a recorder and a facilitator if possible Team Leader The team leader runs the meetings and has the following responsibilities • Calls the meetings and develops the agenda • Focuses on the content of the session • Uses team effectively in decision making 6 July 1998 10 IPPD Handbook • Resolves disputes to make sure decisions are made • Encourages balanced participation • Provides logical clear and concise task delegation • Assigns and tracks action items • Maintains all of the official meeting records • Arranges for administrative support i e reserve the meeting room distribute the agenda record the minutes of the meeting and set up the video teleconference VTC if necessary • Ensures attendance of IPT members critical to the discussion points on the agenda Recorder The recorder chronicles the highlights of the meeting any action items that develop during the meeting and other important discussion points It is usually not necessary to keep verbatim minutes but if it is deemed necessary a professional recorder should be added Normally however the recorder will simply keep track of major items and document the highlights and key decisions Facilitator Early in the life of an IPT it is useful to designate a facilitator to monitor team meetings to ensure that the team operates in an IPPD manner and to observe the rules established by the team The facilitator focuses on the conduct of the meeting rather than the content and ensures that the focus is maintained and the appropriate team-building techniques are employed It is helpful however if the facilitator has some technical understanding This helps a facilitator to determine what is important and to formulate directions to guide the team The facilitator also serves as quality advisor to the team and can help with administrative tasks Having people available to act as a facilitator is sometimes difficult however one person can facilitate many teams and contractors often have human resourcetype people who can function in this role It is also a role that can be contracted for However if an outside facilitator is used part of their job should be to put themselves out of work by enabling the team to do its own required facilitation through internal process monitoring 3 5 2 Agendas An agenda should be prepared prior to every meeting and distributed in advance of the session It is particularly important to distribute the agenda well in advance of the meeting if advanced preparation is required of the membership The IPT leader sets the agenda however administrative personnel can aid in its preparation and distribution 3 5 3 Ground Rules Establishing ground rules by which all meetings will be conducted should be one of the first items on the team’s agenda for the first meeting The team must view these rules as inviolable 6 July 1998 11 IPPD Handbook and everyone must understand and agree to all of the ground rules The most critical rules pertain to the following • Attendance • Discussions “no sacred cows” • Confidentiality no retribution or “poisoning the well” with those outside of the team • An analytical approach use facts to support decisions • End-product orientation everyone gets assignments and does them • Constructive confrontation no finger pointing • Participation of all members Some basic rules for team members to follow during meetings include— • Listen to others’ ideas without judging • Question ideas rather than questioning people • Ask for expansion or clarification of ideas • Contribute to but do not dominate the conversation • Look for answers without losers win-win solutions • Avoid disagreements—look for something good or something to build on in every idea • Avoid debating or fighting for an idea that appears to be inappropriate • Review frequently and summarize ideas as you see them • Stay focused--do not jump ahead • Get on board and work to implement it when you’ve had your say and the decision has been made Additional ground rules can be found in Rules of the Road at http www acq osd mil ar doc taba pdf 3 5 4 Meeting Frequency How often a team meets depends upon the team’s mission Essentially there is no set frequency for IPT meetings Meeting frequency will be determined by the team and team leader To avoid unproductive time spent in meetings all team members must arrive at meetings fully prepared to take action and make decisions according to the set and pre-distributed agenda 3 6 Team Training Team training is a very important aspect of IPTs The appropriate training at the appropriate time can increase the effectiveness and efficiency of a team Training comes with the added cost of the member’s time but it can pay significant dividends at a later date when the team accomplishes tasks more quickly Listed below are some common types of training that might be offered to teams All of the courses listed except for product-specific training are offered by 6 July 1998 12 IPPD Handbook the individual Services many universities and colleges and a variety of commercial offerors who specialize in these types of training 3 6 1 Team-Building Training Team-building training is oriented toward the quick formation of a group of individuals into a team It focuses on exercises designed to engender trust cooperation team goal attainment and communication among team members Participants learn teamwork by taking part in challenging exercises and role playing By practicing the principles taught in a group environment team members become familiar with each other They learn the strengths and weakness of the other members in order to learn how to function more efficiently as a team Informal training programs can be conducted locally and then reinforced during regular team meetings by using team-building exercises given by trained facilitators This may be a quicker less expensive method of conducting team training if time is considered a critical factor for team members 3 6 2 IPPD Training IPPD training is an important part of each team’s training program At a top level IPPD training covers the application of DoD’s IPPD tenets and provides examples and suggestions on how to implement the approach It provides a good general background for someone who has not been exposed to IPPD and acts as an effective refresher for a team member who has been away from IPPD for a while Additional training educates team members in tools and processes Tool training focuses on key tools and how and when they are used Process training is centered on process development process improvement and the development and use of metrics to monitor or improve processes Team members learn how to make analysis charts and conduct process analysis IPPD training often includes lessons in Total Quality Management TQM and the principles for creating quality products Course content is likely to vary depending on who is offering the training Team leaders should be the first ones trained in IPPD principles and should also be capable of determining the level of training required for their team For more information on IPPD training visit the Defense Acquisition University DAU homepage at http www acq osd mil dau See also the DoN-sponsored IPT Learning Campus CD resource guide http www acq-ref navy mil g-tools html 3 6 3 Information Technology Training Despite the fact that computers are everywhere not everyone is knowledgeable or proficient in their use Team leaders can assume that team members’ collective computer skills will range from non-existent to exceptional But even proficient members may find that the selected software is foreign to them For these reasons teams should be given an appropriate level of training to ensure that electronic information transfer is used to the maximum extent possible This will also aid in ensuring that the data transferred between team members is usable by the other members 6 July 1998 13 IPPD Handbook 3 6 4 Product-Specific Training Product-specific training is usually conducted as needed Not all teams will require in-depth knowledge of a product to effectively accomplish their charter Those that do will usually have this training provided by the contractor developing the product or by a member of the Program Office who is sufficiently knowledgeable to conduct the training This particular type of training is generally of a technical nature It may be a lesson in the capabilities of a new technology the special handling requirements for a particular component or disposal requirements for anticipated byproducts from the use or disposal of the system Whatever the nature of the system it is important that all members of the team have the same information if it impacts the mission of the team 3 6 5 Systems Engineering and Analysis Training Team leaders may find it advantageous to conduct some team training in the area of systems engineering or systems analysis Some team members may be very familiar with methods for conducting analyses tradeoff studies and assessments while others will be unfamiliar with the methods Therefore this training should be conducted as needed to familiarize team members with such areas as risk management risk assessment tradeoff studies and cost performance analysis Since cost performance analyses and tradeoff studies are crucial to effective IPT decision making training in these areas can be very valuable Each member needs to understand the procedures used to conduct analyses including the relative importance of all of the variables used in a particular method and how they affect the outcome of that methodology Tools and methods are most effective when all members understand their value and use 3 6 6 Facilitator Training If a professional facilitator is not available facilitator training for one or more team members is important because it enables the team leader to focus on the content of the meeting while the facilitator focuses on context A facilitator can assist the team by helping the team leader to plan and run meetings use team-building techniques to develop trust and cooperation enhance team communications focus team discussions and deal with problematic team members Facilitators are also trained in building and interpreting various types of analysis charts such as Pareto charts flowcharts and cause and effect diagrams 3 7 Team Membership and the Government Role With IPPD the government needs to be actively involved as a customer and a team member from the start of an acquisition program The government can function as a leader or as a participant but should not assume the traditional role of oversight The government role in IPPD is to structure a program that gives the contractor the highest possible probability for successfully delivering what the customer wants and then helping the contractor to achieve that success In this way all parties should achieve their goals—customers get what they need and contractors’ companies make a profit The contractor often leads the development of products and processes with government personnel as members of the IPTs Government personnel functioning on contractor-led IPTs need to be familiar with the contractor’s processes and business practices and avoid trying to 6 July 1998 14 IPPD Handbook change the contractor’s methods to reflect government methods Such familiarity increases the likelihood that government IPT members will be treated as positive additions to the team Moreover because the success of the program depends on the success of the contractor all team members need to work to make the contractor a success This requires a major change in the mindset of government personnel whose former role was usually one of regulation and enforcement The new environment becomes one of incentivized performance where both the government and the contractors work together and share the benefits The following is an example of the “Program First - Contractor First” mindset Government Contractor Role Example Advanced Deployable System ADS Program The following is the Navy’s ADS Program Manager’s vision as stated in his Program Management Plan The Contractor is the key to our success We intend to work cooperatively to develop an affordable shallow water surveillance capability The Government team will strive to ensure that the Contractor understands the requirements The Government team will provide added value to the Contractor’s efforts The following excerpt from the LPD 17 homepage illustrates both the oversight function being replaced with active government participation in the program and the importance LPD-17 places on including all stakeholders right from the beginning of an acquisition or development program Government Contractor Teams Example LPD 17 Earlier ship acquisitions have employed systems engineering principles to include the operator but often these efforts would gear up precisely when the design integration and construction phases were entering a period of minimal flexibility—4 to 7 years after contract award In contrast Team 17’s process relies on mission teams to define the overall operational context for a new surface combatant The mission teams include representation all the way across the shipbuilding-customer base the Office of the Chief of Naval Operations the Marine Corps the fleet commanders other services and the organizations that regularly study questions of warfighting More specialized development and support teams composed of representatives from the systems commands and design agencies contribute by translating operational context into specific shipbuilding technology Coordination is facilitated by a “virtual team” approach that uses computer technology to link geographically dispersed work centers for continuous interaction For further information see http lpd17 nswc navy mil exwar html Government personnel participating on a contractor-led IPT need to recognize that while they are assisting in developing solutions the contractor is responsible for contract performance Should the contract requirements performance requirements schedule deliverables testing etc require modification such modification must be effected only through formal modification of the contract by the government contracting officer Direction provided to the contractor by government personnel which constructively changes the terms of the contract is prohibited 6 July 1998 15 IPPD Handbook 3 8 Final Thoughts on Team Best Practices for IPPD An IPT structure is not something that can be set up and then allowed to function on its own It is not self-sustaining Personnel will move into and out of the group the status of the program will change over time and the personalities of the team may evolve as well For these reasons it is imperative that the IPT spirit be constantly nurtured and reinforced When the IPT ground rules are permitted to slide the team members will instinctively revert to what they know best which in most cases is the traditional stovepipe structure An IPT will at least to some degree be constantly subjected to these traditional pressures to some degree and must be diligent in its efforts to overcome the hurdles An inability to implement all the concepts described in this handbook or learned through other training material does not mean that the benefits of IPPD cannot be achieved it just means that the benefits will be a little bit harder to reach Remember that the purpose of the IPT structure is to make it easier to implement IPPD Once set up and operating each IPT must remain focused on improving the team’s effectiveness and taking every opportunity to make the changes that move the team closer to the ideal IPPD environment 6 July 1998 16 IPPD Handbook Chapter 4 Metrics This chapter defines what metrics are describes their essential properties and types and outlines a nine-step process for developing metrics 4 1 Metric Attributes A metric differs from a measurement in that a metric is a composite of meaningful quantifiable product or process attributes taken over time that communicate important information about quality processes technology products and or resources Measurements are simply the raw data from which metrics are calculated A good metric is capable of reliably measuring a specific process repeatedly over time The purpose of a metric is to measure change regardless of whether that change is positive or negative For example when measuring the technical performance of a test article the goal is usually to increase the performance of the article If the present test of the article reflects a decrease in performance from the previous test the data process and any changes made must be examined to determine the cause Metrics help define problems by fostering process understanding and indicating when corrective action is required The goal of metrics is to show a trend that results in action to improve the process For a metric to be meaningful it must represent one or more cause-and-effect relationships that control the process being measured Sometimes data may be difficult to measure or collect but it is very valuable Other times data that is easily collected is meaningless Ensuring that data value is worth the collection effort is essential to a good metric Metrics should be reconsidered if the data do not represent cause-and-effect relationships do not show a trend or are not timely In addition output metrics are preferred over input metrics Many metrics such as those relating to cost schedule and performance can be used throughout the program’s life cycle while others may be tied to only one portion of the program Choosing quality over quantity of metrics is a continuing challenge To assist teams in assessing metrics the following is a list of attributes generally associated with a good metric • Has value to the team members or is an attribute essential to customer satisfaction with the product • Tells how well organizational goals and objectives are being met through processes and tasks • Is simple understandable logical and can be used repeatedly • Shows a trend • Is unambiguously defined • Uses data that is cost-effective to collect • Allows for timely collection analysis and reporting of information • Provides insight that drives appropriate action 6 July 1998 1 IPPD Handbook 4 2 Types of Metrics Metrics are used at all levels of a program’s structure to represent key measures mainly in the areas of cost schedule and performance Metrics monitored by program IPTs should be supported by other metrics monitored by sub-tier teams Sub-tier teams should ensure that their metrics are aligned with the Program IPT’s metrics in intent language and format Sub-tier team metrics however should not be limited to those handed down from the program team At the sub-tier level additional metrics are often needed to accurately monitor the performance of the sub-tier team’s product Although this chapter focuses primarily on hardware metrics many programs have a software component Efforts in measurement for software development include Practical Software Measurement PSM by the Joint Logistics Commanders Joint Group on Systems Engineering Their website has links to other software measurement sites The PSM website is at http www psmsc com Three major categories of metrics are progress product and process These categories are intended to assist teams in identifying the types of metrics they should be using 4 2 1 Progress Progress metrics are used to monitor the health and status of the program They serve as alarms for adverse trends These metrics must allow for the detection of adverse trends in sufficient time to permit corrective actions see Figure 4-1 for an example of a progress metric Metrics that indicate a trend after the outcome has become a fait accompli are useless as control metrics The following are metrics examples that fall into the progress category • Cost performance index and variance • Schedule performance index and variance • Earned value • Risk assessment tracking • Manpower planned versus actual • Deliveries 6 July 1998 2 IPPD Handbook Cumulative Dollar Variances $'S in Millions $10 00 $5 00 Schedule $0 00 Variance $5 00 $10 00 $15 00 $20 00 $25 00 Cost Variance $30 00 Figure 4-1 Sample Progress Metric 4 2 2 Product Product metrics are measures of a program’s technical maturity and are tied to the key performance parameters of a product For developmental programs these measures are found in the operational requirements document ORD as objectives and thresholds and in the test and evaluation master plan TEMP as critical technical parameters see Figure 4-2 for an example of a product metric Each performance parameter has an associated cost schedule and risk impact Metrics of this type indicate to teams whether or not the desired technical performance is achievable given the constraints of the program To ensure a degree of commonality in reporting metric data to higher-level teams the program team should determine the objectives that each sub-tier team is to accomplish the frequency and level of detail of their reporting and the allowed variation for each product metric Examples of product metrics include— • Operational availability • Weight budget • Mean time between failures MTBF • Speed • Range • Payload 6 July 1998 3 IPPD Handbook Product unit cost • Power consumption Mean Time Between Failure • Objective ed Problem solv Tre nd 1 2 3 4 Threshold 5 6 7 8 9 Test Unit Number Figure 4-2 Sample Product Metric 4 2 3 Process Process metrics assess the quality and productivity of a program’s processes In order to improve a process it must be understood and measured Data is collected at specific checkpoints in the process flow and then analyzed The analysis of the data should be able to predict quality at later stages in the process see Figure 4-3 for an example of a process metric Process metrics are a concern not only of the IPPD stakeholders or IPTs measuring them but also of the functional organizations such as budgeting contracting or testing that own the processes being measured Cooperation is essential to ensure that the best metrics are used or developed Process metrics usually compare current predicted performance versus performance objectives A standard of performance is set using historical data or expected levels of performance The process is then measured to see whether the objective is being met If the objective is not met analysis should determine why If the objective is missed it might suggest that the objective was not properly set In either case the process should be examined for ways to improve process performance and thereby establish a new objective Statistical process control SPC is a good method to use for monitoring controlling and improving processes see Section 7 3 6 Examples of process metrics are— • Number and cost of requirements changes • Number and cost of engineering change proposals 6 July 1998 4 IPPD Handbook Number and cost of test failures • Cycle Time • Defect rates Defects per 100 units • 35 30 25 20 15 10 5 Time Figure 4 3 Sample Process Metric 4 3 Metric Development Process Choosing or creating metrics is not a random process Developing a measurement system requires an in-depth understanding of customer and project requirements Program processes and process outputs must be identified From there process output thresholds must be determined and the appropriate measures or performance indicators developed The following nine-step process is not the definitive methodology for metric development but it does provide guidance in what to consider when creating or choosing a metric specifically for process metrics 1 Identify the purpose of the metric Is this metric intended to provide data only to the team creating it or will it be reported to higher level teams What type of metric is needed—programmatic management control technical performance measure or process 2 Define what is to be measured Identify what it is that needs to be measured to satisfy the purpose see step 1 If the process that is to be measured is not clearly understood in terms of cause-and-effect relationships then the measurement will consist of a trialand-error determination of seemingly related factors that may or may not have a bearing on the outcome 3 Identify and examine existing metrics Once the cause-and-effect relationships have been identified existing metrics from this or other programs should be examined to determine if any of them satisfies the requirement It makes good sense to use a proven metric when the process previously measured matches or parallels the process under consideration 4 Generate new metrics if existing metrics are inadequate When generating a new metric pay attention to what is needed as an output of the process to be measured and 6 July 1998 5 IPPD Handbook how that output contributes to the end product With metrics the focus is on a process’ contribution to these final outputs Teams should be interested in those measures that drive the final outcome and are key to making process improvements 5 Rate the metric against the attributes of a good metric Refer to the attributes listed in section 4 1 The metric should satisfy all of the criteria listed If it does not return to step 2 and correct the deficiencies 6 Select the appropriate measurement tools Keep in mind that the metric data should be economical to gather This includes the hours spent gathering the data processing it and the time required to display it Automated data gathering is preferred but many collection processes do not lend themselves to automation Once the data is gathered it often requires analysis or processing to be useful There are many means of analyzing and displaying the data such as process variance charts and control charts for process data In some cases a specialist may be needed to analyze and present the data 7 Baseline the metric This will serve as a reference point to begin acquiring data and measuring any changes 8 Collect and analyze metric data over time Aggregate metric data over time and examine trends Special and or common causes of effects on the data should be investigated Compare the data with the baseline to ascertain improvement decline or no change Utilize SPC when and as appropriate 9 Initiate process improvement activities Initiate iterative process improvement activities with key process owner involvement Once the process has been changed the data must be closely watched for trend improvement If degradation is noticed the reason for it must be identified and corrected The process should not be changed until data trends have been clearly established unless a change is required to correct a previous change that resulted in a decline in performance 4 4 General Guidelines for Team Metrics Metrics for IPT performance generally follow the guidelines below 1 Metrics should measure only what is important and output outcome metrics are preferable to input activity metrics Metrics should measure the goals of the IPT as stated in the charter for the following reasons • All activities of the IPT should be centered on meeting the chartered goals Measurements of any other items are distractions When the metrics apply directly to these goals products of these goals—which the program manager might be tempted to track independently—will be tracked indirectly with the primary metrics • Reporting and documentation of extraneous metrics consume too much valuable time that should be devoted to accomplishing the chartered goals • Metrics should roll up through the IPT hierarchy Metrics not directly related to primary goals cannot easily track upwards 6 July 1998 6 IPPD Handbook 2 Metrics should be measurable in real time The purpose of metrics is to indicate the current performance of the IPT Metrics of a historical nature are just that—a measure of what has happened a summary and not necessarily an indicator of future performance Ideal measurements should also be easy to make Difficult measurements take time and thus may not be done “in real time ” 3 Metrics should be “on display ” Metrics should be visible to those whose work is being tracked This can give individual team members a better understanding of the goals of the team and what actions are needed to better meet those goals 4 Metrics should be updated Because acquisition programs change as time progresses and thus the goals of the IPTs change over time metrics also need to be frequently reevaluated for current applicability 6 July 1998 7 IPPD Handbook Chapter 5 Integrated Information Environments An integrated information environment is a key element of an IPPD environment thus its importance is stressed throughout this document This chapter shows how computing assets in a program can be integrated to enhance IPPD implementation In an IPPD environment different functions are linked through integrated computer assets to give all stakeholders real-time access to technical and business financial contracting etc information Hand delivered mail or isolated computer systems that produce hard copies are replaced by local area networks LANs and the Internet the dominant vehicle in this paperless environment With this reliance on electronic communications software compatibility and computer security are related issues of importance to the successful implementation of IPPD 5 1 Internet Until recently electronic communications have been transmitted via fax machines dedicated data lines or internal networks Today the Internet is an ideal host vehicle for electronic data exchange E-mail over Local Area Networks LANs and the Internet is rapidly becoming the dominant medium of communication between collocated and noncollocated personnel See Figure 5-1 for a generic Internet-based network Data Flow IPT 1 Internet Public Access Data IPPD Data Server Web Site IPPD Data Base Program Management Aides Collaborative Engineering Tools Engineering Models IPT 2 Legend User LAN IPT n IPPD Database Administrator Firewall Figure 5-1 Internet-Based Network 6 July 1998 1 IPPD Handbook The Internet can be used to make both business and technical data bases available to IPPD stakeholders at widely separated locations This capability permits the near-real-time sharing of program and engineering data and enhances workflow management action item coordination electronic document sharing and scheduling and milestone planning Internet software tools are continually being developed to integrate these data bases IPPD Internet Tools Example Army Missile Command The Army Missile IPPD team at Redstone Arsenal is organizing a set of applications for performing IPPD via the Internet The following are some of the applications currently available • A rolling calendar that provides team-wide coordination with hypertext links • An action item data base that provides a clear picture of responsibilities and task interrelationships real-time task status a multiple parameter search engine and automatic e-mail message generation to the responsible individual when a task is assigned • A discussion group area similar to an Internet bulletin board that functions as a virtual meeting area where people can be remotely located and not simultaneously present at different times • A meeting minutes data base that provides everyone with access to meeting minutes and contains a search engine for locating specific topics • An IPT organizational hierarchical data base that —Displays the current IPT hierarchy —Provides access to team charters missions schedules meeting minutes key deliverables etc —Provides a built-in e-mail capability —Provides team member information such as skills resumes and photos • A computer-aided design CAD drawing data base capable of reading drawing data sets from the majority of available CAD programs with a “red-line” review comments feature • A technical document library that allows documents to be stored in text or graphic form retrieved across platforms and researched using an advanced search engine • A workflow management tool for timely and intelligent routing and distribution of documents with attachments For further information contact the Manufacturing Technology Division System Engineering and Production Directorate Research Development and Engineering Center at http ippd redstone army mil mippd For programs in which facilities and personnel are not very dispersed i e that have a limited number of locations needing access to information or that have security requirements exceeding the capabilities of the Internet more traditional network solutions dedicated networks using secure communication lines can be used in place of or in conjunction with the Internet In setting up such a network attention needs to be paid to the network capacity Bandwidth can be 6 July 1998 2 IPPD Handbook a major consideration when organizations are widely distributed—the efficient exchange of very large files such as CAD and engineering analysis files can be hampered by limited network capacity 5 2 Compatibility One roadblock to an effective integrated product development environment is the inability of different design tools data bases and other business software tools to talk to each other This deficiency not only makes communication between team members from different functional groups difficult but also significantly diminishes the productivity of the individuals that need to use multiple tools Because the interoperability of different design development business tools is currently being investigated any specifics listed here might well be out of date as soon as this document is published Thus for up-to-date developments the reader is encouraged to consult the Department of Commerce National Institute of Standards and Technology NIST Current NIST efforts include work to develop a set of integrated design and manufacturing tools as well as a national information infrastructure that would make it possible to perform electronically the many business tasks that have traditionally been done manually—all in an environment where different applications can interact with each other For more information on NIST’s activities see http www nist gov Two standardized options for interoperability are NIST’s Common Interface Standard and DoD’s Continuous Acquisition and Life-Cycle Support CALS standards 5 2 1 Common Interface Standard NIST is promoting a common interface standard to eliminate or significantly reduce the interoperability problem between manufacturing and design tools that can be experienced in IPPD One project is the Computer Aided Manufacturing Environment CAME in which architectures interfaces and data bases for integrating engineering tool environments are being developed from commercial products where possible 5 2 2 Continuous-Acquisition and Life-Cycle Support The Computer-Aided Life-Cycle Support CALS initiative is an industry and government strategy to enable more effective generation exchange management and use of digital data supporting the life cycle of a product CALS centers on use of international standards business process changes and advanced technology application This initiative was started in September 1985 by the DoD with the goal of enabling the integration of enterprises on a worldwide basis through the development implementation and integration of digital information standards for product design manufacture and support The National Technical Information Service NTIS CALS Information Center the largest single source for current information on CALS is accessible at http www fedworld gov edicals calsinfo html 6 July 1998 3 IPPD Handbook 5 3 Security Neither government nor industry can accept integrated information environments unless electronic network transactions including e-mail are secure During IPPD for example there are clear requirements for authenticating the source of data verifying the integrity of the data preventing disclosure alteration or destruction of the data by unauthorized users and verifying receipt of the data A secure network includes firewalls comprehensive security policies data encryption measures educated users and electronic signature safeguarding programs • Firewalls The most popular firewall technology today is Trusted Information Systems TIS Internet Firewall Kit which was developed under a Defense Advanced Research Projects Agency DARPA program Because firewall technology is constantly changing program network security personnel should remain up to date on the state of the technology and upgrade program software as necessary • Comprehensive security policies Each organization participating in an IPPD project even if it is unclassified should have established and enforced security policies covering personnel physical plants and automated information systems AISs to protect competition-sensitive information and proprietary data Sources for security policies are the DoD Industrial Security Program Operating Manual DoD 5220 22-M Security Requirements for AIS DoDD 5200 28 and Information Security Program DoD 5200 1R • Data encryption Because the Internet operates on commercial unsecure communication lines between network servers locations of the firewalls data encryption is a vital part of the overall secure network Data encryption packages include Acrobat Encryption Pretty Good Protection PGP Netscape Secure Server and others Data encryption is used to ensure that the data sent over the Internet is useless to anyone who intercepts it along the way This includes all data even e-mail messages • Educated users The probability of security compromises is high unless users are indoctrinated and regularly refreshed on security issues While IPT members are encouraged to freely share data among themselves and with other IPTs all programs involve some sensitive information that should be appropriately safeguarded • Electronic signature safeguarding programs Many transactions especially those involving financial data or engineering data that is under configuration control require a way to electronically indicate approval by one or more authorized individuals Traditionally this was accomplished by pen on paper signature blocks While signatures can be easily scanned into digital form security software is required to deter forgery Electronic signature safeguarding programs include the Department of Commerce’s Advanced Authentication Technology Program More information on this NIST program is at http csrc nist gov authentication overview htm Whenever an engineering drawing or business form is modified the approval cycle needs to be repeated Thus version control software should automatically rescind approvals and route changed drawings or forms back to approval authorities again for digital signature 6 July 1998 4 IPPD Handbook For further information on security contact the Manufacturing Technology Division System Engineering and Production Directorate Research Development and Engineering Center U S Army Missile Command RSA AL http ippd redstone army mil mippd Security Example USAF Data Base Compromised In 1996 a computer programmer working for a major defense contractor gained complete access to an USAF data base on the readiness of USAF aircraft and other weapon systems The computer system part of a network of data bases that the USAF uses to monitor how ready its combat units are for war was left unprotected because a program designed to secure it was never installed With the right passwords which were found in a file housekeeping program the system was even accessible from the Internet Upon discovering the breach in security a program named “Safeguard” was loaded Extracted from “The Washington Post” 15 June 1997 edition 5 4 Electronic Business Applications IPPD is greatly facilitated by communication networks and related tools available today in the world of electronic business This mode of business has been legislated by the Federal Government for government business and is being developed by both government and commercial entities 5 4 1 Federal Acquisition Streamlining Act of 1994 The Federal Acquisition Streamlining Act FASA of 1994 Public Law 103-355 signed by President Clinton on 13 October 1994 was designed to simplify and streamline the federal procurement process It has significantly changed how the government does business The Act repeals or substantially modifies more than 225 provisions of law to reduce paperwork burdens transform the acquisition process to electronic commerce EC and improve the efficiency of the laws governing the procurement of goods and services Most significantly the new law— • Emphasizes the acquisition of commercial items • Streamlines acquisition procedures under an elevated small purchase threshold • Establishes uniformity in the procurement system • Improves protest and oversight processes and authorized specific pilot programs • Implements a system for electronic data exchange the Federal Acquisition Computer Network FACNET The FACNET requires the government acquisition process to evolve from the traditional paperbased mode to an expedited data-based mode The electronic system is intended to provide a single face to industry The Act establishes parameters for FACNET along functional lines both for government and private users These functions are to be implemented by agencies within 5 years of FASA’s enactment The government wide FACNET will be designed to— 6 July 1998 5 IPPD Handbook • Inform the public about federal contracting opportunities • Outline the details of government solicitations • Permit electronic submission of bids and proposals • Facilitate responses to questions about solicitations • Enhance the quality of data available about the acquisition process • Be accessible to anyone with access to a personal computer PC and a modem More information on FACNET can be found at http www acq sd mil ec facnet htm 5 4 2 Electronic Commerce and Electronic Data Interchange Electronic commerce EC is the paperless exchange of business information using electronic data interchange EDI and related technologies In its traditional role EC consists of e-mail computer bulletin boards fax machines Electronic funds transfer EFT and other paperless data transfers All EC systems replace all or key parts of paper-based workflows with faster cheaper more efficient and more reliable communications between machines EDI is a collection of public standard message formats and a data element dictionary that allows trading partners to exchange data in a simple way using any electronic messaging service These standard message formats provide an application neutral format for the direct computer to computer exchange of information In EDI the electronic equivalents of common business documents such as purchase orders and invoices are transmitted electronically between the computers of trading partners These electronic documents are formatted in accordance with American National Standards Institute ANSI Accredited Standards Committee ASC X12 the U S national standard for EDI The international standard is the United Nations Electronic Data Interchange for Administration Commerce and Transport UN EDIFACT The government has mandated the use of either the ANSI or UN standards when data are exchanged electronically with vendors suppliers and contractors Translation software is used by each trading partner to translate the business data from ASCII or another applications software format to an ANSI ASC X12 format and vice versa EDI standards often are confused with the method of data transport They are two separate entities The standard formats can be exchanged over any electronic messaging service In the past the ANSI ASC X12 standards were married to a formal method of data transport involving translation software and a value added network or proprietary direct connection This approach can be costly and difficult Today EDI data move over many types of messaging services including the Internet The Internet open system based standards make it very easy to implement EDI at minimal cost It is cost effective for a program office to implement EDI because of the variety of commercial off the shelf tools that are available to exchange EDI messages between application systems In the government context a Request for Quote RFQ may be transmitted to all registered trading partners Trading partners respond with an electronic response to an RFQ document The government buyer reviews all received responses using bid evaluation software chooses a contractor to buy from based upon bid price or another preestablished criterion and transmits an electronic purchase order document to the selected contractor The contractor responds by transmitting a purchase order acknowledgment document shipping the product and transmitting 6 July 1998 6 IPPD Handbook an invoice document to the government buyer The buyer upon receiving the goods transmits a payment order document to the contractor and pays the contractor using EFT The Joint Electronic Commerce Program Office JECPO is responsible for accelerating the application of electronic business practices and associated information technologies to improve DoD acquisition processes and supporting sustainment life-cycle practices The National Electronic Commerce Resource Center ECRC program also was established to help small businesses with EC and EDI through regional centers located across the United States Contact the DoD Joint EC Program Office at http www acq osd mil ec Contact the ECRC program at http www ecrc ctc com Contact EDI for Program Management Reporting at http www acq osd mil pm edi edi htm Contact the DoD Integrated Data Environment at http www acq osd mil api tpm ppmo htm 5 4 3 Business Tool Exampless Traditional manual methods across all functions are being replaced with newly-developed computer tools In the business arena EC and EDI are opening up many opportunities for such tools For example the JSF program has developed two software tools to aid in a paperless contracting process the Bids Evaluation Support Tool BEST and the Contracting Officer Support Tool COST More information on BEST and COST can be found at http www jast mil html contracts html A Standard Procurement System SPS is being developed within DoD as a fully-functional automated information system AIS that will standardize the procurement business practices and data elements by promoting the use of the same automated contracting procedures It will perform standard automated procurement functions for acquiring systems supplies and services and is supposed to subsume individual program legacy systems like the ones mentioned above unless those systems perform functions not inherent within the SPS The system is due to be completed in 1999 Additional information on the SPS can be found at http www sps hq dla mil 5 5 Product Development Applications In the recent past major weapon systems were designed produced and fielded with each functional group using manual pencil-and-paper techniques and tools Then one by one many of these techniques and tools were automated using computerized applications Today it is common to find many function-unique computer tools and applications employed on a single development effort As previously discussed in Sections 2 1 6 and 2 1 7 there is a need to integrate these tools to work together A middle-of-the-line approach is to integrate all data-base-type data manufacturing logistical reliability maintainability purchasing etc into one system and have that system interact on a limited basis with a drawing program parts lists configuration management This approach is most useful when developing improvements to an already established product line Lockheed Martin is incorporating this approach on the F-16 program to cut the costs and cycle times of product support efforts and product upgrades 6 July 1998 7 IPPD Handbook Computer-Integrated Manufacturing CIM takes the interoperability issue one step further and creates a computer environment in which all the applications not only talk to each other but also use a common data base Implementing CIM— • Makes up-to-date data available to all parties • Eliminates translation errors resulting from reformatting data from one application to another • Simplifies computer resource support and data base administration • Simplifies configuration management of data • Guarantees that downstream functions will be notified of changes that impact interfaces or overall system performance • Enhances the ability to conduct concurrent engineering and manufacturing development Many tools are widely used in industry to accomplish many of the CIM functions—for example CATIA IBM Dassault Systemes Unigraphics and Pro ENGINEER… These tools provide capabilities such as— Computer-Aided Design CAD • 2-D and 3-D drafting tool • Assembly modeling tool that allows a designer to assemble separate engineering models in a 3-D environment • Wire bundle installation tool that automates the design and routing of wire bundles • Solid and wireframe modeling Computer-Aided Engineering CAE • Finite element modeling tools • Mechanical thermal acoustic dynamic and other analysis tools • Stress analysis tools • Fitting simulation tool that enables users to define the trajectory of parts to be assembled or disassembled Computer-Aided Manufacturing CAM • Wire bundle formboard generation formboards are used for wire harness manufacture • Cell design and robot programming tool for verifying the robot’s suitability for a given task and then generating the programs • Fixed and multiple axis milling tools that enable numerical control programmers to generate verify implement and maintain tool paths for simple to complex milling and drilling machines • Manufacturing infrastructure tool that provides a way to visually replay and verify a machine tool path on an electronic mockup and to examine and modify cutter tool paths 6 July 1998 8 IPPD Handbook Manufacturing Resource Planning MRP • Integration of parts lists bill of material product documentation needed by MRP programs Chapter 6 Modeling and Simulation Modeling and simulation M S supports the IPPD approach the integration of complex systems and is a key tool used by IPTs The members of an IPT share test and simulation data and identify needed information from the tests and simulations Furthermore technical and operational challenges which can be identified early in system development through simulation can be targeted for further testing Virtual prototypes embedded in realistic synthetic environments can aid in developing a shared vision of the proposed system and provide a means for understanding the complex interactions among the configuration items in the system design Design manufacturing and test engineers can work together in IPTs to build a prototype that can be more efficiently manufactured and tested Simulation is being used more in the acquisition process due to increased availability of M S tools and processes declining resources and the recent emphasis on IPPD DoDD 5000 1 and DoD 5000 2-R Part 3 4 4 state that— Models and simulations shall be used to reduce the time resources and risks of the acquisition process and to increase the quality of the systems being acquired Representations of proposed systems virtual prototypes shall be embedded in realistic synthetic environments to support the various phases of the acquisition process from requirements determination and initial concept exploration to the manufacturing and testing of new systems and related training Accredited modeling and simulation shall be applied as appropriate throughout the system life-cycle in support of the various acquisition activities requirements definition program management design and engineering efficient test planning result prediction and to supplement actual test and evaluation manufacturing and logistics support PMs shall integrate the use of modeling and simulation within program planning activities plan for life-cycle application support and reuse models and simulations and integrate modeling and simulation across the functional disciplines In addition to increasing the effectiveness of the design test and manufacturing functional specialists modeling and simulation will benefit the product support members of the team e g the logisticians and maintainers as well as the training and warfighting communities Program offices need to support and use modeling and simulation more than ever before and must plan for the funding of program and legacy M S Modeling and simulation capability has matured to the point where it can facilitate several activities 1 development 2 communication between government and contractor 3 requirements exploration in the context of CAIV 4 demonstrating the significance of features found in component and subcomponent tests 5 test planning and analysis 6 communication between engineering manufacturer tester and user 7 logistics management and 8 training and human factors evaluation during the life-cycle of a system M S used well in the IPTs can be a key contributor to the implementation and success of IPPD 6 July 1998 9 IPPD Handbook M S is increasingly being employed by the DoD to provide better insight into weapon system performance reduce testing and training costs and develop force mixes of weapon quantities and types These uses ultimately support the twin goals of reducing DoD weapon acquisition costs and dramatically shortening the time to weapon system fielding Accomplishment of these goals requires— • An integrated simulation T E process that provides continuous insight—to ensure that quality is built into programs from the start • An emphasis on prevention over cures—where simulation test and evaluation are used to identify and resolve problems early The innovative use of M S to produce systems better faster and cheaper is demonstrated by the following examples • The AIM-7P Sea Sparrow was developed and tested using only 10 of the planned 50 launches The Navy was able to eliminate the remaining 40 flight tests using an end-game effectiveness model to predict the lethality of the missile • The GBU-28 was developed in less than 6 weeks during Desert Storm by relying almost exclusively on lethality and vulnerability modeling to design and predict the performance of the system • Army testing of bridge durability—a process that traditionally requires 12 weeks to do 3 000 crossings—was reduced to 9 weeks with a mix of actual crossings and simulation • At the Air Force's Arnold Engineering Development Center M S has been used to lower the cost of testing to the customer The average time in the PWT-16T wind tunnel has decreased from 6 weeks to 3 to 4 days • At Eglin AFB the use of the Preflight Integration of Munitions and Electronics Systems PRIMES ground simulation led to a 35 percent reduction in cost and a 300 percent increase in data capture during a recent flight test program of the APG-63 radar 6 1 Simulation-Based Acquisition The DoD is seeking to streamline ways in which it acquires weapons systems Evolving modeling and simulation tools have the potential to reduce the time resources and risk associated with the process while improving the quality of the systems produced through a strategy called Simulation Based Acquisition SBA The Department’s vision is to have an acquisition process that is enabled by the robust collaborative use of simulation technology that is integrated across acquisition phases and programs The goals of SBA are to— • Substantially reduce the time resources and risk associated with the acquisition process • Increase the quality military utility and supportability of fielded systems while reducing total ownership costs • Enable IPPD across the full acquisition life cycle 6 July 1998 10 IPPD Handbook SBA is an integrator of simulation tools and technology across acquisition functions and program phases and across programs It is a concept in which M S as a resource is more efficiently managed in the acquisition process In a defense environment of decreased funding SBA addresses both the decreasing availability of resources for system development and the increasing power of M S tools Through reliance on the collaborative use of simulation technology in an IPPD environment models and simulations are integrated between program phases to reduce the time processes and risks associated with the acquisition process 6 2 The Simulation Test and Evaluation Process The Simulation Test and Evaluation Process STEP is a major DoD initiative designed to improve the acquisition process by integrating M S with T E STEP is consistent with the regulations that govern systems acquisition and does not require their modification STEP moves beyond the “test fix test” approach to a “model-simulate-fix-test-iterate” approach Problems are fixed as they are discovered This approach model first simulate test fix after each step and then iterate the test results back into the model is reiterated throughout system development Iterative loops can occur in this process For example one can model simulate fix simulate fix simulate fix test and then feed the results into the model When a need to fix is discovered the time for each fix can be much shorter when the fix can be verified in the model in hours or days as opposed to a field test which can take weeks or months to verify a fix The latest information on STEP can be found at http www acq osd mil te programs tfr step htm 6 3 Defense Modeling and Simulation Office Extensive M S capabilities exist in the DoD The Defense Modeling and Simulation Office DMSO was established to provide a focal point for information concerning DoD M S activities Currently the DMSO promulgates M S policy initiatives and guidance to promote cooperation among DoD components to maximize efficiency and effectiveness DMSO is a staff activity reporting to the Director Defense Research and Engineering DDR E Office of the Under Secretary of Defense Acquisition and Technology OUSD A T Current DoD policy and capabilities concerning M S are contained in the DoD M S Master Plan DoD 5000 59-P This plan is the DoD’s vehicle to direct organize and concentrate its M S capabilities and efforts on resolving commonly shared problems DoD 5000 59-P is available with additional information on DMSO activities at http www dmso mil 6 July 1998 11 IPPD Handbook Modeling and Simulation Examples M S Environment Example Joint Strike Fighter The JSF program has adopted an M S environment that has shortened the timeline for task identification and requirements generation The program office has pursued a product and process team approach that includes industry and has developed the modeling tools necessary to replicate the threat environment operations concept and JSF weapon system performance This open product and process approach has enabled the government and industry team to gain early operational insight and make the pertinent trades up front to ensure that performance and affordability objectives are met Customers and DoD officials alike are convinced that JSF M S efforts will result in a better product for the warfighter For further information on the Joint Strike Fighter program see http www jast mil M S as a Tool Example Simulation Based Design The Defense Advanced Research Project Agency DARPA originally sponsored the Simulation-Based Design SBD program to develop technology that would enable IPPD in a computer-based environment for the design and evaluation of complex mechanical systems Elements of the SBD program include the following Virtual Prototype An engineering representation of a product and process model It is geometrically and dimensionally correct and behaves in accordance with the laws of physics Virtual prototypes may contain many different subsystems and components all of which interact with each other Synthetic Environment A system of computer-based models generating a comprehensive workspace for conceiving optimizing and evaluating virtual prototypes Product and Process Model An information structure that shows how the system operates and how it is made SBD expands beyond the traditional basic geometric description of a system to include the system configurations behavioral attributes and performance descriptions needed to simulate functionality As a system evolves from concept to fielding the virtual prototype’s product and process model grows in complexity and detail in the areas of design cost predicted performance reliability and other factors Virtual Environment This is a system that provides a medium for design team members to collaborate and access the resources of a design in real time Systems simulated in a virtual environment can use virtual prototypes to simulate the actual product and its operation as well as the processes necessary to manufacture and assemble that product Using virtual prototypes in synthetic environments allows complex systems to be rapidly prototyped The virtual prototype when placed in the synthetic environment behaves as the real product would Immersed in a virtual environment designers can manufacture the product test the product under realistic conditions provide customer walk-throughs have operators test the human factors and usability and test out repair procedures—all without 6 July 1998 12 IPPD Handbook actually building the physical product SBD is intended to permit manufacturing cost performance and life-cycle considerations to be coordinated and integrated through the entire process from concept development to manufacture and operation Use of these tools will⎯ • Permit detailed evaluation of product and process designs early in the life cycle therefore reducing the number of expensive surprises during manufacturing and operational service • Eliminate costly prototypes for both product and process designs • Provide realistic operator interaction with the product during the requirement and design process • Permit development of tactics and training in realistic operational scenarios with existing operational assets Information about these M S tools can be found at http sbdhost parl com 6 4 Prototyping The heart of the M S topic is prototyping The purpose of a prototype is to provide a vehicle for • Learning—generating information concerning the design • Communication—giving a visual and tactile description of the design i e seeing and feeling how it works • Integration—assembling and fitting components within a design • Reducing design iterations—improving the certainty of information thus reducing the need for rework • Milestones—achieving a desirable level of functionality Prototypes can be physical or virtual depending on the maturity of the design and the intended use of the prototype For example virtual prototypes are usually more flexible than physical ones because design iterations are much faster with computer models Physical prototypes are usually necessary to identify and analyze multiple interacting phenomena and they are also better for detecting unanticipated phenomena Most programs incorporate both types of prototypes in their development 6 4 1 Virtual Prototyping A virtual prototype can be defined as a computer-based simulation of a system or subsystem with a degree of functional realism comparable to a physical prototype Computer-generated prototyping has advanced to become an exceptionally powerful tool used in all aspects of the systems engineering and development processes From an IPPD standpoint virtual prototyping VP benefits the requirements analysis process functional analysis and allocation and synthesis 6 July 1998 13 IPPD Handbook of an emerging product as well as the product verification testing VP also dramatically improves the ability to conceptualize with a 3-D picture In addition VP is useful much earlier in the design process than physical prototyping and can be used to prototype large systems such as ships submarines and buildings Advanced planning is critical for a valid application of VP Proper investment in VP for the short term can yield tremendous time and budget savings and a superior product in the long term The degree of fidelity and the basis for verifying validating and accrediting VV A the prototype are important up-front decisions The customer and T E communities should be involved early and all should agree on the modeling and simulation program and its application VV A is the keystone for the successful use of all VP technology and involves extensive upfront planning and investment VP tools exist today that enable the simulation of nearly any aspect of the design and operation of a system Because of the high initial cost of these tools in hardware software and training computer simulation efforts should be directed to those areas where the payoff is greatest such as • Fit and assembly assessments • Performance simulations and assessments • Operating processes • Manufacturing process simulations • Maintenance analyses • Operational assessments Virtual Prototyping Examples Fit and Assembly Assessments Example Boeing 777 For the first time in the company’s history Boeing Aircraft designed the entire 777 aircraft on a computer and successfully built it without a complete physical mock-up Using an extensive VP process Boeing effectively brought together 33 subcontractors spread across 13 countries all operating in a digital electronic format The VP resulted in a 93 percent reduction in design changes compared with those in its previous aircraft and the greatest first-time form and fit ever achieved by the company Furthermore VP has improved the accuracy of tool design by a factor of 10 Boeing found that their product and process teams benefited from VP because it stimulated the employees’ creativity Performance Simulations and Assessments Example Predator M S has been employed extensively in the Predator Advanced Concept Technology Demonstration ACTD It has been used in the broadest context to address global issues such as force mix assessments in a lesser context to simulate capabilities in exercises and in an even more narrow context to address specific performance issues such as the 6 July 1998 14 IPPD Handbook identification of design tradeoff study parameters Force Mix Assessments At the highest levels M S is being used to develop assessments of alternative force mixes of manned and unmanned reconnaissance systems including Predator Several classified studies such as the Intelligence Surveillance and Reconnaissance ISR Joint Warfighting Capability Assessment JWCA and the Command Control Communications and Computers ISR Mission Assessment CMA are using M S to identify reconnaissance architecture options for consideration Additionally the Defense Airborne Reconnaissance Office’s DARO architecture development includes within its force mix considerations of all unmanned air vehicles UAVs including Predator Predator has been integrated into each of the exercises and its performance characteristics platform and sensors are incorporated in the full range of studies which include campaign- and mission-level analyses The results of these efforts are helping to determine for example the number of Predator UAV systems that will be needed to support the objective of dominant battlespace awareness at an affordable cost Capabilities Simulation in Exercises At the next level M S is being used to support Predator participation in operational exercises In these exercises virtual Predators are flown by operational users because the limited quantities of real hardware assets are unavailable and because M S yields substantive insights at considerably lower cost than operating the real assets These exercises have contributed significantly to the development of the concepts of operation CONOPS for Predator and to an increase in the user knowledge base about the employment of UAVs in general For instance in FY96 Predator was modeled in a simulation called the Multiple Unmanned Aerial Vehicle Simulation Environment MUSE The MUSE was combined with an improved Joint Surveillance and Target Attack Radar System JSTARS simulation to provide a representation of real-time capabilities at selected theater corps and division-level command and control headquarters Performance Issues At a third level M S has been used in the Predator program to assess operational performance analyze performance parameters conduct tradeoff studies and evaluate potential system changes and improvements as in the following examples After initial radar cross section RCS measurements were conducted computer modeling was used to determine the Predator RCS In accomplishing the initial operational assessment of Predator limited data from the 1995 European deployment was used as the basis for several engineering models and numerous simulations to complete the analysis of Predator’s effectiveness On many occasions sufficient field data simply could not be collected to validate critical assessment objectives and M S was the only practical alternative for evaluation Much of the engineering design of the Predator de-icing system was done through M S The determination of ethylene glycol flow requirements hole emplacement on the front leading edge of the wings and the flow rates necessary to operate successfully were modeled and then tested in a wind tunnel prior to actual vehicle flight tests A recently completed M S study for the DoD's Director of Operational Test and Evaluation 6 July 1998 15 IPPD Handbook DOT E has been used to predict the Predator’s coverage capabilities of the target area This work was done to gain insight into Predator's ability to meet its Key Performance Parameter KPP of a continuous 24-hour target area presence Because a demonstration of this capability had never been attempted an event-driven simulation was developed to help identify the factors that might affect Predator's ability to meet this requirement The model included missions of various ranges system failures projected system reliability and maintenance actions scheduled and nonscheduled The study's key finding was that the Predator's ability to continuously monitor a target area i e the target-area presence or timeon-station is most sensitive to the transit time to the target area and less sensitive to system reliability and maintenance capabilities The judicious use of creative M S has directly contributed to the management of costs on the Predator program by predicting operational effectiveness in conjunction with abbreviated operational assessments effectively assessing air vehicle survivability cost determining optimum system configuration and assessing alternative force structure options Further information on the Predator UAV program can be found at http www acq osd mil daro homepage predms htm Performance Simulations and Assessments Example USAF In-Flight Simulators The following three USAF aircraft can be programmed to test the flight performance of other aircraft—real or conceptual NF-16D This aircraft commonly known as VISTA Variable Stability In-flight Simulator Aircraft is a special modification of a high-performance airframe in current production that can be configured to emulate the performance of other modern fighter aircraft The model of the aircraft to be simulated is programmed on the in-flight simulator's computers When the evaluation pilot flies from the cockpit the in-flight simulator responds like the model The NF-16D has been used to support the development of the F-22 and the Light Combat Aircraft India NT-33A This predecessor of the NF-16D which is still available for supporting in-flight simulation needs has such features as independent control of pitch roll and yaw and a programmable heads-up display HUD center stick and side stick The NT-33A was used in the development of the X-15 A-10 F-15 F-16 F-18 F-22 Lavi Israel Gripen Sweden and the Light Combat Aircraft India NC-131H This Total In-Flight Simulator TIFS is the world's only large 6-degree-offreedom in-flight simulator Its features include a separate evaluation cockpit that is easily reconfigured and accessible in flight a programmable display system and a rugged dependable proven airframe The NC-131H was used to develop the Space Shuttle Supersonic Transport B-1 and B-2 This aircraft also has an alternate mission to perform avionics system testing Operating Process Simulation Example Electric Boat Electronic Visualization System 6 July 1998 16 IPPD Handbook The Electronic Visualization System EVS is a computer environment for the design and evaluation of submarines This system’s capabilities include • Simulation of the performance of the submarine • Simulation of operations in the control and engine rooms • Practice manufacturing and interface resolution The EVS is displayed in a room where the IPPD team can view display and communicate with one another to resolve problems Each person can wear virtual reality devices to be immersed in a virtual environment Using the EVS IPT members can perform detailed assembly animations kinematic studies analysis animations and anthropomorphic studies The EVS can be accessed at various locations via a secure network thus it is available to IPT members at different locations Manufacturing Process Simulation Example VM FastTrack A primary objective of virtual manufacturing VM tools is to reduce the cost of the first product in production by iterating design options and manufacturing approaches in a virtual factory environment where the design and manufacturing approach can be solidified at minimal expense In other words learning is done on the computer rather than on the factory floor McDonnell Douglas demonstrated this in a program called VM FastTrack in which an F-15E production design change was accomplished by simultaneously using both the current paper design approach and commercially available VM techniques The following benefits were attributed to the VM approach • A 33 percent reduction in design release time • A 27 percent reduction in design cost • A 19 percent reduction in manufacturing cycle time • A 20 percent reduction in factory floor space utilization Manufacturing Process Simulation Example Simulation Assessment Validation Environment The JSF program has contracted the development of a VM program called Simulation Assessment Validation Environment SAVE to support low-risk transition of weapon system technology from concept to EMD The objective of the Lockheed SAVE program is to integrate implement and validate low-risk VM technology The SAVE system can be adapted to any engineering manufacturing effort and is designed to be employed during all phases of a product's life cycle from concept design through production However the focus of this project is on virtual manufacturing for aircraft structural assemblies as part of the total weapon system development This program when developed will provide significant cost savings to the JSF program 6 July 1998 17 IPPD Handbook The primary users of the SAVE system are the JSF program’s IPT members SAVE is a comprehensive VM modeling and simulation environment using multiple engineering and manufacturing variables SAVE's iterative modeling capabilities facilitate the development of the optimum production fabrication assembly plan Lastly through electronic links the integrated simulation technology and its associated data base permit worldwide electronic processing of the same VM environment using a common data base SAVE's full suite of VM software tools operating in a single environment allows cost schedule and risk assessment to be continually evaluated as the program advances The integrated tool suite permits verification and refinement of the design and manufacturing process prior to the production of the physical hardware The SAVE system— • Integrates the software tools used today in a standalone environment • Collects and controls the data developed by the IPT in a single logical data base • Provides ready access for all members of the IPT organization to a single data base • Allows transparent communication between IPT members through telecommunications networking online messaging and workflow management • Permits the IPT to conduct EMD simulations to optimize design producibility and manufacturing processes while simultaneously reducing cost schedule and risk The SAVE tool suite supports the IPT in a cooperating evaluation of component design tool design tolerance analysis assembly planning ergonomics factory floor simulation schedule simulation risk assessment and cost analysis through the SAVE data base Maintenance Analysis Example Design Evaluation for Personnel Training and Human Factors The Air Force Materiel Command’s Logistics Research Division-Acquisition Logistics Branch has developed software for simulating maintenance activity Design Evaluation for Personnel Training and Human Factors DEPTH is primarily used to detect human factors problems during the design process The software also has applications in training process efficiency analysis and logistics data generation By using DEPTH acquisition costs can be dramatically reduced by accelerating development time with virtual prototyping and helping to eliminate the need for physical mockups DEPTH allows maintenance activity to be analyzed using articulated 3-D human figure models HFMs The HFMs provided by the Jack software are accurate representations of humans with respect to both anthropometry body size and shape and motion The HFMs can be proportioned to represent different percentiles within Air Force Army or civilian populations They can be dressed for arctic chemical defense or normal environments and they can work with any of the 200-plus tools in the data base Movement of the HFMs can be controlled with a standard mouse body tracking equipment or the automatic simulation capability The automatic simulation capability referred to as motion modeling allows complex simulations to be rapidly created As simulations run DEPTH reports such information as accessibility visibility and strength The information can also be directed to 6 July 1998 18 IPPD Handbook logistics data bases The DEPTH software runs on most current Silicon Graphics workstations and is available at no charge to most U S organizations requiring a maintenance simulation However a licensed copy of Jack—an interactive graphic system for the manipulation and display of articulated figures developed at the University of Pennsylvania—must be purchased to run DEPTH Operational Assessments Example Synthetic Theater of War Various battlefield simulators located around the country enable the system developers to assess how their concept will perform in different scenarios Synthetic Theater of War STOW is an ACTD jointly sponsored by DARPA and the United States Atlantic Command USACOM The STOW program seeks to create a seamless simulated environment that will be usable across the spectrum of service and joint training crisis rehearsal doctrine development battle planning resource readiness assessment material development and system acquisition STOW 97 will demonstrate enhanced simulation fidelity based on combat resolution at the weapons system level of detail realistic simulation of command and control behavior networking and information flow technology and the capability to provide knowledge-based autonomous forces in simulation with human-in-the-loop HITL participation wherever desired STOW 97 will be fully distributed so that forces may participate in exercises or rehearsals from command posts and simulators at widely separated bases or on a live range if desired Significant additional goals of STOW 97 are to integrate simulation with operational C4I and management information systems and to improve the technology and processes of After Action Reconstruction and Analysis AARA Further information on STOW 97 can be found at http www acq osd mil at stow htm 6 4 2 Physical Prototyping Both virtual and physical prototypes have their place in today’s acquisition environment The F22 development relied heavily on virtual M S to meet the cost and schedule objectives of the program But virtual prototypes could not satisfy all of the M S needs as the following example illustrates Physical Prototype Example F-22 The F-22 program demonstrates the continued usefulness and need of physical prototypes The following major physical prototypes have been or will be used in the F-22 program Avionics Prototypes The F-22 avionics concept was demonstrated first in the Boeing Avionics Ground Prototype Laboratory This was followed by airborne tests in Boeing's 757 Airborne Flying Laboratory AFL 6 July 1998 19 IPPD Handbook RCS Prototype The low observability features of the F-22 design were confirmed using a full-scale pole model of the F-22 Wind Tunnel Prototypes More than 36 000 hours of wind tunnel testing have been completed in the F-22 development program so far A total of 19 195 test hours were accumulated in the demonstration validation phase of the program for the F-22 prototype and a total of 16 930 wind tunnel test hours were completed on the refined F-22 configuration during the current EMD phase Wind tunnel testing was used not only to test the flight characteristics of the airframe but also to test weapon separation characteristics for various munitions Other Prototypes The F-22 EMD contract includes two airframes one for static testing and one for fatigue testing in addition to 9 flyable aircraft A major drawback of traditional physical prototypes was the time and expense involved in producing them New technologies that are available today enable the quick and inexpensive fabrication of small prototypes using automated processes These technologies are commonly grouped under the title “rapid prototyping ” 6 4 2 1 Rapid Prototyping If a picture speaks a thousand words a 3-D model speaks volumes Rapid prototyping RP makes generating affordable physical 3-D models possible with little lead-time The ability to quickly generate numerous models compared with earlier labor and time intensive methods is of great value in the IPPD environment for communicating ideas creating T E articles and even creating relatively low-cost tooling RP also known as desktop manufacturing solid free-form manufacturing or solid free-form fabrication consists of various manufacturing processes by which a solid physical model of a part is made directly from a 3-D CAD model Unlike milling in which machines remove material to form a shape RP systems build a part layer by layer from liquid powder or sheet material Materials used include plastics ceramics metals and paper To begin the RP process the 3-D data is sliced into thin 0 005 inch cross-sectional planes by a computer The cross sections are sent from the computer to the RP machine which builds the part layer by layer The shape of the first cross-sectional plane generated by the computer defines the first layer’s geometry It is bonded to a platform or starting base and additional layers are bonded on top of the first shaped according to their respective cross-sectional planes This process is repeated until the prototype part is complete The resulting prototype provides a conceptual model for design visualization and review by the entire design team Engineers may use it to check form and fit and to perform limited function tests It can also be utilized for soft tooling for prototypes and as a pattern for hard tooling RP processes include— • Printing 6 July 1998 20 IPPD Handbook • Ballistic particle manufacturing • Design-controlled automated fabrication • Direct shell production casting • Fused-deposition modeling • Multijet modeling • Selective laser sintering • Solid-ground curing • Stereolithography • Topographic shell fabrication • Laminated object manufacturing Time and again companies have documented how RP has helped them save an almost unbelievable amount of prototyping time avoid costly design errors and enhance the production of tooling The cost of a model produced by one of these systems can range from under $50 to $1 000 The less expensive models are generally too delicate to be used for any purpose other than concept modeling and early design review and approval The main restriction of RP is the limited size of the models The average build volume of an RP system is about a 250-milimeter 10-inch cube but there are systems that produce larger part prototypes Many companies have successfully built parts in sections and then fastened e g glued or screwed them together While this works it is an approach that RP users tend to avoid 6 July 1998 21 IPPD Handbook Chapter 7 Additional IPPD Tools Many additional tools that are available are described in the literature for use in an IPPD environment Some selected examples are included in this chapter for convenience with further references given for additional information 7 1 Requirements Definition 7 1 1 Quality Function Deployment Quality Function Deployment QFD is a tool often cited as an enabler for IPPD because it is an efficient and effective method for meeting customer requirements The QFD methodology consists of a structured procedure that starts with the qualities desired by the customer the objective identifies the functions required to provide these products or services and identifies the means for deploying the available resources to best provide these products and or services This Objective-Function-Means process is documented and mapped in a matrix that allows all team members to see how their inputs contribute to satisfying customer requirements This has the added benefit of helping to break down the walls between the functional areas in the product development process QFD provides a systematic approach to building a team perspective of what needs to be done the best ways to do it the best order in which to accomplish it and the staffing and resources required It also provides a good format for capturing and documenting decision making Additional QFD information can be found at the QFD Institute website at http www qfdi org Links to other sites are provided at this site as well Quality Function Deployment Example Joint Strike Fighter The JSF program office has found QFD to be a very effective tool in the implementation of IPPD QFD has helped enable the program office to build a consensus across a large group of individuals and organizations representing different experiences operational needs and priorities 7 1 2 Requirements Analysis Process in Design for Weapon Systems One software application that aids in requirements definition is the Requirements Analysis Process in Design for Weapon Systems RAPID-WS The RAPID-WS software enables the capture and iterative use of operational and technological data before committing to a systemspecific solution The data is used by the weapon system operators or IPTs who are responsible for defining the operational requirements RAPID-WS offers the potential to reduce both manpower costs and contractual analysis costs through the standardization and reuse of critical acquisition data With RAPID-WS operational users designers and the acquisition corps have iterative and effective use of requirements-oriented data to support the earliest phases of acquisition For additional information contact the Air Force Research Laboratory Logistics Research Division AFRL HESS Wright-Patterson AFB or go to http www alhrg wpafb af mil 6 July 1998 1 IPPD Handbook 7 2 System Decomposition Many engineering systems are large and multidisciplinary The design of new complex systems such as large aerospace systems cannot begin until the possible interactions among subsystems and their parts are determined Once that task is completed the proposed system can be decomposed to identify its hierarchical structure The Design Manager's Aid for Intelligent Decomposition DeMAID is a knowledge-based system developed by NASA for ordering the sequence of modules and identifying a possible multilevel structure for the design problem DeMAID displays the modules in an N x N matrix format called a design structure matrix where a module is any process that requires input and generates an output Modules that generate an output but do not require input such as an initialization process are also acceptable Although DeMAID requires an investment of time to generate and refine the list of modules for input it can save a considerable amount of money and time in the total design process particularly in new design problems where the ordering of the modules has not been defined The decomposition of a complex design system into subsystems requires the judgment of the IPPD participants DeMAID reorders and groups the modules based on the links interactions among the modules helping the team members make decomposition decisions early in the design cycle The modules are grouped into circuits the subsystems and displayed in an N x N matrix format Feedback links which indicate an iterative process are minimized to occur only within a subsystem Since there are no feedback links among the circuits the circuits can be displayed in a multilevel format Thus a large amount of information is reduced to one or two displays which are stored for later retrieval and modification The IPPD teams then have a visual display of the design problem and the intricate interactions among the different modules The design manager can save a substantial amount of time if circuits on the same level of the multilevel structure are executed in parallel DeMAID estimates the time savings based on the number of available processors In addition to decomposing the system into subsystems DeMAID examines the dependencies of a problem with independent variables and dependent functions A dependency matrix is created to show the relationship DeMAID is based on knowledge-base techniques to provide flexibility and ease in adding new capabilities Although DeMAID was originally written for design problems it has proven to be capable of solving any problem that contains modules processes which take input and generate an output For example one group is applying DeMAID to gain an understanding of the data flow of a very large computer program In this example the modules are the subroutines of the program Several companies including General Motors GM and Boeing are using this tool Further information on DeMAID can be obtained at http www cosmic uga edu abstracts lar-14793 html 7 3 Defect Prevention Traditional engineering focuses on solving problems analyzing failure using a repetitive process of design-build-test testing one factor at a time firefighting and studying in detail the problems associated with interactions among the factors involved This approach is costly and time-consuming and is not always successful The IPPD environment with its integrated teams and a centralized information system that allow real-time access and timely iterative analysis 6 July 1998 2 IPPD Handbook makes prevention of defects and problems more likely One means of problem prevention is Variability Reduction VR VR enables the reduction of variations that can lead to product defects in the design and manufacturing processes Variability reduction is accomplished using many tools some of which are discussed in the following sections First the following example from Northrop Grumman Corporation NGC illustrates the use and benefits of some of these tools Design For Manufacturing Assembly DFMA And Variability Reduction VR Tools Example Northrop Grumman Corporation Integrated Product Development IPD Data Sheets are controlled drawings at the assembly level that depict the interrelations of detailed parts tooling and assembly sequences for each cost center They include the datums of detail parts and the tolerance requirements of part features and tooling part locators They also include key characteristics at the assembly level which are then flowed down to the detailed part level Geometric Dimensioning Tolerancing GD T is an internationally recognized engineering drawing language that specifies tolerance dimensional requirements with respect to actual function and the inter-relationship of part features NGC has provided extensive GD T training to IPD team members and suppliers Key Characteristics KC are designated to identify those part or assembly features interfaces where variation from nominal results in the greatest loss Statistical Process Control SPC measurements are then focused on key characteristics to minimize variation ensure capable processes and reduce unnecessary inspection requirements Statistical Process Control SPC provides data to measure the capability of critical processes and or key characteristics to produce quality parts within specified tolerance bands and to control process shifts and spreads Successful SPC applications on close tolerance holes and countersinking have resulted in significant defect reduction Variation Simulation Analysis VSA is an assembly simulation model in which detail part and tool tolerances are compiled to predict conformance to geometric requirements to include out of specification conditions VSA is proprietary software requiring seat licenses VSA operates in a 3-D environment and is being used on selected aircraft programs NGC’s experience has shown that the combination of these DFMA VR tools with 3-D design and IPD implementation have resulted in— • Improved parts fit • Net trimming before assembly • Reduced shimming • Reduced assembly hours cost • Reduced cycle time 6 July 1998 3 IPPD Handbook 7 3 1 Design for Manufacturing Process Capability Design for Manufacturing Process Capability is a design policy that requires new designs to be optimized with respect to manufacturing processes This method requires an intimate knowledge of process capabilities and the impact that tolerance stacking in successive operations has on key characteristics Key characteristics are features of a design for which variation has the greatest impact on the fit performance or service life of the finished product 7 3 2 Design for Manufacturing Assembly Design for Manufacturing Assembly DFMA techniques are designed to reduce product cost through design simplification DFMA achieves such simplification by reducing the number of parts and ensuring that the required parts are easy to manufacture and assemble DFMA usually results in enhanced product quality because many noncompliances are attributable to product complexity 7 3 3 Process Variability Reduction Variation in the process used to manufacture a product can result in variation in the key characteristics of the product By reducing the variability of the processes the variability of the key characteristics can be reduced and hence the quality of the product increased 7 3 4 Root Cause Closed Loop Corrective Action Traditionally process quality control involved inspection to identify nonconforming items and disposition of defective items as scrap or rework Much time effort and cost was spent determining rework procedures and performing the rework while little effort went to addressing the basic cause of the problem By investigating the root cause of the problem with a multidisciplinary team empowered by high-level management and then applying corrective action to the process or design recurrence of most problems can be prevented This process was used in the late 1980s to address the high rate of nonconformance found on the General Dynamics F-16 fighter production line and within a short time that production line returned to world-class standards 7 3 5 Robust Design Robust design is the systematic approach to finding optimum values of design factors that result in economical designs with low variability to provide consistent customer satisfaction A robust design results in a product that is insensitive to or tolerant of sources of variation and change that are difficult costly or impossible to control whether on the shop floor or in use over time Robust design is accomplished using a variety of tools and methodologies including Taguchi Methods Design of Experiments Six Sigma and others The Taguchi Methods describe a strategy to optimize a design to withstand variation in its manufacture and use Design of Experiments DOE is a tool for collecting and managing information for design optimization Six Sigma defines a specific quality goal and a strategy to meet it 6 July 1998 4 IPPD Handbook 7 3 5 1 Taguchi Methods Taguchi Methods is a system of cost-driven quality engineering that emphasizes the effective application of engineering strategies rather than the use of statistical techniques It includes both upstream and shop-floor quality engineering in a process of product parameter design tolerance design process parameter design and on-line quality control Upstream methods efficiently use small-scale experiments and orthogonal arrays to reduce variability called “noise” and find cost-effective robust designs for large-scale production and the marketplace Shop-floor techniques provide cost-based real-time methods for monitoring and maintaining quality in production Taguchi Methods allow a company to rapidly and accurately acquire technical information to design and produce low-cost highly reliable products and processes While the following example applies to production quality of an existing design and not new development it is still a good example of the benefits of applying Taguchi Methods Taguchi Methods Example Aerojet Ordnance Poor production quality and nonconforming products were a problem for the GovernmentOwned Contractor-Operated GOCO plants making the Area Denial Artillery Munition ADAM mine for the Army Nineteen out of 25 lots were rejected 40 000 rounds per lot A joint team of government and industry tried—without success—to find the cause of the problem Although Aerojet Ordnance had not developed this product it was called in to apply Taguchi experiments to the testing Aerojet took three months to prepare for and conduct experiments in order to identify the critical parameters It identified 13 controllable factors and set three different levels for each factor all except one were within tolerance Aerojet fired six rounds for each experiment It identified four factors of greatest improvement and determined how building the round with those factors at optimum levels would provide rounds virtually 100 percent in conformance Results These predictions were validated in field testing Using the parameters identified in the experiments 54 rounds were produced and tested without a failure This was the first time in the history of the product that a 100 percent yield had been observed over a reasonable time period Another 54 rounds were produced using a parameter setting where the experiments predicted a yield of 50 percent Twenty-seven of the rounds failed the test Production lines are now working to capacity building good products There have been no reported problems in eight months 7 3 5 2 Design of Experiments Design of Experiments DOE is a tool used to collect and manage information for design optimization DOE is used to optimize process parameters for increased yields DOE is a statistical tool that maximizes the amount of information obtained from a limited number of controlled experiments The experiments are derived by varying parameters and conducting an experiment or operating a process to determine the result By continually adjusting controllable process variables and analyzing the results the design process can be tweaked 6 July 1998 5 IPPD Handbook toward maximum output This continuous controlled adjustment process is referred to as Evolutionary Operations Software tools to assist in the application of DOE are available For example applications to date of Gosset developed by Bell Labs include optimizing the production of wafers for integrated circuits placing laser beams for the treatment of tumors in the brain growing protein crystals designing a cellular substrate used in catalytic converters and designing coated photographic paper 7 3 5 3 Six Sigma The term “six sigma” relates to the statistical function used to measure the amount of variance in a process Six Sigma as an industry program is an effort to achieve high quality low cost and minimum cycle time resulting in a highly satisfied customer Six Sigma is a way to measure the chance that any unit of product can be manufactured with zero defects—no more than 3 4 defects per one million items To achieve a Six Sigma design the characteristics of the design that most affect performance and reliability need to be identified Then by increasing the allowable range of variation of those characteristics many more units will be usable This is a six-step process depending on customer requirements and process capability Two good journal articles on company Motorola Texas Instruments General Electric successes with Six Sigma can be found at http www qualitydigest com dec97 html sixsigma html and http www ge com investor article 7 3 6 Statistical Process Control Another tool used to ensure high manufacturing yields through variability reduction is Statistical Process Control SPC SPC is most applicable to Phase II Engineering and Manufacturing Development and the Production part of Phase III It allows for the continuous monitoring of the output of critical stages of a process and identifies special-cause variation that once isolated can be removed from the process to control product output within known or knowable process capabilities Automated tools are available to collect the required measurements perform the required mathematical analysis and alert the operator of process change or unexpected variation Statistical Process Control SPC Example Hewlett Packard SPC is usually only part of an overall quality program Hewlett Packard HP however developed their quality program using SPC Results of its implementation include the following • The composite field failure rate of all HP products decreased 83 percent over the past eight years • Scrap and rework costs have been drastically reduced in many divisions One wave soldering process reduced its defect rate from 4000 parts per million ppm to 3000 ppm Other areas have experienced reductions of 80 to 95 percent • Manufacturing costs have been reduced as much as 42 percent • Parts inventories have been reduced as much as 70 percent • Manufacturing cycle times have been reduced as much as 95 percent 6 July 1998 6 IPPD Handbook • Product development times have been cut up to 35 percent • Productivity has increased as much as 300 percent • Physical plant requirements including floor space have been reduced significantly in many cases One division reported that it has increased shipments 400 percent over the last several years without having to add any floor space • One field repair station reported reducing its repair turn-around-time by 80 percent • The finance department at one division trimmed its financial close cycle by 33 percent • Total Quality Control TQC applications in field sales operations have improved sales effectiveness 7 4 Cost Modeling DoDD 5000 1 directs that cost must be viewed as an independent variable To use the Cost as an Independent Variable CAIV methodology accurate and current cost models are needed Without up-to-date real-time cost data the CAIV process cannot be used in a timely and repetitive fashion to guide design decisions 7 4 1 Real-Time Costing In the past cost models were a consequence of the way the engineering process worked Customer requirements led to a design and the technical output of the design process was used as an input to the cost models The cost models reflected a point cost estimate of the design concept this estimate along with its supporting cost data was forwarded to the customer who used it as a model for his or her own cost analysis The cost estimates produced by both industry and the customer were mainly based on parametric cost models e g weight as a size parameter engineering or manufacturing complexity factors While this method yielded a cost estimate based on easily measured or estimated factors it was accomplished after design decisions had been made and reflected cost estimates based on historical processes and approaches In an IPPD approach cost estimating needs to be performed up front in order to provide timely feedback to the design process To be effective concurrent cost estimating requires integrated cost and engineering models Without such integration the process becomes as tedious and time consuming as traditional methods Another way to eliminate the redundant cost modeling effort which becomes necessary when evaluating proposals from different vendors using different cost models is to do what the JSF program office did—make a single cost model available for the contractors to use 7 4 2 Activity-Based Costing One of the best methods available today to produce an accurate cost model is activity-based costing ABC ABC has received its name because of its focus on the activities performed in the realization of a product Costs are traced from activities to products based on each product’s consumption of such activities ABC differs from conventional costing systems in two distinct ways 6 July 1998 7 IPPD Handbook 1 In conventional costing systems the assumption is that each unit of a given product consumes a certain amount of resources e g material labor and energy ABC is based on the assumption that products directly consume activities not resources Therefore the cost of a product is the sum of all the costs of the activities performed to produce that product 2 Conventional cost systems are based on unit-level cost drivers or allocation bases of the product that are directly proportional to the number of units produced Direct labor hours machine hours and pounds of material are examples of such unit-level allocation bases The ABC system uses cost drivers that can be at the unit level batch level and or product level Examples of batch-level cost drivers are setup hours and the number of setups Examples of product-level cost drivers are the number of parts the number of times parts are processed and the number of engineering change orders One of the prime advantages of ABC over traditional methods is its ability to distinguish between direct costs from indirect costs by separating batch-level costs from product-level costs For example economies of scale cannot be accurately modeled in the traditional cost model It is also well known that using common components yields cost reductions but again only ABC can model the cost savings associated with this practice The inability of traditional cost models to trace overhead costs correctly by only using unit-level cost drivers result in their systematically under-costing small low-volume products and over-costing large high-volume products For further information on Activity-Based Costing visit the NASA web site at http mijuno larc nasa gov or query the Defense Technical Information Center DTIC at http www dtic mil 7 5 Lean Enterprise “Lean enterprise” refers to a company’s ability to increase flexibility to react to changing requirements and to eliminate waste in the design and manufacturing processes Lean enterprise originally began as a concept called lean manufacturing in the Japanese automobile industry and has since been credited with turning around the U S automaking industry Within DoD the principles of lean enterprise are being tailored to the aerospace industry through a program called the Lean Aircraft Initiative LAI jointly led by the USAF and Massachusetts Institute for Technology MIT with the full participation of the leading companies in aerospace The principles of lean enterprise are captured in a series of overarching practices that include the implementation of IPPD The objective of lean enterprise is to improve the total company—the objective of IPPD is to improve program performance within that company Consequently the lean enterprise’s overarching practices complement and reinforce an IPPD approach During source selection one indicator to look for is the degree to which the contractor has implemented the lean enterprise practices detailed in the Lean Enterprise Model LEM These practices create a corporate environment in which an IPPD program can thrive Another valid indicator as mentioned earlier is the company’s implementation of lean enterprise practices with strong corporate support for Lean initiatives generally equating to lower risk for achieving IPPD success Information on the Lean Aircraft Initiative may found at http web mit edu lean The Lean Enterprise Model may be found at http imvp mit edu LAI lem lem html 6 July 1998 8 IPPD Handbook Appendix 1 Acronyms 3-D Three-dimensional AARA ABC ACTD ADS AFB AFL AIS ANSI APB ASC After Action Reconstruction and Analysis Activity-Based Costing Advanced Concept Technology Demonstration Advanced Deployable System Air Force Base Airborne Flying Laboratory Automated Information System American National Standards Institute Acquisition Program Baseline Accredited Standards Committee BEST Bids Evaluation Support Tool C4I CAD CAE CAIV CALS CAM CAME CDRL CIM CLIPS CMA CONOPS COST CPIPT Command Control Communications and Computers and Intelligence Computer Aided Design Computer Aided Engineering Cost as an Independent Variable Continuous Acquisition and Life-Cycle Support Computer Aided Manufacturing Computer Aided Manufacturing Environment Contract Data Requirements List Computer Integrated Manufacturing C Language Integrated Production System Command Control Communications and Computers ISR Mission Assessment Concepts of Operation Contracting Officer Support Tool Cost Performance Integrated Product Team DAB DARO DARPA DAU DDR E DeMAID DEPTH DFMA DMSO DoD DOE DOT E Defense Acquisition Board Defense Airborne Reconnaissance Office Defense Advanced Research Projects Agency Defense Acquisition University Director of Defense Research and Engineering Design Manager's Aid for Intelligent Decomposition Design Evaluation for Personnel Training and Human Factors Design for Manufacturing Assembly Defense Modeling and Simulation Office Department of Defense Design of Experiments Director of Operational Test and Evaluation 6 July 1998 1 IPPD Handbook DTIC Defense Technical Information Center e-mail EC ECP EDI EFT EMD EVM EVS Electronic Mail Electronic Commerce Engineering Change Proposal Electronic Data Interchange Electronic Funds Transfer Engineering and Manufacturing Development Earned Value Management Electronic Visualization System FACNET FASA Federal Acquisition Computer Network Federal Acquisition Streamlining Act GOCO Government Owned Contractor Operated HFM HITL HP HUD Human Figure Models Human-in-the-Loop Hewlett Packard Heads Up Display IBR IPPD IPT ISR IT Integrated Baseline Review Integrated Product and Process Development Integrated Product Team Intelligence Surveillance and Reconnaissance Information Technology JECPO J-MASS JROC JSF JSTARS JWCA Joint Electronic Commerce Program Office Joint Modeling and Simulation System Joint Requirements Oversight Council Joint Strike Fighter Joint Surveillance and Target Attack Radar System Joint Warfighting Capability Assessment KPP Key Performance Parameter LAN LCC Local Area Network Life-Cycle Cost M S MAIS MDA MDAP MNS MRP MTBF MUSE Modeling and Simulation Major Automated Information System Milestone Decision Authority Major Defense Acquisition Program Mission Needs Statement Material Resource Planning Mean Time Between Failure Multiple Unmanned Aerial Vehicle Simulation Environment 6 July 1998 2 IPPD Handbook NAVAIR NDI NIST NSSN NTIS Naval Air Systems Command Nondevelopmental Item National Institute of Standards and Technology New Attack Submarine National Technical Information Service OIPT ORD OSD Overarching IPT Operational Requirements Document Office of the Secretary of Defense PC PDRR PGP PMO PRIMES Personal Computer Program Definition and Risk Reduction Pretty Good Protection Program Management Office Preflight Integration of Munitions and Electronics Systems QFD Quality Function Deployment RAPID-WS RCS RDT E RFP RFQ Requirements Analysis Process in Design for Weapon Systems Radar Cross Section Research Development Test and Evaluation Requests for Proposal Requests for Quotation RP Rapid Prototyping SAVE SBA SBD Simulation Assessment Validation Environments Simulation-Based Acquisition Simulation-Based Design SFRC SM-3 SOO SOW SPC STEP STOW Short Form Research Contract Standard Missile Statement of Objectives Statement of Work Statistical Process Control Simulation Test and Evaluation Process Synthetic Theater of War T E TEMP THAAD TIFS TIS TOC Test and Evaluation Test and Evaluation Master Plan Theater High Altitude Area Defense Total In-Flight Simulator Trusted Information Systems Total Ownership Cost 6 July 1998 3 IPPD Handbook TQC TQM Total Quality Control Total Quality Management UAV UN EDIFAC T USACOM USAF USD A T Unmanned Aerial Vehicle United Nations Electronic Data Interchange for Administration Commerce and Transport United States Atlantic Command United States Air Force Undersecretary of Defense Acquisition and Technology VAN VISTA VM VP VR VTC VV A Value Added Network Variable Stability In-flight Simulator Aircraft Virtual Manufacturing Virtual Prototyping Variability Reduction Video Teleconference Verification Validation and Accreditation WBS Work Breakdown Structure 6 July 1998 4 IPPD Handbook Appendix 2 Sources of Additional Information Air Force Research Laboratory Logistics Research Division AFRL HESS Wright-Patterson AFB http www alhrg wpafb af mil CAIV http www acq osd mil CALS http www fedworld gov edicals calsinfo html CATIA http www1 ibmlink ibm com HTML SPEC g2214399 html DeMaid http www cosmic uga edu abstracts lar-14793 html DMSO http www dmso mil DoD Guide to IPPD http www acq osd mil te survey table_of_contents html DoD EC EDI Information Center Phone 1-800-EDI-3414 World Wide Web http www acq osd mil ec DoD risk management Defense Acquisition Deskbook http www deskbook osd mil ASC Handbook for Integrated Risk Management Aeronautical Systems Center ASC FMC Building 11A 1970 Third Street Suite 6 Wright-Patterson AFB OH 45433-7213 or http www wpafb af mil az_public abb htm DoD Risk Management Guide http www dsmc dsm mil pubs gdbks risk_managementhtm htm Security Requirements for AIS DoDD 5200 28 http tecnet0 jcte jcs mil 9000 htdocs teinfo directives soft ds html Information Security Program DoD 5200 1-R http www dtic mil 80 c3i 52001 html Information Systems Security Manufacturing Technology Division System Engineering and Production Directorate Research Development and Engineering Center U S Army Missile Command RSA AL http ippd redstone army mil mippd IPT Learning Campus CD resource guide http www acq-ref navy mil ipthome html 6 July 1998 1 IPPD Handbook IPPD Multimedia Training Tool http www acq-ref navy mil g-tools html J-MASS http www jmass wpafb af mil JSF program http www jast mil LPD 17 program http lpd17_wr nswc navy mil Missile IPPD Tools Manufacturing Technology Division System Engineering and Production Directorate Research Development and Engineering Center U S Army Missile Command RSA AL http ippd redstone army mil mippd National Institute of Standards and Technology http www nist gov NSSN program http www acq-ref navy mil Open Systems Joint Task Force http www acq osd mil osjtf Predator UAV program http www acq osd mil daro homepage predms htm Quality Function Deployment http www qfdi org Rules of the Road A Guide for Leading Successful Integrated Product Teams http www acq osd mil ar ipt htm Simulation Based Design http sbdhost parl com STEP http www acq osd mil te programs tfr step htm STOW 97 http www acq osd mil at stow htm m Tools of Total Quality http www acq-ref navy mil g-tools html 6 July 1998 2