IT Economics Corporation

IT Portfolio Management Seminars Earned Value Management Integrated Project Teams
Preparing Presentations Computing ROI CIO Success Hints


The Integrated Project Team - A Valuable Tool for Managing Projects

Integrated Project Teams

Integrated Project Teams are used in leading organizations and have been adopted by many federal and state government agencies. The document below will give you an understanding of the most important concepts underlying this approach. This material is excerpted from a Department of Defense document titled DoD Integrated Product and Process Development Handbook, August 1998. Although the document was produced some years ago, the concepts it explains remain valid.

The content of the Handbook is substantially larger than the amount reproduced here. We have taken the liberty of changing the formatting and doing minor editing so the exerpts will be an integrated and coherent piece.
The terms Integrated Product Team and Integrated Project Team are interchangeable. While the original DoD material used the former term, the material below uses Integrated Project Team.

Introduction to Integrated Process and Process Development (PPD)

Integrated Process and Process Development (IPPD) is a management technique normally implemented by Integrated Project Teams (IPTs). IPPD is currently in use in many commercial and government organizations. This guide was written to serve as a primer for the Defense Acquisition Workforce to foster, facilitate and understand the use of IPPD.

The IPPD Concept


IPPD has been mandated for the Department of Defense. IPPD is a management technique that simultaneously integrates all essential acquisition activities through the use of multidisciplinary teams to optimize the design, manufacturing, business, and supportability processes.

At the core of IPPD implementation are Integrated Project Teams (IPTs) that organize for and accomplish tasks that acquire goods and services. These multifunctional teams are the foundation of the process. The IPT decision-making processes and the empowerment of the teams may require cultural change in the way decisions are made in the Department.

This guide is a primer on IPPD. Nothing in this guide should be construed as directive in nature. Any processes described are examples. Those processes actually used should be decided upon at the appropriate time by the implementing organization and tailored for each application.


IPPD has its roots in integrated design and production practices, concurrent engineering, and total quality management. In the early 1980s, U.S. industry used the concept of integrated design as a way to improve global competitiveness.

Industry's implementation of IPPD expanded concurrent engineering concepts to include all disciplines, not just technical, associated with the design, development, manufacture, distribution, support, and management of products and services. Diverse segments of U.S. industry have successfully implemented this concept to become recognized leaders in IPPD practices, most notably in the auto and electronics industry. Many corporations have institutionalized the IPPD process and associated training programs. Several of these corporations were consulted in the development of this guide.

DoD defines IPPD as, "A management process that integrates all activities from product concept through production/field support, using a multifunctional team, to simultaneously optimize the product and its manufacturing and sustainment processes to meet cost and performance objectives." IPPD evolved from concurrent engineering, and is sometimes called integrated product development (IPD). It is a systems engineering process integrated with sound business practices and common sense decision making. Organizations may undergo profound changes in culture and processes to successfully implement IPPD.

IPPD activities focus on the customer and meeting the customer's need. In DoD, the customer is the user. Accurately understanding the various levels of users' needs and establishing realistic requirements early in the acquisition cycle is now more important than ever. Trade-off analyses are made among design, performance, production, support, cost, and operational needs to optimize the system (product or service) over its life cycle. In order to afford sufficient numbers of technologically up-to-date systems, cost is a critical component of DoD system optimization. Cost should not simply be an outcome as has often been the case in the past. Thus, cost should become an independent rather than dependent variable in meeting the user's needs.

Although there are common factors in all known successful IPPD implementations, IPPD has no single solution or implementation strategy. Its implementation is product and process dependent. A generic IPPD iterative process is shown in figure 1-1.

Figure 1-1. A Generic IPPD Iterative Process applies resources, including people, processes, money, tools, and facilities. The IPPD process reorders decision making, brings downstream and global issues to bear earlier and in concert with conceptual and detailed planning, and relies on applying functional expertise in a team-oriented manner on a global-optimization basis. It is necessary to understand early the processes needed to develop, produce, operate and support the product. Equally important are these processes' impacts on product design and development.

