SOFTWARE ACQUISITION GOLD PRACTICE

Integrated Product and Process Development (IPPD)

FOCUS AREA:   PROCESSES – System Engineering

Definition and Summary:  A systematic approach to product development (acquisition) which increases customer satisfaction through a timely collaboration of necessary disciplines throughout the life cycle.

 

The figure below graphically illustrates a generic IPPD process.  Particular note should be made of the Team sub-process, as the creation and implementation of an Integrated Product Team (IPT) is, perhaps, the most critical ingredient for the success of the entire IPPD process.

Successful definition and implementation of IPPD can result in:

 

·         Reduced Cycle Time to Deliver a Product

·         Reduced System and Product Costs

·         Reduced Risk

·         Improved Quality

DESCRIPTION OF THE PRACTICE:

 

SUMMARY DESCRIPTION

The figure presented below graphically illustrates a generic IPPD process.  Particular note should be made of the Team sub-process, as the creation and implementation of an Integrated Product Team (IPT) is, perhaps, the most critical ingredient for the success of the entire IPPD process.

 

 

The use of state-of-the-art methods and tools for planning, information, management, design, cost trade-off analysis, and modeling and simulation significantly improves IPPD effectiveness.  These IPPD tools include:

 

• Information Technology and Decision Support
• Trade-Off Studies and Prioritization
• Cost-Performance Trade-Offs
• Prototyping
• Modeling and Simulation
• Measurement and Metrics

 

DETAILED DESCRIPTION

Figure 1 graphically illustrates a generic IPPD process.  Particular note should be made of the Team sub-process, as the creation and implementation of an Integrated Product Team (IPT) is, perhaps, the most critical ingredient for the success of the entire IPPD process.

 

Figure 1:  The IPPD Iterative Process (with IPT Implementation)

 

The use of state-of-the-art methods and tools for planning, information, management, design, cost trade-off analysis, and modeling and simulation significantly improves IPPD effectiveness.  These IPPD tools include:

 

• Information Technology and Decision Supportw

 

Document management, process documentation and configuration control (i.e., Configuration Management) are critical activities in the successful implementation of IPPD.  A common information system is needed to provide opportunities for team members to access product or process information at any time, from any location.  Access should be provided to design information; automated tools; specifications and standards; schedule and cost data; documentation; process methodologies; program tracking; program and process metrics; etc..

 

• Trade-Off Studies and Prioritization

 

To fully leverage the IPPD process, design trade-offs that optimize system requirements vs. cost should be performed during the earliest phases of the software life cycle.  Product/process performance parameters can be traded-off against design, development, testing, operations and support, training requirements, and overall life cycle costs.  System attributes such as mission capability, operational safety, system readiness, survivability, reliability, testability,maintainability, supportability, interoperability and affordability also need to be considered.

 

Quality Function Deployment (QFD) is one technique for evaluating trade-off scenarios.  It is predicated on gaining an understanding of what the end user really needs and expects.  The QFD methodology allows for tracking/tracing trade-offs through various levels of the project hierarchy, from requirements analysis, through the software development process, to operational and maintenance support.

 

• Cost-Performance Trade-Offs

 

Activity-Based Costing (ABC), which focuses on those activities that bring a product to fruition, is considered a valuabletool for IPPD cost analysis.  Costs are traced from activities to products, based on the consumption of each product of those activities.  The cost of the product is measured as the sum of all activities performed, including overheads, capital costs, etc.

 

• Prototyping

 

Prototypes provide a representation of a product/system under development.  They facilitate communications between software designers and product/system users by allowing users to better describe or gauge actual needs.  For IPPD, there is a need to rapidly develop prototypes as early as possible during software design and development.  Customer manipulation helps clarify requirements and correct misconceptions about what the product should or should not do,thereby reducing the time to complete a fully functional design, and reducing the risk of delivering an unacceptable product.

 

Software prototyping must be controlled to eliminate unnecessary prototyping cycles that cause cost and schedule overruns.  It is also necessary to guard against scope creep, in that users may want to add features/enhancements that go beyond the scope of contracted requirements.

 

• Modeling and Simulation

 

Modeling and simulation (M&S) techniques are a cost-effective approach to reduce the time, resources and risks, and to improve the quality, of acquired systems.  Validated M&S can support all phases of IPPD, and should be appropriately applied throughout the software life cycle for requirements definition; program management; design and engineering; test and evaluation; and field operation and maintenance.

 

