Integrated Product Team Research Articles

5.3.2 SPECIFICATION DEVELOPMENT WITHIN THE IPT: A CASE STUDY OF THE F‐22

AbstractThe goal of this paper is to demonstrate how the concurrent engineering method embodied in the Integrated Product Team (IPT) philosophy has impacted the specification development process on the F‐22 program. The article will examine the concurrent engineering process as it applies strictly to specification development.[1] In particular, the success of the specification development process will be attributed to three main factors: (1) maintaining flexibility in the Preliminary Allocated Baseline (PAB) until Functional Configuration Audit (FCA), (2) Increasing communication and trust between the contractor and the customer by making the customer an integral member of the IPT, and (3) taking advantage of the automated technology to redesign the specification development process. While the F‐22 program is a multi‐corporate endeavor, these principles can be applied to any development effort.]

SYSTEMS PERSPECTIVE TO DESIGN OPTIMIZATION

AbstractRockwell Space Systems Division has been undergoing dramatic changes in the last three years to embrace the Integrated Product Team (IPT) development concept. The architecture of the design system operates is critical to our mission in becoming cheaper, faster, better. Our design architecture is evolving from one that is a byproduct of the design to one of driving good design. A key element in the design process is the interconnectivity of systems and design engineering.This paper discusses the changes that are occurring in people, processes and technologies which are evolving to produce cost effective, designed products by Rockwell Space Systems Division. A modification product design case study involving tool integration known as Enterprise Process and Data Management (EPDM) will be examined in more detail.

5.1.2 DEVELOPMENT AND EVOLUTION OF AN INTEGRATED PRODUCT DEVELOPMENT SYSTEM/CENTER AT THE SPACE AND MISSILE SYSTEMS CENTER

AbstractAn Integrated Product Development Center (IPDC) was developed at the Air Force Space and Missile System Center (SMC) and achieved Initial Operational Capability (IOC) in June 1994. The IPDC provides a computer‐aided environment to accomplish systems engineering and program management activities characteristic of Integrated Product Development (IPD) implemented within the Air Force. The IPDC serves as the nucleus of an overall IPD System (IPDS), connecting Integrated Product Team (IPT) members internal and external to SMC, and facilitating and encouraging a “paperless”, efficient, and cost‐effective environment. Initial emphasis was on establishing a collaborative work environment and providing acquisition support tools for IPTs. Users of the IPDC expressed general satisfaction with the center, its initial usage in its first three months exceeded 80 percent of its daily availability. The paper addresses the conceptualization of the IPDS/C, the systems engineering process applied to identify its requirements, design, and current and planned user environments.

3.5.4 THE TRANSITION OF FUNCTIONAL ORGANIZATIONS TO INTEGRATED PRODUCT TEAMS ON THE SPACE STATION PROGRAM

AbstractSince May 1993, the Space Station Program has undergone major restructuring, primarily due to budgeting constraints, as a result of the new presidential administration. Thus far, significant changes have been made to the program which have already resulted in considerable improvements in the management, scheduling and budgeting of the program. This paper will focus on the major management changes of selecting a single Prime contractor and the effectiveness of the NASA and the Prime contractor at transitioning from a Functional Organization to Integrated Product Teams (IPTs). The Space Station program is an example of how the transformation of a functional organization to IPTs can be implemented successfully, despite failure rates of up to 65‐85%. The characteristics of Tom Peters' Simple Form/Lean Structure and Autonomy and Entrprenuership, which are two of the eight attributes of Excellent Organizations, as well as Peter Senge's 5th Discipline of Systems Thinking will be extended to include the implementation of the theories on a functional organization transitioning to IPTs. In addition, the overall transition will be evaluated based on customer satisfaction, productivity, schedule, communication, employee moral and costs. Finally, conclusions will be made and recommendations to improve the transition process will be discussed.

2.3.3 Risk and Opportunity Management and the Project Cycle

AbstractSystem engineering, as a function, is responsible for oversight of risk and opportunity management of a project. Design engineering is likewise responsible for risk and opportunity management at the Configuration Item level and below. Any complete process model, designed to illustrate engineering responsibilities, must emphasize the risk and opportunity aspects of system engineering management, and must illustrate these important activities in the context of the overall system engineering process. The model presented in this paper meets these objectives.The evolving baseline for the technical aspects of the project cycle can be illustrated during decomposition and definition process in a set of descending steps, and during the integration and verification process in a set of ascending steps. This representation creates a “Vee,” with the evolving baseline represented by the legs, or core, of the “Vee.” Risk and opportunity management activities, which are essential to the process, are shown as supporting activities off the core of the “Vee.”Use of a “Vee” model was introduced in our paper presented at the first NCOSE symposium in Chattanooga in October 1991. The “Vee” model illustrates the end‐to‐end involvement of system engineering in the development process, emphasizes the use of risk reduction and opportunity enhancement techniques, and encourages the implementation of concurrent engineering (including integrated product teams).During the past three years we have gained valuable experience in using this model as the heart of our System Engineering and Project Management training and consulting with major government and commercial clients. As a result of this highly illustrative model we have experienced considerable success in conveying the intricacies of the system engineering process to system engineers, project and program managers, and executives.As noted in our 1991 paper, others have considered a “Vee” project model in the past, but they only considered the core of the “Vee.” The enthusiastic acceptance of our model by many professionals is based on the power of the model in providing visualization of the complete development process. Key features of the model are: 1) Only the activities on the core of the “Vee” are part of the evolving baseline managed under configuration control, 2) project risk and opportunity management activities are off‐core activities external to the current baseline, and 3) time and baseline maturity move to the right, which helps illustrate the impact to the approved baseline caused by users with changing requirements.Enhanced graphics and lessons‐learned examples have been included to provide full understanding of how these concepts are used to drive toward optimum solutions based on value, risk, and opportunity.