Basic elements of the iterative process are:

>>Requirements, a first step in the iterative process above, are generated by the customer in a negotiation among many parties, each with serious and important concerns.

>>Knowing and understanding the customers (command structure, doctrine, tactics, operating environment, etc.) and their needs is essential.

>>Integrating the user's requirements, logistical requirements, and the acquirer's budgetary and scheduling constraints is a fundamental challenge in DoD acquisition.

A Disciplined Approach includes five general activities:

  • understanding the requirements,
  • outlining the approach,
  • planning the effort,
  • allocating resources, and
  • executing and tracking the plan.

Decisions made using this approach should be re-evaluated as a system matures and circumstances (budgetary, threat, technology) change. A disciplined approach provides a framework for utilizing tools, teams, and processes in a structured manner that is responsive to systematic improvement efforts.

Tools in this IPPD process include:

  • documents,
  • information systems,
  • methods, and
  • technologies

that can be fit into a generic shared framework that focuses on planning, executing and tracking. Tools help define the product(s) being developed, delivered or acted upon, and relate the elements of work to be accomplished to each other and to the end product.

Examples of tools used include integrated master plans, 3-D design tools and their associated databases, cost models linked to process simulations/activity-based costing, development process control methods, and earned value management.

Teams are central to the IPPD process. Teams are made up of everyone who has a stake in the outcome or product of the team, including the customer and suppliers.

Collectively, team members should represent the know-how needed and have the ability to control the resources necessary for getting the job done. Teams are organized and behave so as to seek the best value solution to a product acquisition.

Development Processes are those activities which lead to both the end product and its associated processes. To ensure efficient use of resources, it is necessary to understand what activities are necessary and how they affect the product and each other. Examples include requirements analysis, configuration management, and detailed design drawings.

Product and Associated Processes include what is produced and provided to the customer. Customer satisfaction with the product, in terms of mission effectiveness, as well as operating and support aspects and costs, is the ultimate measure of the team's success.

Customer is the user and a team member and also the ultimate authority regarding the product. Any changes to the formal requirements driving the product/process development must come through negotiation with the customer.

This generic IPPD iterative process described above is a systems engineering approach. It differs from the long held view that systems engineering is essentially a partitioning, trade-off, control process that brings the "-ilities" and test functions together. This IPPD process controls the evolution of an integrated and optimally balanced system to satisfy customer needs and to provide data and products required to support acquisition management decisions which, themselves, are part of the IPPD/IPT process. This approach also transforms the stated needs into a balanced set of product and process descriptions. These descriptions are incrementally matured during each acquisition phase and used by DoD and its contractors to plan and implement a solution to the user needs. This process balances cost, system capability, manufacturing processes, test processes, and support processes, as identified in DoD Instruction 5000.2.

The IPPD process is an integrated team effort within DoD and contractor organizations and with each other. DoD crafts the basic acquisition strategy, almost always with industry assistance. Contractors usually play a significant role in development, design, and manufacturing with DoD in a management role. Both participate in each others' major activities through team membership, and the implementation and use of tools and technology.

IPPD Key Tenets