• Measurement and Metrics

 

The IPPD approach stresses defining processes and establishing strategic checkpoints to determine process health using accurate measurement and open communications.  Defining and using process-focused metrics provides for early feedback and continuous monitoring and management of IPT activities.

 
Metrics should be structured to identify the overall effects of IPPD implementation.  Measures of success can include schedule, communications, responsiveness and timeliness.  Additional important measures include productivity, customer satisfaction and cycle time.

 

CHARACTERISTICS OF IMPLEMENTATION:

 

SUMMARY CHARACTERISTICS

 

Enabling Practices:           Link to IPPD Interrelationships Diagram

Enabled Practices:            Link to IPPD Interrelationships Diagram

Impact Areas:                      Primary: Little consensus

Life Cycle Phase:               Throughout the program life-cycle

Scope/Authority:                Organization-level

Applicability:                       Acquisition; development

Use Indicators:                   High task complexity; high number of individual disciplines involved Software-intensive acquisitions

Use Inhibitors:                    None indicated

Appropriate Programs:    Software-intensive acquisitions

Inappropriate Programs: Small, single product

Barriers:                               Political/cultural issues (turf, responsibility, accountability); infrastructure that does not support teaming

Facilitators:                          Strong leadership, training, commitment on the part of upper and middle management; infrastructure that supports teaming

 

 

ANTICIPATED BENEFITS OF IMPLEMENTATION:

 

Successful definition and implementation of IPPD can result in:

 

• Reduced Cycle Time to Deliver a Product

 

What were formerly sequential decisions can now be made concurrently from an integrated perspective, with all stakeholders accounted for.  All decisions should be based on a system software life cycle perspective that minimizes the number and magnitude of changes during development and deployment of the software.  A subsequent reduction in extended and expensive rework cycles has a positive impact on schedules and overall software life cycle costs.

 

• Reduced System and Product Costs

 

Proper emphasis on IPPD at the beginning of the software development process helps to optimize the product and process funding profile.  Pre-IPPD funding profiles based on historical data may no longer be relevant.  Early software project phases may require additional investment, but unit costs, and overall life cycle costs, may be reduced due to fewer design or engineering changes, better capability to meet schedule objectives, and extensive use of trade-off analyses to reach cost-effective solutions.

 

• Reduced Risk

 

Team planning at the earliest stages of software development promotes better understanding of available technologies and processes.  This, in turn, yields a better understanding of risk and its impacts on cost, schedule and performance.  Effective risk assessment can result in methods or processes for reducing or mitigating potential risks and establishing more realistic cost, performance and schedule objectives.

 

·         Improved Quality

 

Teamwork that is coupled with team desire and management support for continuous software product and process improvement results in improved product and process quality for the end-user.

 

DETAILED CHARACTERISTICS

 

The key characteristics of Integrated Product and Process Development, as derived from the “DoD Guide to Integrated Product and Process Development”, Version 1.0, dated 5 February 1996, are described in the table below. 

 

Key Characteristics of Integrated Product and Process Development (IPPD)

-     derived from DoD Guide to Integrated Product and Process Development, Version 1.0, 5 Feb 1996 [IPPD GUIDE, 1996]

