Los Angeles AFB, CA
Table of Contents
How to Use This Guide 1
The Evolution of Integrated Product Development 2
Definition of Integrated Product Development 3
Relationship of IPD to Other Command Initiatives 3
Chapter 1 Integrated Product Development Overview 5
What is IPD? 5
Benefits of IPD 6
Implementing IPD 6
Chapter 2 Applications 8
Module I New Acquisitions 8
General Principles 8
Defining the Requirement 9
Outlining the Program 10
Planning the Program 12
Conducting Source Selection 16
Allocating Resources 16
Tracking and Executing the Program 17
Module 2 Existing Acquisitions l9
Chapter 3 Integrated Product Teams (IPTs) 20
Organizational Structure 20
IPT Membership 22
Chapter 4 Training 24
Awareness Training 24
Team Training 24
Appendix 1 Sample Section L Instructions 26
Appendix 2 Quality Function Deployment 27
Appendix 3 IPD Implementation Plan 30
A key ingredient enabling us to achieve our Total Quality Leadership (TQL) cultural change is Integrated Product Developmentor IPD. The IPD philosophy is a new way of thinking about how we do business here at Space and Missile Systems Center. It represents a fundamental shift in focus away from our individual stovepipe mentality and towards delivering integrated systems to our customers.
This guide describes a framework for applying the IPD approach to your activity. It will help you understand how to find ways to work more closely with your customers; empower your people; enable everyone to make better program decisions; and structure your management data so Integrated Weapon System Management (IWSM) concepts can be applied more smoothly.
I am totally committed to the implementation of IPD and the cultural change that it implies. The IPD approach is part of the total quality methodology we must use to improve both our products and our people. IPD will help us achieve our TQL vision"A Great Place to Work Where Great Work is Done."
EDWARD P. BARRY, JR.
Lieutenant General, USAF /
Commander, Space and Missile Systems Center
How to Use This Guide
The purpose of this guide is to help you understand the Integrated Product Development (IPD) philosophy and how to apply it to your program or product.
It is a reference book, not necessarily intended to be read end to end. Read those chapters that are relevant to what you are trying to do. For example, if you are trying to apply IPD to a new contractual effort, read Chapter 2. If you are trying to develop teams, read Chapter 3. We suggest, however, that everyone review Chapter 1 as the first step. It provides a history of the development of the IPD approach as well as a description of the basic concept as it is today.
The Evolution of Integrated Product Development
The genesis of the Integrated Product Development Concept traces back in time to the President's Blue Ribbon Commission (also known as the Packard Commission) on Defense Management. The Packard Commission concluded that many of our weapon systems cost too much, take too long to develop, and by the time they are fielded, incorporate obsolete technology. Similar problems plagued selected U.S. industries, most notably the automotive and electronic. These industries improved their "competitive position" by concurrently designing their products and related production and support processes.
Prompted by the Packard Commission Report ("A Quest for Excellence", June 1986), the Under Secretary of Defense for Acquisition requested the Institute for Defense Analyses (IDA) to examine concurrent engineering practices. Encouraged by IDA's recommendations ("The Role of Concurrent Engineering in Weapon System Acquisition", December 1988), the Undersecretary provided interim acquisition guidance to the military services (March 1989) concerning concurrent engineering and its role in the acquisition process.
The concept emphasized formation of multidisciplined teams in support of product development. It was characterized by:
(a) Focus on the customer's requirements
(b) Quality is the result of improving a process
(c) Process improvement is a neverending responsibility.
Sustainable momentum for acquisition process change was assured when the Secretary of Defense presented the "Defense Management Report to the President" (July 1989). This report was prepared in response to the presidential directive to develop a plan to accomplish full implementation of the recommendations of the Packard Commission. (This Defense Management Review also examined the improvements envisioned by the GoldwaterNichols Defense Reorganization Act of 1986). The directive specifically targeted DOD Acquisition Practices and Procedures. Subsequently, DOD Directive 5000.1 (dated 23 February 1991), based on the principles contained in the "Defense Management Report to the President", established a disciplined management approach for acquiring systems and materiel that satisfy the operational customer's needs.
The Integrated Product Development concept continued to evolve under the aegis of the Air Force Systems Command. The Advanced Tactical Fighter program management and industrial partners (circa 1991) couched the philosophy of concurrent engineering in an innovative management structure, called the Integrated Management System. It was through this mechanism that the Air Force hoped to maximize:
(a) Industry involvement earlyon in the development of a "Request for Proposal" and commitment upfront to an executable program
(b) Simultaneously improve visibility and understanding of program risks
Further maturation of the Integrated Product Development stemmed from the Air Force Materiel Command and its development of the Integrated Weapon Systems Management (IWSM) approach. The White Paper, "IWSM in AFMC", dated January 1992, declares that System Program Offices within the product development centers "will use a management philosophy known as Integrated Product Development". AFMCR 500l l, dated 1 Nov 1992, declares that the fourth key element of the IWSM philosophy is the use of Integrated Product Teams.
Definition of Integrated Product Development
The definition of IPD, as well as and explanation of the philosophy and its basic tenets, is provided below:
Integrated Product Development is a philosophy that systematically employs a teaming of functional disciplines to integrate and concurrently apply all necessary processes to produce an effective and efficient product that satisfies customer's needs. Product, in this sense, is not only what is delivered to your customer (e.g., hardware, software, services, and documents), but also processes (e.g., design, manufacturing, test, and logistics) which make the product possible. Products range from complete weapon systems to individual end items and from request for proposals to briefings, as well as policies like those for the Integrated Acquisition Strategy Process and the Configuration Control Board.
Relationship of IPD to Other Command Initiatives
IPD shares many useful, synergistic characteristics with two other SMC management initiatives: Total Quality Leadership (TQL) and Theory of Constraints (TOC). IPD is a benchmark systems engineering process. Within the context of the TQL principle of continuous process improvement, IPD represents the process and resources to provide rapid, cost effective, customer focused product development. Below are listed the ten principle core values and concepts of total quality leadership, taken from the Malcolm Baldrige Award Criteria, as they apply to IPD.
1. Customer Driven Quality. IPD stresses a customer focus and analyzes the value and effectiveness of the total system from a customer's perspective, specifically "right product, right place, right time, right price, and right service".
2. Leadership. IPD emphasizes a revised role for the organizational leader, from that of the traditional hierarchical pyramid. The new leader is coach, trainer, resource provider and policy/strategy maker. TOC further defines the new leaders role as "Socratic", with three tasks: determining what to change, what to change to, and how to change.
3. Continuous Improvement. IPD assumes some sort of competitive environment in which the customer has a choice and increasingly higher expectations for our products which demand continuous process improvement.
4. Employee Participation and Development. IPD stresses capitalizing on total system optimization by involving all functional skills in an integrated decision making process. TQL and IPD go further and stress employee development through structured training, experience, career enrichment, and recognition.
5. Fast Response. IPD sees product cycle time as a major competitive advantage. It recognizes the relationship between cycle time reduction, increased product quality, lower overall costs, and responsiveness to changing customer requirements.
6. Design Quality and Prevention. IPD recognizes this fundamental concept of concurrent engineering. To have the best product, it is imperative to obtain and employ during design the expertise of all subsequent process interfaces (manufacturing, test, operational use, repair, modification, disposal, etc.).
7. LongRange Outlook. IPD stresses that the organization must plan on a long term horizon, deploy its energies and resources through a quality plan to achieve the objectives and constantly reevaluate and replan. TOC stresses a road map process that identifies the corporate goal and then selects where the organization wants to have its system constraint. TOC seconds the concept of continuous reevaluation.
8. Management by Fact. IPD stresses flow out processes and establishing process check points to determine the health of the process. In addition, all philosophies stress accurate measurement and open, fear free communication. TOC emphasizes information particularly at the system constraint IPD further takes management by fact and stresses a framework decision information system that integrates all phases of product life through a consistent and logical product breakdown structure.
9. Partnership Development. IPD speaks to the power of integrated teams and partnerships beyond the bounds of organizational or command lines.
10. Public Responsibility/and citizenship. Beyond the active partnerships of customers, teams and suppliers, IPD recognizes that the "whole" system goes beyond the boundaries of the product, to include the community and environment within which the product is developed, tested, manufactured, used, repaired, and disposed of.
Chapter 1 - Integrated Product Development Overview
What is IPD?
IPD is a management philosophy based on sound business practices and common sense decision making. It involves bringing the right people to the right place at the right time to make the right decisions. As defined earlier, IPD is "a philosophy that systematically employs a teaming of functional disciplines to integrate and concurrently apply all necessary processes to produce an effective and efficient product that satisfies customers' needs." Central to this definition are the following key features of IPD:
Product orientation. The IPD management philosophy focuses on the products to be delivered to the customer. The product, however, may take several forms. While an acquisition organization may deliver hardware and software, a sustainment organization may provide a service to its customer. A staff organization may provide policy to its customer. In each case, these products dictate the ultimate success of the organization in the eyes of the customer.
Crossfunctional teaming. All functions that impact the performance of the product should have a role in the development and management of the product. Implementation of this concept requires effective teaming between the functional representatives. The product's customers and suppliers should be members of the team to ensure that product requirements are understood and properly flowed to lower tier organizations. The Integrated Product Team (IPT) then has the ability to make intelligent decisions based on the combined input of engineering, production, logistics, program management, contracting, financial management, sustainment, operations, and other disciplines.
Empowerment. To be effective, an IPT should be given requisite authority and responsibility for its product. It should be the goal of management to drive decisions to the lowest appropriate level commensurate with risk. Adequate resources should be provided to the teams so that they conduct business in an integrated and empowered manner. It is also incumbent upon management to ensure proper training of empowered people.
Upfront planning. IPD requires a deliberate, upfront planning effort by the IPT early in the product's life cycle. While the early phases of product development only consume a small part of the product's total cost, the decisions that are made there dictate over eighty percent of the total cost. Downstream changes to the product are extremely costly and usually require extensive rework and reconfiguration of the product. A key to this process is the transition to eventbased planning that focuses the maturation of the product on specific events and accomplishments rather than a scheduled point in time.
Benefits of IPD
Applying the IPD management philosophy will result in significant benefits to the organization and the product it delivers. The benefits gained from IPD are consistent with the objectives of streamlined acquisition and continuous improvement.
Reduced time to field system. Decisions that were formerly made sequentially, e.g. by engineering, then manufacturing, then logistics, etc., are now made in an integrated forum. Downstream changes to the product are reduced due to the upfront planning between functions. The result is a significant reduction in the time it takes to deliver the product to the customer.
Reduced system cost. The cost of the system is reduced in two ways. First, the need for redesign, rework, or contract modifications is reduced since all appropriate disciplines are involved concurrently in the decision processes. Second, a reduction in the time to deliver the product to the customer will reduce cost.
Improved quality. Smarter, integrated decisions will improve the quality of the product.
Programs that are easier to manage. The IPD management philosophy structures the program's resources along product lines and gives each team the authority and responsibility to deliver their product. It also focuses risk management efforts by tying risk directly to the product. The daytoday management of the program is simplified by the integration of management structure and its associated tools.
An organization must undergo a fundamental change in the way it operates to implement IPD. To do this, management must be successful in changing the organization's culture and must put in place a framework to facilitate the change.
Cultural change. The tendency of an organization to make decisions in a sequential fashion has led to a business culture that separates the various functional areas within the organization. There has also been an organizational reluctance to interact with the customers and suppliers. The IPD management philosophy requires that all barriers be torn down so that integrated decision making can occur. This requires a change in the culture that drives the day to day operation of the organization.
To have the most chance for success, senior management must lead this cultural change through leadership by example. If the senior leaders do business in an integrated fashion, they will have a powerful effect on the actions of the entire organization. Additionally, the empowerment process can only begin at the ton of the organization. It is there that the first steps must be taken to release the reins of control to give the authority and responsibility to the people that know the products best.
Framework. A management framework that emphasizes IPD is essential for facilitating a change in the business culture. The traditional culture has created organizations that are structured along functional lines and management tools that suboptimize a particular function while making it difficult to communicate with other functions. For the IPD management philosophy to work, organizations should bring all resources to bear on the products it delivers to its customers. Management tools should be integrated to facilitate communication between functions and create a decision making process that emphasizes teaming and upfront planning. Chapter 2 of this guide presents approaches to applying this management framework at various points in a system's life cycle and Chapter 3 provides detailed guidance on organizational structure and the use of Integrated Product Teams (IPTs).
Chapter 2 Applications
The following modules present approaches to implementing an IPD framework at different phases in a system's life cycle. The modules are designed to build upon existing tools such as the Air Force Acquisition Model. Where appropriate the modules will refer to the existing tools for further guidance and direction. Most of these tools can be easily obtained through our local staff organizations.
Module 1 New Acquisitions
The success of implementing IPD largely depends on our ability to create an effective framework for the program. In a new acquisition, this framework is established in the Request for Proposal (RFP). The RFP identifies the detailed requirements for the system and defines how the government plans to manage the program and execute a contract. It is imperative that an appropriate amount of upfront planning occur prior to RFP release since changing the framework after contract award not only will incur excessive costs but will impose an unacceptable amount of risk on the program.
Perhaps the key to performing effective upfront planning is the membership of the RFP preparation team. An RFP should be developed with the same people that will manage the contract after the source selection. The team membership should not only include the project officers and Integrated Product Teams (IPTs) that will constitute the core of the organization managing the contract, but also have representatives from the senior management and staff organizations. Additionally, customer representatives should be considered part of the team since the successful application of their requirements will truly dictate the success of a program.
Another important element of proper planning in the RFP process is the involvement of the suppliers, which in most cases are corporations in the defense industry. In addition to helping them understand our requirements prior to source selection, an effective line of communication with industry prior to release of the RFP will provide feedback which will greatly enhance the quality of the RFP. We should never lose sight of the fact that the contractor is the true expert on developing and producing the system we require. In most cases, communication beyond the traditional draft RFP should occur. Regular meetings, incremental release of RFP elements, and making use of electronic bulletin boards to run ideas past industry are all good ways of making this early communication occur. One of the primary complaints of industry is that RFPs are not well written (i.e., poorly planned) and limit their ability to submit a good proposal for source selection. As we move towards implementing IPD throughout all our programs, it will be essential that we help industry understand our needs and approaches to putting the framework in place prior to RFP release and contract award.
The following sections outline the general flow of an acquisition as shown in Figure 2.1. A project officer and/or IPT should be able to follow the process presented and conduct an acquisition that is well planned out and implements the IPD philosophy.
Defining the Requirement
Establishing Customer Requirements. The first step in the acquisition process is establishing the requirements of your customers. No program has much chance for success without welldefined requirements that can be flowed down into the products and processes that make up the system. All of the elements of the acquisition are at risk until firm requirements are set down for the program.
The requirements process begins by identifying your customers. The most obvious customer is the organization that will actually operate the system once it is fielded (e.g. AFSPACECOM). Most of the current requirements process is based on receiving input from this operator. You should not, however, treat the operator as your only customer. Other customers include the headquarters, the local staff agencies, and other government agencies. Each of these customers have requirements that must be met for us to put out an RFP and run an acquisition program. In fact, the contractors can be considered a customer in the RFP process since they must understand our requirements. You also should not forget that you are your own customer since you will have to manage the contract you are creating.
With the list of customers assembled, the next step is to actually gather the requirements. For some customers, like the operator, formal processes are already in place to begin this process. For instance, the operator should already have an approved Mission Need Statement (MNS) and Operational Requirements Document (ORD). For other customers, a process will have to be established for gathering requirements. One process that works well for this is called Quality Function Deployment. This tool provides a systematic approach to understanding, prioritizing and documenting customer requirements. A more detailed description of this tool can be found in Appendix 2.
The key to effectively gathering requirements from any customer is communication. It is important to develop a strong team relationship with all customers so that the flow of information is not only timely, but useful. Many customers will wait until the last minute to present their requirements (i.e. during a review process) if they don't feel like they are part of the team from the beginning. Spending the time up front to get good requirements will save countless days downstream trying to correct everything you've done for a customer requirement that was not identified or ignored.
Translating Customer Requirements. You should always concentrate on gathering the minimum requirements necessary to field the system. Requirements should be performance oriented. In other words, the requirements should describe the way the system must function once it is fielded. This will give the program the necessary flexibility to design the best system. You should avoid "howto" types of requirements that constrain the acquisition unnecessarily. You should document these performance oriented requirements in a functional specification like the system specification described in MilStd490. The system specification will be the cornerstone of the acquisition since the rest of the RFP will provide the tasking and contractual vehicles to meet its requirements.
Preparation of the system specification should occur concurrently with the preparation of the operator's ORD. In addition to saving the time associated with serial preparation, preparing the documents in parallel allows the operator to run the requirements by the acquisition personnel prior to finalizing their ORD. It also gives you a chance to work closely with the operator to ensure that the requirements are correctly translated into specification language.
The system specification should be prepared during the Concept Exploration (CE) and Demonstration/Validation (Dem/Val) phase of the program. You should provide a baselined system specification to the offerors as part of the Engineering and Manufacturing Development (EMD) phase RFP. The offerors should then be required to submit system segment specifications as part of their EMD proposals. This direction belongs in Section L of the RFP as part of the specific instructions to the offerors. The purpose of having the offerors prepare and submit segment specifications is to see how each offeror breaks their system into products and how the systemlevel functional requirements are allocated to each of the products.
Outlining the Program
The next step in the acquisition process is to outline the program with respect to the products of the system. One of the fundamental tenets of IPD is product orientation where all activities in the program are focused on the products that are actually delivered to the operator. You should break out the products to a level commensurate with the risk associated with acquiring the product. In most cases, it is sufficient to break down the products two levels below the overall system. The plan will break out the products to a lower level in the proposal and provide a specification tree that follows the same breakout. A sample breakout is provided in Figure 2.2.
You may also have to identify some of the management processes that apply to multiple products, especially those that integrate the products into a complete system and control the contractor's interactions with the government. Examples might be integration working groups, program reviews, configuration management, data management, and cost reporting. These processes need to be identified since they will flow into the RFP.
Using this data, you prepare a Work Breakdown Structure (WBS). The WBS should mirror the product breakout and provide a numbering system that will flow through the entire RFP. The overall system being procured becomes the Level 1 WBS and the products underneath the system become the lower level WBS elements. This is consistent with the examples in MilStd881 WBS elements should also be provided for the processes mentioned above. However, the process element should be inserted below the product that it serves. For instance, since systems engineering integrates Level 2 products into a complete Level I system, it would become a separate Level 2 WBS element called Systems Engineering/ Program Management. The key is to avoid breakouts based on the functions within the program since, under the IPD philosophy, the product breakouts are crossfunctional.
The WBS should also establish a numbering system that will serve as a baseline for developing the rest of the RFP. The numbers are usually 4 or 5digits without periods in between. For instance, if the first Level 2 product is the Space Vehicle, it might be numbered 1000 under the overall system 0000. The first subproduct under the Space Vehicle would then be numbered 1100. An example of this numbering system can be found in Figure 2.3.
Establishing a preliminary productoriented organization is the next step in the process. Since you will manage the program with a product focus and develop the RFP like you plan to manage the program, it makes sense to establish teams of people that will address the requirements of each product and translate those requirements into the RFP. To support the IPD philosophy, these teams should be crossfunctional in nature. That means that each product team will contain the resources to address all the functional specialties that will play a role in the acquisition of that product. For example, the team should have representatives from program management, engineering, manufacturing, logistics, contracting and financial management. The membership of the team will be dependent on the maturity of the program. Obviously, a product team in a production program would require fewer design engineers than manufacturing specialists. The team should also have a leader that is selected using the guidelines from Chapter 3. This organizational structure will eventually be aligned with the winning contractor's organization and finalized to become the SPO's organization during the execution of the contract.
Planning the Program
One of the key tenets of IPD is upfront planning. Since altering contracts is not easy, most of this planning should occur prior to contract award. Their are several goals to this upfront planning activity. The first is to define the core program that must be accomplished. The core program consists of those activities that you must perform to have a program. The second goal is to put in place an integrated management framework. It is important that you set up the entire program around this framework to ensure that IPD flourishes and the program is easier to manage. Finally, the core program risk must be evaluated to allow adequate resources to be allocated.
Define the Core Program. The first step in the planning process is to define the key program events that must occur throughout the life of the program. The type of event will depend on the phase the program is in. For instance, a key event during the design phase might be the critical design review while a key event during production might be the completion of acceptance testing. Events may also be nonrecurring or recurring. For example, there may be key events during the production phase that will recur each time the system is manufactured. These key events should be provided to the offeror in Section L of the RFP. The offerors may add key events to the list if required by the unique system they will propose.
Once the events have been established, you should define the work that must be accomplished to get to each event. In the RFP, this work is defined in an example Statement Of Work (SOW) that you will provide to the offerors as part of Section L, Proposal Preparation Instructions. The key here is to only define the minimum requirements of the government. This way each offeror has the flexibility to define the work for the unique system it will propose while still meeting the government's minimum requirements. Each offeror will prepare a SOW and submit it as an attachment to the contract in the source selection. The result is a SOW written by the people who will actually perform the work and will, therefore, achieve a greater deal of commitment from the contractor.
The example tasking in the SOW should be defined by product and process using the numbering system established in the WBS. Each IPT should prepare the tasking for its product. The tasking for each product should be crossfunctional in nature and cover all work that must be performed on that product for the life of the program. This tasking will serve as a major element of the tool kit that each IPT will use to manage the contract after award. A model of the example SOW for Section L of the RFP can be found in Appendix 1.
Establish an Integrated Management Framework. The next step in the planning process is to have the offeror describe to you how they will accomplish the work in the SOW and tie the work to the key events defined earlier. The vehicle the offeror will use is the Integrated Master Plan (IMP). For each product, the offeror will identify the significant accomplishments that must be met to complete the work defined in the SOW. Each significant accomplishment is then tied to a key program event. Additionally, the offeror will provide success criteria for each significant accomplishment so that you know how to determine that the accomplishment is completed. One thing to keep in mind is that there is no schedule information in the IMP. The IMP should be event driven and not tied to any date. For the source selection, the offeror will prepare an IMP like the one in Figure 2.4 and submit it as an attachment to the contract.
You will find that there are SOW tasks, especially for management processes, that do not fit well in the above IMP format. For instance, it may be difficult for the offeror to identify an event or significant accomplishment for configuration management. It is important that these processes are also properly planned prior to contract award. Rather than requiring the IMP format described above, you should request that the offeror prepare a separate narrative section within the IMP. This narrative should describe the offerors approach to performing the process and identify any relationships or interactions with the program office or other government personnel. It should also identify any governing documents. The narratives are usually limited to 5 pages and are submitted as part of the IMP during source selection. After contract award, these narratives will become part of the contract along with the rest of the IMP.
The direction to the offeror to prepare the IMP should occur in Section L of the RFP. These instructions should explain what an IMP is, provide guidelines for developing the IMP, and provide an example format. You should also provide a brief IMP instruction under each WBS element in the example SOW that describes the desired scope of the IMP for that product and identifies any unique IMP requirements the government might have such as narratives. An IMP should be required for each phase of the program from Concept Exploration through Production.
Each IPT should also identify any CDRL items required for its product. Care should be taken to avoid repeating the same CDRL item for each IPT. Those items could probably be consolidated into single DD Forms l423 with each interested IPT on the distribution list.
There are two CDRL items that must be developed for the RFP that are major elements of the IPD tool kit. They are the Integrated Master Schedule (IMS) and Technical Performance Measures (TPMs). The Integrated Master Schedule is usually received about once a month from the contractor and puts a date to the events and activities described in the IMP. An example of the lMS and its flowdown from the IMP is shown in Figure 2.5. The TPMs are measures of the technical maturity of the system and serve as an important tool for the IPT to track the progress of the system. The offeror should be required to provide the first submittal of each of these CDRL items with the proposal. Each IPT should identify to the offeror any TPM's that it feels are mandatory for managing the development of the product.
At this point, the RFP is ready for release. Prior to releasing the final RFP and ceasing all discussion, it is important that you feel comfortable with the offeror's understanding of your requirements in the RFP. The upfront planning that the offeror's will do prior to source selection will be extensive and a great deal of it will be put on contract at award. If the offeror prepares its proposal with a misunderstanding of the requirements, you will go through a great deal of pain trying to fix it after contract award.
Conducting Source Selection
The offerors' proposals will come back with an integrated IPD "tool kit" using the single numbering system. To take advantage of this package, the source selection should be conducted under the same framework that developed the RFP. The areas of evaluation, therefore, should match the WBS structure, and the evaluation teams should be the IPTs (including the product integration team) that will run the program after contract award. The exception to this, however, is the cost evaluation. Due to regulatory constraints, each IPT's cost manager will be detailed to a cost team to perform an independent evaluation. You will also be required to have a past performance evaluation team that should have adequate representation from the various IPT's and functional specialties.
The IPT's should develop items and evaluation standards prior to source selection that focus on the offeror's approach to meeting the requirements of each product. The actual evaluation will then rely heavily on the information provided in the offeror's SOW and IMP since these documents will reflect each offeror's unique approach. Traditional proposal volumes should also be required from the offeror's for each WBS element to provide supporting information on the offeror's particular approach.
In many cases, you will require more people on the IPTs during source selection than you needed to write the RFP. If this is the case, it is important that the new people be trained on the IPD approach prior to entering the source selection. Details on the types of training that would be useful can be found in Chapter 4.
After awarding the contract, you and the contractor will have to allocate adequate resources to effectively manage the contract and perform the work. The key here is to base the allocation of people, dollars and schedule on the assessed risk of the program. In other words, the higher risk areas of the program should have a greater allocation of resources than the lower risk areas. It is important that the government's allocation of the resources mirror the contractor's allocation so that the management of the contract can be done in a team fashion and make maximum use of the IPD tools established in the RFP phase of the acquisition.
Develop the Organization. The process of allocating people to run the program results in a finalized organization. The first step in this process is to examine the products identified in the RFP. You should work with the contractor to decide if an organization based on those products is the best one to run the program now that the details of the system are known. The goal is to match the government and contractor organizations so that an IPT is really one team with membership from both the contractor and government. This mirroring will make the contract easier to manage using the IPD "tool kit." If the government and contractor mutually decide to alter the organization from the RFP, an administrative change to the contract will have to be made to adjust the WBS, SOW and IMP. The second step in the personnel allocation process is to determine the proper manning for each part of the organization. This allocation should follow the guidelines identified in Chapter 3 and also be based on a risk assessment. For instance, if the team assesses that the greatest risk in the spacecraft is in the attitude control thrusters, a greater proportion of propulsion engineers might be included in the spacecraft IPT. It is also important that the IPT membership adequately represent all functions that will bear upon the performance of that product including the users and suppliers. The final personnel allocation should be agreed to by both the government and contractor.
Allocate Dollars. The process of allocating the dollars assigned to the program follows the allocation of personnel. This allocation will have more of an impact on the contractor than the government. One of the tenets of IPD is to drive authority and responsibility to the lowest level of the organization commensurate with risk. What this means is that the program manager should assign fiscal responsibility to each IPT rather than allocating out by function. To the government program office, this simply affects the way we manage the costs through C/SCSC. The WBS and C/SCSC are aligned so that the IPT can monitor the cost accumulated for its specific product. The contractor, however, should give its IPTs the necessary budget to accomplish the tasks it must perform to deliver its product. The contractor's IPT chief then has the authority to allocate the budget according to the risk associated with developing and producing its product.
Allocate Time. The final allocation of resources involves assigning time to the IMP. The contractor will perform the bulk of this allocation by identifying a schedule for each of the accomplishments and criteria in the IMP. The contractor will document this information in the IMS that is delivered to the government as a CDRL item in the contract. The government's role in this process is to ensure that the contractor's schedule meets the delivery schedule in the contract with the least possible risk. This CDRL item is usually delivered each month and requires approval by the government.
Tracking and Executing the Program
The tracking and executing of the contract will undoubtedly be the largest phase of the acquisition effort. The key to making this phase easier to manage is effectively using the integrated program structure. The integrated "tool kit" developed as part of the RFP is now part of the contract (Figure 2.6). Each IPT should be using the tools to focus on the cost, schedule and performance of the product it is responsible for. The senior management of the program needs to drive decisions to the lowest level commensurate with risk. In other words, since the IPT is the body of knowledge that is the most familiar with its product, decisions affecting the performance of the product should be made by the IPT whenever appropriate.
For development programs, the value of the TPMs cannot be understated. The TPMs are the true metrics for the success of the program in that they indicate how well the system meets the user's requirements. They also help to provide a balanced system view that will reflect the effectiveness of the data generated using the tools under the single numbering system. In other words, the adequacy of the allocation of resources based on the initial risk assessment will be apparent from the technical maturity of the system evidenced in the TPM data. Since the allocation of resources is an ongoing process; the IPTs and/or senior management can make adjustments based on this information.
The success of the program will also depend heavily on the exchange of information between the program office, the contractors, and the user. It is important that the necessary steps be taken early to establish a process of open data exchange. Although the method of exchange will depend on the unique conditions of the program, the methods can range from regular meetings with all parties to complex management information systems. At the very least, however there needs to be an effective way to transfer documents between the program office and contractor to avoid lengthy review processes that may hold up the program.
Finally, an ongoing training program must be established that will refresh the existing team members and educate the new members on the details of the IPD approach. Since this approach to program management varies from some of the more traditional approaches, the team members need to receive this training so that they understand how to make maximum use of the IPD "tool kit" and realize the full benefit of the IPD approach. This training especially applies to the senior management within the program office since the IPTs will find it difficult to manage in a manner different from their superiors. Guidelines on the type of training that should be conducted can be found in Chapter 4.
Module 2 Existing Acquisitions
While it may be easiest to institute the IPD managementphilosophy on new contractual efforts, ongoing acquisition programs can also derive many benefits. Product orientation is a fundamental tenet of IPD that can be applied to any organization. The introduction of IPTs as described in Chapter 3 will focus the organization on its products and facilitate crossfunctional interaction. Program data can be integrated with the IPTs, improving the decision making process. All this can lead to reduced time, reduced cost and improved quality for the remainder of the program. The emphasis on integrated teamwork and decisionmaking can also facilitate m implementing the principles of Integrated Weapon System Management.
A key decision in determining how to introduce IPD into an existing program is whether or not to restructure the contracts to follow the framework of the Integrated Program Structure described earlier in this chapter. Of prime consideration here is the amount of performance period remaining on a contract. If a contract is nearly complete, the effort needed for the restructure may not be worthwhile. In that case, careful consideration and planning should be devoted to developing the "tool kit" that will be provided to the teams. If a contract restructure is deemed appropriate, the guidance in Module 1 applies.
One approach for introducing IPD into an existing program that has worked well included establishing a Steering Committee and a Working Group and writing an IPD Implementation Plan (See Appendix 3).
The Steering Committee consists of the System Program Director, the functional directors and key contractor managers. They provide overall guidance and approval to the efforts of the Working Group and determine the objectives of the IPD implementation effort.
The Working Group is made up of people from across the program office, encompassing a broad range of grades and functional specialties. The plan describes the objectives of implementing IPD and their key management processes. It lists the products of the program and the teams that would be used to manage them. The plan explains the "tool kit" that the teams will use to make cost, schedule, performance and support decisions. The plan also provides guidance on how the teams should work internally and how they should interact together.
Chapter 3 Integrated Product Teams (IPTs)
One aspect of IPD management philosophy is the creation of an organization with a product orientation that facilitates crossfunctional teaming. At the macro level, this entails setting up a structure for the organization that uses a hierarchical arrangement of both Integrated Product Teams (IPTs) and functional staff. The IPTs manage the products delivered to the customer while the functional staff maintains technical excellence within the program.
The overall structure of the organization can be broken down into two levels, the system level and the product level, as shown in Figure 3.1.
System Level. The system level of the organization consists of the Program Manager and the functional directors. The functional directors perform five major roles within the organization.
First, the functional directors serve as the systemlevel IPT along with the Program Manager and IPT team leaders. In this capacity, they act as a crossfunctional team to advise the Program Manager on issues that affect overall system performance and ensure that the various products within the organization integrate into the toplevel system.
Second, they are responsible for managing the personnel aspects of their discipline in the program office. They provide qualified people to support the IPTs. They are responsible for the continuing professional development and training of their people assigned to IPTs.
Functional chiefs are also responsible for the technical excellence of their functional area. They should continuously strive to improve the processes that are being used within the IPTs to manage the product. They should also keep abreast of developments outside the organization that may affect their processes and the overall system. These developments may include policy changes, legal developments or technical breakthroughs. For example, the director of contracting would strive to continuously improve the contract management processes used by the IPTs as well as keeping a breast of changes to the FAR.
In addition, functional chiefs would provide a home for adjunct team members that are not physically located with a single IPT. As a part of the normal management of resources within an organization, there will be times when people must be shared among IPTs, especially when they possess very specialized skills or are very limited in number.
Lastly, the functional directors interact with higher headquarters personnel and senior representatives from customers and suppliers on issues relating to the overall system.
Product Level. The product level of the organization consists of a hierarchy of IPT's that report directly to the Program Manager. These IPTs are empowered with the authority and responsibility to deliver their product to the customer. For the lowerlevel IPTs, the customer is the next higher level product. For example, the customer of an IPT responsible for the space vehicle payload would be the IPT responsible for the overall space vehicle. This hierarchy is followed to the highest level IPT whose responsibility is to deliver the product to the end customer. In most cases, this is the systemlevel IPT and the customer is the operating command.
To determine the level of IPT breakout, the program manager should analyze the risk associated with each product. A product that possesses a high degree of risk to satisfying the needs of the customer would justify the creation of subproduct IPTs. On the other hand, a product that possesses little risk may be managed at a higher level. The guiding tenet here is that the organization is broken out by products and not by the functions.
Another aid to the successful implementation of this hierarchical structure is a focus on integration. An integration team at each level can help the IPTs at that level ensure their individual products will successfully integrate into the next higher level product. For example, an integration team would ensure that the payload and spacecraft integrate into the space vehicle. The role of this integration team is not to perform the integration, however, but to facilitate discussion between the IPTs.
To be effective, an IPT must include representatives from all the relevant disciplines that play a significant role in the performance of the product and be facilitated by a strong leader.
Team Members. Selection of the appropriate team members will depend on the unique characteristics of the product in terms of performance and risk. The first consideration must be given to any discipline that has an effect on the performance and life cycle support of the product. Representation from these disciplines is necessary to ensure that integrated decisions are made and sequential processes are avoided. However, the team should be kept to a manageable size to be effective (810 members is a good goal). The selection of the fulltime team members, therefore, will depend on the risk associated with the product. he team must examine the product to determine which disciplines present the most risk to its success and select the team members based on this information.
IPTs will likely have two types of members: core and adjunct. Core members are the fulltime members of the IPT; adjunct members participate on a parttime or as needed basis. While colocation facilitates the most effective communication within a team, there will be times when a given discipline is not represented on a full time basis. This situation may occur if a person with specialized knowledge is required by multiple teams or if the risk or workload associated with that discipline did not justify full time membership, or if a team member (ea. ALC member, contractor) works in another location or city. In both cases, a form of matrix management must be used. The functional directors will control the allocation of these people, and any team personnel requirement will have to be worked with them directly.
It should also be noted that physical colocation is the preferred approach when setting up IPTs. Colocation opens and maintains frequent channels of communication that are lost if team members are located in other buildings and only attend meetings. However, the establishment of daily meetings, continuous sharing and understanding of ideas and the formation of subgroups to work on particular issues can help alleviate this problem.
Team Leader. The role of the team leader is to keep the team focused on integration and decisionmaking. The team leader is not necessarily the supervisor of the team. Consensus decisionmaking is encouraged. With this role, the selection of an effective team leader is crucial to the successful functioning of the team. While some individuals can be good managers or experienced technicians, they may not be able to function as an effective leader of an IPT. There are several factors that should be considered when selecting a team leader:
Team player. The team leader should be able to guide, encourage and coach the team's operation. The team leader should have the attributes of effective leadership: tact, diplomacy, competence, and the ability to listen and move the group towards consensus. The leader should help the team to achieve balanced, integrated decisions without dominating the process.
Communication skills. The team leader should be an effective communicator. The leader should be able to advocate the teams conclusions and recommendations to others and to work effectively within the framework of the next higher level IPT in the organization.
Broad knowledge. The team leader should be familiar with the various disciplines that affect the performance of the product they are responsible for. This will enhance the cross functional interaction within the IPT and help ensure that the decision making process does not become dominated by one discipline.
Chapter 4 Training
The single most important factor contributing to IPD success is education and training in the IPD management philosophy. IPD is a new way of doing business, a cultural change. As such, the entire program team needs to understand the basic IPD approach, its benefits, and how to apply it. This training should be conducted as a series of building blocks, with each session building on the last. A combination of formal briefing and handsontraining is recommended. Program offices are encouraged to use their own facilitators or trainers as much as possible. The Acquisition Development Organization (SDS) can assist with the IPD training. The continuous improvement office (TQ) can recommend team building tools and a team building approach. (The following types of training serve as a guide each organization can tailor to its unique situation).
All members of the organization should receive awareness training to familiarize them with the IPD management philosophy. This training should have three parts: program specific, IPD philosophy, and team building. The program specific training should assure that everyone has a common vision and understanding of the customer's requirements and the organization's purpose and products. Next is an overview session on IPD philosophy and an introduction to the tools and techniques used to implement this management philosophy. Finally, team building exercises should be conducted to bring the organization together as a whole and to facilitate the cultural change. The organization's customers and suppliers should be included in these presentations whenever possible.
As IPTs are formed, training should occur that builds upon the awareness training. First, it should provide detailed guidance on the implementation of the IPD management philosophy as it pertains to a specific team. This training should also focus on understanding the roles and interrelationships between the various disciplines and between teams, on the participation of core and adjunct members, and on bringing the group together as a team. The training should identify the team's customers, both internal and external, and the products delivered to those customers. The second part should focus on teambuilding. If possible, the team should include its customers and suppliers in this training to help build solid relationships. This training should be repeated for new team members downstream and as a refresher for any member of the team who wish to reinforce their understanding of the IPD management philosophy and the tools associated with it.
Task Specific Training. The IPD philosophy can be introduced into a program either at the beginning of a new contractual effort (ea. RFP, major ECP, program restructure) or into an existing program during its ongoing activity. Before entering into this effort, it is wise to train the people who will be doing the implementation about their objectives, roles, and tasks.
New Contractual Effort. The team that will introduce IPD through a major contractual effort needs to understand two areas: ( I ) their program and (2) how IPD applies to the effort they are about to undertake.
Regarding their program, the team needs to understand the core requirements of the program, both in terms of customer requirements and key contractual program events. They also need to understand the major products and processes of their program and how that translates into an outline of the program in the work breakdown structure. This may be a refresher on the program information presented in the awareness training.
If writing an RFP, the team will need to learn how to communicate the program structure and requirements into a draft SOW, how to write instructions on how to propose an IMP, how to determine which CDRLs are needed, how to structure their CLINs, and how to involve industry early on in the process. When the proposals are received and the team is about to perform source selection, they will need to understand what to expect in the proposals and how to fairly evaluate what will likely be very different proposals.
Existing Programs. The basic awareness and team training should provide most of the training needed. However, if the contracts are not to be restructured, team members will need to learn where and how to find all the information they will need to manage their product. This may take the form of a matrix that lists the relevant SOW tasks, CLINs, and CDRLs, as well as cost, schedule and performance data.
Appendix 1 Sample Section L Instructions
1100 Space Vehicle
Example Statement of Work: The contractor shall develop, test and support a space vehicle system that meets the system specification, in accordance with the activities described in the IMP.
Integrated Master Plan (IMP): The space vehicle section of the IMP shall include, but not be limited to, the steps required to develop, test and support the space vehicle
Proposal Volume: The offeror shall provide a description of the space vehicle system.
6400 Quality Assurance Management
Example Statement of Work: The contractor shall implement a quality assurance program that focuses on variability reduction and is based on MilQ9858A.
Integrated Master Plan (IMP): In a narrative section, the offeror shall describe its approach to quality assurance management using MilQ9858A as a framework and identify how it will interact with the government.
Proposal Volume: No additional instructions.
Appendix 2 Quality Function Deployment
QFD is a process that integrates customer requirements into the design and development of the product. It is a structured, customer oriented process for determining, assessing and prioritizing system/acquisition's requirements. Successive applications of the QFD tool drives the design of the product to the level of detail required by the team to support the "voice of the customer". Design, production and support life cycle are all considered. Sometimes called the "house of quality" because of the appearance of the structure of the diagram used to facilitate the inputs and assessments, QFD systematically translates the customer requirements into target values that are disseminated to all project personnel. It emphasizes early participation of all disciplines and functional representatives in product or process development and facilitates crossfunctional communications.
QFD, as an approach to design, was introduced by Yoji Akao in 1966. In 1972 Akao's ideas were formulated and systematized at Mitsubishi's shipyard in Kobe, Japan for the "oneofakind" ship design. However, it has broad applicability to manufactured products, complicated processes and many areas of service industries. Today QFD is a major force in the quality efforts of U.S. industries, notably the automotive industry.
The approach of QFD can be summarized in six steps.
1. The customer states requirements in their own words.
2. Define the relationship between customer requirements and selected characteristics
3. Convert customer requirements into specifications, functional and allocated
4. From the specifications define design requirements
5. Define the method and activities for validation of customer requirements
6. Feedback to the customer and all participants
The basic methodology of QFD is to identify specific "whets" of the customer and translate those items into "hows". As the two lists are developed, the interaction between the two elements is determined and the resolution of conflicts begins. The team formed to develop the acquisition/process identifies the customers and attempts to quantify the basic nature of the customer "wants". The team then develops lists of "hows" which will meet the "whets" (requirements) of the customer. The QFD process will prioritize the "hows" and identify conflicts or tradeoff in the selection of the "hows". IPD uses the QFD to translate the user requirements into a system specification.
IPD use of QFD in Requirements and Product Development
While QFD is not a tool or philosophy unique to IPD approach, it is a potentially very powerful tool that is very much in consonance with the philosophies and practices of both IPD and TQL. Following the logic stated above, the design of the system is detailed through the successive development of "houses of quality" using the defined 'hows" as the "whets" of the next house.
In the IMP system, the team develops, via brainstorming or similar tools, the basic "whets" of the system or program. The first set of "hows" developed represent the basic program outline and are translated into both the user requirements document and the outline of the acquisition program. Successive houses funkier define the design of the program and allow the team to identify conflicting interactions between the various program requirements. Successive houses identify program structure; design and define methods for meeting the requirements of the user stated in his operational requirements documents. In fact, the optimum use of QFD would be with the user to assist in the development of the basic requirements. User/customer participation is crucial. participation by knowledgeable people, with significant decision making authority, is necessary.
This pertains to all of the participants customers/users, program office, and functional experts (regardless of affiliation). The process is quite labor intensive, and usually requires dedicated participation by a fairly large number of people for several days or more. The team that goes through a QFD process will, as individuals, have gained a great deal of shared knowledge about the program, its requirements and the other team participants (i.e., QFD can be a team building activity).
Appendix 3 IPD Implementation Plan
INTEGRATED PRODUCT DEVELOPMENT
Greater visibility into risk areas
Enhance trust and teamwork through govt/industry teaming
Greater functional influence
Smoother transition to production, operations and support
Lower cost, higher quality
At what level will products be managed
At what level will teams be formed
Role of functional chiefs
How will industry and other govt agencies be incorporated into teams
Will the contract he restructured
3.0 PROGRAM OUTLINE
3.1 Key Products
3.2 Key Processes
4.0 TOOL KIT
4.1 Integrated Master Plan
4.2 Integrated Master Schedule (Near and Long Term)
4.5 Risk Management
4.6 Other Tools (CLINs, Clauses, CDRLs, Award Fee, etc)
5.0 TEAM MANAGEMENT
5.1 Empowerment(Authority, Responsibility, Accountability)
5.2 Role of the Team Leader
5.3 Role of the Team Members
5.4 Team Procedures (Meetings, govt/industry interaction, etc)
5.5 Integration between Teams