To implement IPPD effectively, it is important to understand the interrelated tenets inherent in IPPD. These key tenets, listed below, were outlined by the Secretary of Defense mandate on IPPD and are consistent with those found in industry:

  • Customer Focus - The primary objective of IPPD is to identify and satisfy the customer's needs better, faster, and cheaper. The customer's needs should determine the nature of the product and its associated processes.

  • Concurrent Development of Products and Processes - Processes should be developed concurrently with the products they support. It is critical that the processes used to manage, develop, manufacture, verify, test, deploy, operate, support, train people, and eventually dispose of the product be considered during product design and development. Product and process design and performance should be kept in balance to achieve life-cycle cost and effectiveness objectives. Early integration of design elements can result in lower costs by requiring fewer costly changes late in the development process.

  • Early and Continuous Life Cycle Planning - Planning for a product and its processes should begin early in the science and technology phase (especially advanced development) and extend throughout every product's life cycle. Early life-cycle planning, which includes customers, functions, 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.

  • Maximize Flexibility for Optimization & Use of Contractor Approaches - Requests for Proposals (RFPs) and contracts should provide maximum flexibility for employment of IPPD principles and use of contractor processes and commercial specifications, standards and practices. They should also accommodate changes in requirements. and incentivize contractors to challenge requirements and offer alternative solutions which provide cost-effective solutions.

  • Encourage Robust Design and Improved Process Capability - The use of advanced design and manufacturing techniques that promote (1) achieving quality through design, products with little sensitivity to variations in the manufacturing process (robust design), (2) a focus on process capability, and (3) continuous process improvement are encouraged. Variability reduction tools such as ultra-low variation process control similar to "Six Sigma" and lean/agile manufacturing concepts should be encouraged.

  • Event-Driven Scheduling - A scheduling framework should be established which relates program events to their associated accomplishments and accomplishment criteria. An event is considered complete only when the accomplishments associated with that event have reached completion as measured by the accomplishment criteria. This event-driven scheduling reduces risk by ensuring that product and process maturity are incrementally demonstrated prior to beginning follow-on activities.

  • Multidisciplinary Teamwork - Multidisciplinary teamwork is essential to the integrated and concurrent development of a product and its processes. The right people at the right place at the right time are required to make timely decisions. Team decisions, as a result of risk assessments, should be based on the combined input of the entire team (technical, cost, manufacturing and support functions and organizations) including customers and suppliers. Each team member needs to understand his role and support the roles of the other members, as well as understand the constraints under which team members operate. All must operate so as to seek global optima and targets.

  • Empowerment - Decision making should be driven to the lowest possible level commensurate with risk. Resources should be allocated to levels consistent with risk assessment authority, responsibility and the ability of people. The team should be given the authority, responsibility, and resources to manage its product and its risk commensurate with the team's capabilities. The authority of team members needs to be defined and understood by the individual team members. The team should accept responsibility and be held accountable for the results of its efforts. Management practices within the teams and their organizations must be team-oriented rather than structurally-, functionally-, or individually-oriented.

  • Seamless Management Tools - A framework should be established that relates products and processes at all levels to demonstrate dependencies and interrelationships. A management system should be established that relates requirements, planning, resource allocation, execution and program tracking over the product's life cycle. This integrated or dedicated approach helps ensure teams have all available information thereby enhancing team decision making at all levels. Capabilities should be provided to share technical, industrial, and business information throughout the product development and deployment life cycle through the use of acquisition and support shared information systems and software tools (including models) for accessing,exchanging, validating, and viewing information.

  • Proactive Identification and Management of Risk - Critical cost, schedule and technical parameters related to system characteristics should be identified from risk analyses and user requirements. Technical and business performance measurement plans, with appropriate metrics, should be developed and compared to best-in-class government and industry benchmarks to provide continuing verification of the effectiveness and degree of anticipated and actual achievement of technical and business parameters.

Integrated Project Teams (IPT)

Integrated Project Teams are cross-functional teams that are formed for the specific purpose of delivering a product for an external or internal customer.

IPT members should have complementary skills and be committed to a common purpose, performance objectives, and approach for which they hold themselves mutually accountable.

IPTs are the means through which IPPD is implemented. Members of an integrated project team represent technical, manufacturing, business, and support functions and organizations which are critical to developing, procuring and supporting the product. Having these functions represented concurrently permits teams to consider more and broader alternatives quickly, and in a broader context, enables faster and better decisions.

Once on a team, the role of an IPT member changes from that of a member of a particular functional organization, who focuses on a given discipline, to that of a team member, who focuses on a product and its associated processes. Each individual should offer his/her expertise to the team as well as understand and respect the expertise available from other members of the team. Team members work together to achieve the team's objectives.

Critical to the formation of a successful IPT are:

(1) all functional disciplines influencing the product throughout its lifetime should be represented on the team;

(2) a clear understanding of the team's goals, responsibilities, and authority should be established among the business unit manager, program and functional managers, as well as the IPT; and