Characteristic	Comments
Customer Focus	·      Primary IPPD objective is to identify and satisfy the customer’s needs better, faster and cheaper.  Customer needs should determine the nature of the product and its associated processes.  Quality Function Deployment (QFD) is a key tool for focusing on solutions to customer needs/wants.
Concurrent Development of Products and Processes	·      Processes that are used to manage, develop, verify, test, deploy, operate, support, train people, and eventually dispose of the product should be planned early in product design and development ·      Product and process design and performance must remain balanced to optimize software life cycle cost, affordability and supportability objectives ·      Early integration of design elements results in lower costs through fewer changes/less rework later in the development process
Early, Continuous Life Cycle Planning	·      Early product life cycle planning provides a foundation for the various phases of its development, and should include customers, organizational functions and suppliers ·      Key program activities and milestones should be defined to track, understand and effectively manage progress towards cost targets; allocation of resources; and the impact of problems, resource constraints and changes in requirements
Flexibility for Optimization and Use of Contractor Approaches	·      Requests for Proposals (RFPs) and contracts should maximize feasibility of implementing IPPD practices and use of contractor processes and commercial specifications, standards and practices ·      RFPs and contracts should also accommodate requirements changes.  Contractors should be encouraged, through incentives, to challenge requirements and offer cost-effective alternative solutions
Robust Design and Improved Process Capability	·      Promote the use of advanced software design and development techniques that will result in software that (1) achieves quality through design and is robust for all domains and environments, (2) focuses on software process capability, and (3) promotes continuous process improvement ·    Six Sigma techniques are important for process variability and defect reduction
Event-Driven Scheduling	·    Establish a scheduling framework that relates program events/milestones to the attainment of stated goals and accomplishments.  Attainment of goals/milestones signals the completion and acceptability of each event/milestone. ·    Program risk is reduced by ensuring that product/process maturity is incrementally demonstrated prior to performing the next activity
Multidisciplinary Teamwork	·    Multidisciplinary teamwork is a critical factor in the integrated and concurrent development of a product and its processes in order to achieve product and program objectives ·    Team decisions, based on risk assessments, should include the combined input from technical, cost, support, and management functions and organizations, as well as customers and suppliers ·    Team members must fully understand their roles, support the roles of all other team members, and understand the constraints under which the team operates
Empowerment	·    Decision-making should be made at the lowest organizational level, commensurate with assessed risk ·    Resources should be allocated to the appropriate organizational levels consistent with risk assessment authority, responsibility and personnel skill levels ·    The team should have the authority, responsibility (including accountability) and resources it needs to manage its product/program to successful completion
Seamless Management Tools	·    Establish a framework that relates products/processes at all levels to demonstrate dependencies and interrelationships ·    An established management system should relate requirements, planning, resource allocation, and program execution and tracking over the software life cycle ·    Provide capabilities to share technical, programmatic and business information throughout the life cycle by using shared information systems and software tools (including models) to access, exchange, validate and view data and 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/business performance measurement plans, using relevant metrics, should be developed and benchmarked against “best-in-class” government and industry programs and organizations to continually verify effectiveness and anticipated vs. actual achievement of all technical and business objectives.

 

 

RELATIONSHIPS TO OTHER PRACTICES:

 

The Figure below represents a high-level process architecture for the subject practice, depicting relationships among this practice and the nature of the influences on the practice (describing how other practices might relate to this practice).  These relationship statements are based on definitions of specific “best practices” found in the literature and the notion that the successful implementation of practices may “influence” (or are influenced by) the ability to successfully implement other practices.  A brief description of these influences is included in the table below.

Process Architecture for the "Integrated Product and Process Development (IPPD)" Gold Practice

 

Summary of Relationship Factors for the Integrated Product and Process Development Gold Practice

INPUTS TO PRACTICE
Define how the business environment drives IPPD scope	The use of common processes, including management and manufacturing systems, contributes to both cost- and schedule-effective concurrent development of products.  Allowed flexibility in the optimization and use of contractor approaches (acquisition tailoring) increases the feasibility of IPPD approaches resulting in “best value” awards.  Early product life cycle planning provides a foundation for IPPD that involves all stakeholders through all phases of development and deployment.
Identify how technical constraints impact the IPPD role	Technical specifications and requirements help define the roles of the IPPD stakeholders, and the constraints under which they operate.  Encouraging contractors, through incentives, to challenge requirements and offer “best value” alternatives should result from a requirements trade-off/negotiation process that involves the IPPD team.  Interoperability concerns and plans for technology insertion are best addressed by an IPPD process that embraces robust design and continuously improved process capability.
Identify a technical approach that leverages IPPD goals	The IPPD process leverages the use of advanced software design and development techniques to develop a cost-effective, robust design.  Understanding past performance, reaching agreement on interface requirements, and the early development of product and process architectures, allow the IPPD team to establish relevant technical goals.  Cost-effective solutions to meet those goals may include the integration of COTS/NDI and/or reused software into the overall product.
Provide a focused management approach	For IPPD to be effective, management must establish clear goals and decision points that relate requirements, planning, resource allocation and program execution/tracking over the software life cycle.  Proactive identification and management of software configuration and technical/business risk are critical focus areas during the IPPD process.  Metrics-based scheduling and management that relates events/milestones to attainment of program goals reduces program risk.
OUTPUTS FROM PRACTICE*
Provide focused and integrated management of resources	An effective IPPD process holds people and organizations accountable for establishing and meeting program goals and requirements.  Decision-making is delegated to the lowest organizational level, commensurate with risk.  The IPPD team should have the authority, responsibility, accountability and resources required to manage the program to successful completion.
Identify improvements in the acquisition process	Empowerment of stakeholders and proactive identification and management of risk directly relate to an improved acquisition process through a multidisciplinary teamwork approach.  Acquisition team decisions, based on risk assessments, should include the combined input from all stakeholders.  Team members must understand their roles, support the roles of other team members, and understand the necessary program constraints.
Support accurate program/project tracking	Accurate program tracking is achieved by actively soliciting timely and relevant cost, schedule and performance data and information from the IPPD team members.  Use of appropriate metrics and communication of program status to all stakeholders, coupled with personnel and organizational accountability for results, ensures that program progress is maximized and program risk is minimized.