1.5.1 TEAM WORKSHOPS: A SYSTEM ANSWER TO IPT ISSUES

AbstractIn an Integrated Product Team environment, the systems engineering focus can be diluted unless specific steps are taken to focus the key people working on each team, and to improve their understanding and teamwork. Team Launches and Team Workshops have been created to educate teams just coming under contract and ongoing teams, respectively. The workshops teach team techniques in a structured, facilitated setting, over a two‐ to four‐day period, during which teams concentrate on establishing system and project goals, roles, responsibilities, and plans. This paper describes the agendas and processes involved in producing Team Launches and Team Workshops.

5.4.2 Mousetrap: A Concurrent Engineering Simulation That Keeps Going…and going…and going

AbstractThe Department of Defense Systems Management College uses the Stored Energy Ground Vehicle Simulation (“Mousetrap”) to train future program managers in the application and power of concurrent engineering and the systems engineering process. The simulation has evolved over the past seven years into what we believe to be a world class concurrent engineering simulation, which additionally provides the military officers and DoD civilians a critically important industry perspective.Each student integrated product team performs the role of a defense contractor competing against other student “companies” in their quest for the single follow‐on production contract to be awarded after completion of the acquisition development cycle and a government supervised competitive “run‐off”. They respond to a government request for proposal, negotiate a contract and spend time over 14 weeks developing a life cycle balanced system, expending and accounting for labor and actual government funds for materials. They must conduct three acquisition phase based technical design reviews presented to an integrated government program office, and subsequently build and field a competitive prototype.

NASP program technology: An example of transfer benefit for the medical industry and spinback benefit for the government

Technology developed in the National Aero-Space Plane (NASP) program is finding its way into a variety of applications ranging from aerospace to automotive to medical. The NASP Technology Applications Integrated Product Team (IPT) is pursuing technology transfer opportunities to promote the wide use of NASP-developed or-inspired materials in these and other industries. While product innovations and enhancements serve the commercial sector well, they also spin back to the government in the form of cheaper, higher-performing systems and components.

Digraph Analysis As a Valuable Part of the Systems Engineering Process in Design Optimization

AbstractDigraph analysis, an approach to Boolean modeling and analysis of large systems, is a valuable technique when performed as part of systems engineering effort‐Digraph analysis provides modeling of physical and informational flow to evaluate and document decisions regarding design capabilities. It supports effectiveness analyses, design analyses, and trades in examining system interactions, fault tolerance, reliability, redundancies, and risks. A demonstration of how digraph analysis was used when performing systems engineering in an integrated product team environment on the Mars Environmental Survey (MESUR) program is given.

MANAGING INTEGRATED PRODUCT TEAMS DURING THE REQUIREMENTS DEFINITION PHASE

AbstractThis paper describes our experiences in managing Integrated Product Teams (IPTs) during the requirements definition phase of a hardware development and production project. IPTs were used to correct deficiencies found in hardware during field trials. The hardware had to be redesigned quickly with little risk to the rest of the program. The operating methods of these multifunctional teams will be described along with the tools and techniques used. Systems Engineering orchestrated the team efforts both from within the teams and from outside. We will compare the traditional teaming techniques with this new approach. The RDD‐100™ Computer Aided Engineering (CAE) tool was used very effectively in managing and documenting the requirements. An in‐depth look at the role of the Systems Engineer in this environment will be examined.

Mil‐Std‐499B and the Practice of Technical Reviews

ABSTRACTAlthough technical reviews are an important part of the systems engineering process, they have not received a great deal of attention in systems engineering literature. In this paper, technical reviews are discussed for a DoD acquisition program from both the government and contractor's perspective. Requirements for technical reviews that will be included in the about to be released Mil‐Std‐499B are summarized, including descriptions of types of reviews, review sequence, and review content. Opportunities for tailoring review requirements are discussed for several types of programs. Both government and contractor review responsibilities are discussed in light of the new incremental review and integrated product team approach in Mil‐Std‐ 499B. The various steps in the contractor's process for conducting a review are described, including the content of a contractor's technical review plan and the roles of each participant in a “typical” review. Techniques for obtaining approval of a technical review by closing out action items are discussed.

INTEGRATED MASTER PLAN / INTEGRATED MASTER SCHEDULE

AbstractThe Advanced Tactical Fighter (ATF) Engineering and Manufacturing Development (EMD) Request For Proposals called for several dramatic changes in the acquisition process along the guidelines proposed by the Packard Commission. The ATF EMD Program was to truly be an event‐based program, as opposed to being driven predominantly by a schedule produced before the proposals were submitted. How can a major aircraft EMD program be managed apart from a schedule? Of course, it cannot. For the F‐22 EMD Program, an Integrated Master Plan (IMP) was developed, defining all essential tasks in a hierarchial and Integrated Product Team format. The IMP describes the Events, Significant Accomplishments, and Accomplishment Criteria to be completed to the satisfaction of the SPO/Contractor team throughout the nine year EMD Program. The IMP indicates which Work Breakdown Structure element is primarily tasked with each Accomplishment Criteria, the multiple Accomplishment Criteria under a specific Significant Accomplishment, and the multiple Significant Accomplishments necessary to successfully demonstrate satisfactory Event closure. The IMP is a contractual document, without calendar dates. An associated Integrated Master Schedule expands the contractual IMP by adding an expected schedule to every Event, Significant Accomplishment, and Accomplishment Criteria. The IMS also adds sub‐criteria Tasks to some Accomplishment Criteria. In the early stages of the EMD Program, the IMP has already demonstrated its value by instilling a discipline to the concurrent engineering nature of the F‐22 Program that might otherwise have been very difficult to achieve.