(3) identification of resource requirements such as staffing, funding, and facilities. The above can be defined in a team charter which provides guidance.

A Typical Industry Approach

Each step identified in figure 1-2 is important in establishing IPTs to implement IPPD. It is representative of an implementation process found in industry. These steps should be tailored in scope depending upon the size of the program and type of IPT.

Figure 1-2. Generic IPTs Implementation Process (Industry)The intent of this sequence of steps is to insure that the team's mission, objectives, and end products are well defined, and that each team member's role and responsibility are clearly stated.

  • Establish First Tier Integrated Project Team - The selection of a first tier team, which provides strategic direction and corporate oversight, and review, is an important aspect of the process. Appropriate cross-functional team composition will optimize the chances for success.
  • Initiate the Program - The first tier team identifies/validates a need and organizes for program management by initiating a program.

  • Create/Review IPPD Plan - An IPPD Plan (a document containing an Integrated Master Plan, Integrated Master Schedule, and a Project Budget Baseline) should define the scope of the anticipated effort and role of the first tier IPT, and the inter-dependencies and expectations between the first tier and sub-tier teams.

  • Create and Initiate Sub-tier Teams - Once the first tier team has created an initial plan, the sub-tier teams are established. These sub-tier teams should also be multidisciplinary rather than functionally oriented and have specific charters that identify expectations and responsibilities in providing program support. Sub-tier team leaders should be members of the next higher tier team.

This approach to teaming differs from traditional program organizations, which usually focus on single-function disciplines. IPTs are responsible not only for designing the product and its associated processes, but also for planning, tracking, and managing their own work and the processes by which they do their work. Successful application of IPPD rests heavily on the ability to form, align, empower, and lead these cross-functional teams. By transitioning from the traditional use of mandated decisions to a style of leadership that operates through coaching and empowering, an open environment of rapid and honest communication and effective, timely decision making required by IPPD can be created.

The concepts of effective team formation apply to all types of teams. IPTs can be applied at various levels ranging from the overall structure of an organization to informal groups functioning across existing units. IPTs can be formally chartered or natural working groups. Implementation of IPPD, therefore, does not mean that an organization needs to restructure. However, virtually all successful, sustained implementations in industry have eventually entailed reorganizations or re-missioning of organizations or both. These reorganizations are generally undertaken after IPPD implementation has been initiated and experience has indicated a need to realign functions. The team is not the end goal of IPPD, but rather the means through which much of the work is accomplished. The teams are created for the specific purpose of delivering a product and its processes or managing a process for their customer(s).

An IPT structure can be optimized for the product/customer requirements. The number of teams, functional disciplines, and full/part-time members required to support the product development may be different for every program. In addition, team membership, including team leadership, may change throughout the product development cycle. The core members of the team, generally assigned full-time, provide continuity from one development phase to another.

Teams focus on achieving set goals and objectives. Metrics are a means for creating and maintaining that focus. When metrics provide meaningful data, IPTs can clearly see and understand their progress, and better allocate resources for the remaining tasks. Identification and management of risk are key responsibilities of each IPT.

Expected Benefits of IPPD

Applying the IPPD management philosophy can result in significant benefits to the customer, DoD, and industry. The primary benefits are reduced cost and schedule while maintaining, often increasing, quality. (Note: see Figure 1-3)

Figure 1-3 displays anticipated design changes resulting from IPPD implementation versus traditional (serial) acquisition approach, overlaid on a curve of relative cost of making changes.

  • In a traditional approach, the largest number of changes occur late in development, when change costs are high, resulting in higher program costs.
  • In an IPPD process, the bulk of changes occur early in development, when change costs are low, resulting in lower program costs.

With IPPD, a more balanced tradeoff is achieved among cost, schedule and performance. These gains are realized by the early integration of business, contracting, manufacturing, test, training, and support considerations in the design process, resulting in fewer costly changes made later in the process (e.g., during full rate production or operational test).

Return to Home Page

Copyright © 2005-2010 IT Economics Corporation. All rights reserved.