RESOURCES:        

 

§        Websites

o        Department of the Navy – IPPD

http://www.abm.rda.hq.navy.mil/navyaos/acquisition_topics/program_management/ippd

o        James Gregory Associates, Inc.

http://www.jgai.com/

 

§        Tools and Methods

·         Technology Transfer Kit for Product Line Management Best Acquisition Processes and Practices, Reifer Consultants, Inc.,

http://www.reifer.com/

 

§        Experts/Contact Points

·         Paul Croll, Computer Sciences Corporation (pcroll@csc.com)

·         Patricia Larsen, Fraunhofer Center for Experimental Software Engineering

(plarsen@fc-md.umd.edu)

 

 

·         Sarah Sheard, Software Productivity Consortium (sheard@software.org)

·         Jim Armstrong, Software Productivity Consortium (armstrong@software.org)

·         Gerry Imai, Software Technology Support Center (gerry.imai@hill.af.mil)

·         Bob Rassa, National Defense Industrial Association (rcrassa@raytheon.com)

·         Roger Bate, Software Engineering Institute (rrbate@gte.com)

 

§        Training Opportunities:

·         Introduction to CMMI Version 1.1, Staged Representation http://www.sei.cmu.edu/products/courses/cmmi-staged.html

 

·         Introduction to CMMI Version 1.1, Continuous Representation http://www.sei.cmu.edu/products/courses/cmmi-continuous.html

 

·         Integrated Product and Process Development (IPPD) Multimedia Training System http://www.abm.rda.hq.navy.mil/navyaos/content/view/full/218

 

§        Bibliography:

[CMU/SEI-2002-TR-011]	“Capability Maturity Model Integration (CMMI), Version 1.1 – Continuous Representation”, Software Engineering Institute, CMU/SEI-2002-TR-011, March 2002 http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr001.pdf
[CMU/SEI-2002-TR-012]	“Capability Maturity Model Integration (CMMI), Version 1.1 – Staged Representation”, Software Engineering Institute, CMU/SEI-2002-TR-012, March 2002 http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr002.pdf
[DODD 5000.2]	DoD 5000.2-R, “Mandatory Procedures for Major Defense Acquisition Programs (MDAPS) and Major Automated Information System (MAIS) Acquisition Programs”, 5 April 2002 http://www.acq.osd.mil/dpap/policy/directives.htm
[DODI 5000.2]	DoD Instruction 5000.2, “Operation of the Defense Acquisition System”, 5 April 2002 http://www.acq.osd.mil/dpap/policy/directives.htm
[INTERIM, 2002]	“Interim Defense Acquisition Guidebook”, 30 October 2002 (Replaces DoD 5000.2-R, canceled 30 October 2002) http://www.acq.osd.mil/dpap/policy/directives.htm
[IPPD GUIDE, 1996]	“DoD Guide to Integrated Product and Process Development”, Version 1.0, 5 February 1996 http://www.arnet.gov/Library/OFPP/BestPractices/pbsc/library/dod-guide-to-integrated.pdf
[IPPD HANDBOOK, 1998]	“DoD Integrated Product and Process Development Handbook, August 1998 http://www.abm.rda.hq.navy.mil/navyaos/content/download/1000/4448/file/ippdhdbk.pdf
[BATE, 2001]	Bate, R., Gibson, D., Richter, K., “CMMI and Integrated Product and Process Development (IPPD) CMMI”, SEPG 2001 Tutorial, 12 March 2001, http://www.sei.cmu.edu/cmmi/presentations/sepg01.presentations/ippd/
[BOEHM, 2000]	Boehm, B., “Integrated Product and Process Development”, Univ. of Southern California, Lecture CS577b, 27 March 2000 http://sunset.usc.edu/classes/cs577b_2000/EC/17/EC-17.pdf
[GIBSON, 2002]	Gibson, D.L., “Bibliography on Integrated Product and Process Development – CMMI SE/SW/IPPD”, Software Engineering Institute, January 2002 http://www.sei.cmu.edu/cmmi/publications/ippd-biblio.pdf
[GREGORY, 2001]	Gregory Associates, Inc., J.A., “IPPD Process Model”, Version 6.01, James Gregory Associates, Inc, January 2001 http://www.jgai.com/stprocess50/pm60draft/process_model_601.pdf (Download) http://www.jgai.com/stprocess50/pm60draft/index.html (Interactive On-Line)
[GREGORY, 2002]	Gregory Associates, Inc., J.A., “IPPD for S&T – Quick Reference”, Version 3.0, James Gregory Associates, Inc, 6 March 2002 http://www.jgai.com/servlet/DownloadServlet?DownloadID=1&howTransfer=get&CategoryTypeID=13
[SPRINGSTEEN, 1999]	Springsteen, B., Bailey, E.K., Nash, S.H., Woolsey, J.P., “Integrated Product and Process Development Case Study: Development of the F/A-18E/F”, Institute for Defense Analyses, IDA Document D-2228, June 1999 http://www.acq.osd.mil/io/se/ippd/IPPD_Case32-final.doc
[TURNER, 2002]	Turner, R.G., “Implementation of Best Practices in U.S. Department of Defense Software-Intensive System Acquisitions”, Ph.D. Dissertation, George Washington University, 31 January 2002
[WINNER, 2000]	Winner, R.I., “Integrated Product/Process Development in the New Attack Submarine Program”. OUSD(A&T), February, 2000 http://www.acq.osd.mil/io/se/ippd/nssn_ippd.doc

 

 

APPENDICES

DEFINITIONS:

 

A management process that integrates all activities from product concept through production and support, using a multifunctional team, to simultaneously optimize the product and its manufacturing and sustainment processes to meet cost, schedule, and performance objectives.

-    DoDI 5000.2, 5 April 2002, Para E2.1.6 [DODI 5000.2]

 

A systematic approach that achieves a timely collaboration of relevant stakeholders throughout the life of the product to better satisfy customer needs, expectations, and requirements.

-    Capability Maturity Model Integration (CMMI), Version 1.1, Pg. 4 [CMU/SEI-2002-TR-011]

 

A systematic approach that increases customer satisfaction through a timely collaboration of necessary disciplines throughout the software life cycle.

-    Turner Dissertation, 31 Jan 2002 [TURNER, 2002]

SOURCES (Origins of the Practice):

 

UNDEFINED

RECOMMENDING SOURCES:

 

§         DoD 5000.2-R, “Mandatory Procedures for Major Defense Acquisition Programs (MDAPS) and Major Automated Information System (MAIS) Acquisition Programs”, 5 April 2002 [CANCELLED 30 October 2002]

§         Interim Defense Acquisition Guidebook, 30 October 2002 [INTERIM 2002]

 

C2.6.6.3  Applying Best Practices.  In tailoring an acquisition strategy, the PM shall address management constraints imposed on the contractor(s).  PMs shall avoid imposing Government-unique restrictions that significantly increase industry compliance costs or unnecessarily deter qualified contractors, including non-traditional defense firms, from proposing.  Examples of practices that support the implementation of these policies include Integrated Product and Process Development (IPPD)…

 

C2.8.2  Demonstration of assured supportability and life cycle affordability shall be entrance criteria for the Production and Deployment Phase.  The specific requirements associated with integrating the support strategy into the system engineering process shall be accomplished through IPPD.

 

C5.1  The PM shall employ IPPD to the maximum extent practicable.  IPPD considers and integrates program activities throughout the entire program life cycle, including systems management, development, manufacturing, testing, deployment, operations, support, training, and eventual disposal.  Using IPPD, multi-disciplined Integrated Product Teams (IPTs) shall simultaneously optimize the product, product manufacturing, and supportability to meet system cost and performance objectives.

§         Capability Maturity Model Integration (CMMI), Version 1.1, Software Engineering Institute, CMU/SEI-2002-TR-011, TR-012, March 2002 [CMU/SEI-2002-TR-011]

 

PAGE 4  The processes to support an IPPD approach are integrated with the other processes in the organization.  The IPPD process areas, specific goals, and specific practices alone cannot achieve IPPD…(If) an organization or project wishes to use IPPD, it chooses a model with one or more disciplines in addition to selecting IPPD.

 

When you select IPPD for your model, the model will contain the Process Management, Project Management, Support, and Engineering process areas that apply to both IPPD and the other discipline(s) you have selected for your model.  Discipline amplifications specific to IPPD are also provided to help…interpret specific practices for IPPD.

 

 

GLOSSARY

 

Activity-Based Costing (ABC)	A technique that provides a means of accurately assigning support or "soft" costs to product manufacture that includes the administrative resources that a job actually consumes, not just labor, machinery, and materials.
Airlie Council	A group of experts convened by the Navy’s Software Program Manager’s Network (SPMN) in 1995 that established/identified nine best practices.  These practices have been augmented with other practices since 1995, and in current literature are referenced as the original Airlie best practices.
Best Practice	A documented practice aimed at lowering an identified risk in a system acquisition and is required or recommended by a bona fide DoD, industry, or academic source. -    [Turner, 2002]   Methodologies and tools that consistently yield productivity and quality results when implemented in a minimum of 10 organizations and 50 software projects, and is asserted by those who use it to have been beneficial in all or most of the projects. -    Jones, Software Assessments, Benchmarks, and Best Practices, 2000
COTS (Commercial Off-the-Shelf)	A software product that is developed by a third party (who controls its ongoing support and evolution) and is bought, licensed, or acquired for the purposes of integration into a larger system.
Gold Practice	A term coined by the DACS to identify a practice that provides intrinsic value to an organization or program that acquires or develops software.  The DACS term focuses on the realization that a practice may be “worth its weight in gold” in cost savings and process improvements for specific programs and organizations, irrespective of whether other organizations have successfully or unsuccessfully implemented it, by emphasizing that there are other practices/processes that influence, or are influenced by, the success or failure of the Gold Practice.
IPPD	Integrated Product and Process Development
IPT	Integrated Product Team
NDI (Nondevelopmental Item)	Any previously developed item of supply used exclusively for government purposes by a Federal Agency, a State or local government, or a foreign government with which the United States has a mutual defense cooperation agreement.  An NDI may require only minor modifications or modifications of the type customarily available in the commercial marketplace in order to meet the requirements of the processing department or agency.
PM	Program Manager
Quality Function Deployment (QFD)	An organized, disciplined process for determining the product or service requirements necessary to achieve customer-perceived expressed or unexpressed quality.
Six-Sigma Techniques	An approach to reduce process output variation so that ±six standard deviations lie between the mean and the nearest specification limit.  This will allow no more than 3.4 defect Parts Per Million (PPM) opportunities, also known as Defects Per Million Opportunities (DPMO), to be produced.

 

CASE STUDIES FROM THE LITERATURE:

 

Integrated Product/Process Development in the New Attack Submarine Program

 

The New Attack Submarine (NSSN) program used Integrated Product and Process Development (IPPD) to reduce acquisition and life cycle costs and develop a safe, effective weapons system.  IPPD was used for all aspects of the program including the platform, nuclear propulsion, and Command, Control, Communications, and Intelligence (C³I) systems.  The program has used important IPPD practices and learned significant lessons in the areas of team organization and behavior, government participation, contracting, planning, scheduling, tracking progress, tools, design processes, specifications, cost growth avoidance, training, and funding profiles; these are described in this report.  Measured by number of drawings issued at comparable points in time, the NSSN program is 2.5 years ahead of the pace of the predecessor program, SEAWOLF, relative to construction start, has 64 percent fewer drawings requiring government approvals, and is projected to require substantially fewer design changes during construction.

- [WINNER, 2000]

 

Integrated Product and Process Development Case Study: Development of the F/A-18E/F

 

This case study documents how McDonnell Douglas Corporation (MDC) used an Integrated Product and Process Development (IPPD) management philosophy to design and produce the F/A-18E/F aircraft.  The paper identifies key IPPD principles and provides examples of how they were implemented by MDC.  It examines the management practices, organization structure, and integrated tools used to foster the program’s success.  For students of the acquisition process in the Department of Defense (DoD), a list of discussion items and sample answers is provided.

- [SPRINGSTEEN, 1999]

 

Additional Case Studies/Success Stories  can be viewed at the Department of the Navy – IPPD Web Site:  http://www.abm.rda.hq.navy.mil/navyaos/acquisition_topics/program_management/ippd