B08 - Attachment 5 - IMP-IMS-Guide-2023.pdf

Integrated Master Plan and Integrated Master Schedule Preparation and Use Guide

May 2023

Office of the Executive Director for Systems Engineering and Architecture

Office of the Under Secretary of Defense for Research and Engineering

Washington, D.C.

DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited.

Integrated Master Plan (IMP) and Integration Master Schedule (IMS) Preparation and Use Guide

Office of the Under Secretary of Defense for Research and Engineering 3030 Defense Pentagon Washington, DC 20301 osd.r-e.comm@mail.mil | Attn: SE&A IMP-IMS https://www.cto.mil/

Distribution Statement A. Approved for public release. Distribution is unlimited.

DOPSR Case # 23-S-2010.

mailto:osd.r-e.comm@mail.mil

IMP/IMS Preparation and Use Guide

III

Approved by

Thomas W. Simms

Acting Principal Deputy Director for Systems Engineering and Architecture

Office of the Under Secretary of Defense for Research and Engineering

IMP/IMS Preparation and Use Guide Change Record

Date Change Rationale

Contents

IV

CONTENTS

1 Introduction

1.1 Purpose

1.2 Value of the IMP and IMS

2 Policy and Guidance

2.1 Engineering of Defense Systems

2.2 DoD Adaptive Acquisition Framework

2.3 IMP/IMS Guidance

2.4 Digital Engineering Guidance

3 Relationship of IMP and IMS to WBS

3.1 Relationship to Work Breakdown Structure

3.2 Relationship to Organizational Breakdown Structure

4 Integrated Master Plan

4.1 IMP Overview

4.2 Developing and Formatting the IMP

4.3 Relationship Between IMP and IMS

5 Integrated Master Schedule

5.1 IMS Overview

5.2 IMS Requirements

5.3 Developing the IMS

6 Implementing IMP and IMS

6.1 Early Project Planning

6.2 Government Project Planning

6.3 Government Pre-Award Schedule

6.4 Contract Awarded

6.5 Contractor IMS

6.6 Examples of IMP and IMS Implementation

7 Schedule Risk Analysis and Schedule Health

7.1 Schedule Risk Analysis

7.2 Schedule Health

7.3 Risk Overview

V

8 Preparing the RFP

8.1 Overview

8.2 Section L. Instructions, Conditions, and Notices to Offeror or Respondents

8.3 Section M. Evaluation Factors for Awards

8.4 Other Applicable Sections and Considerations

9 Evaluating the IMP and IMS for Source Selection

9.1 Multifunctional Plan and Schedule

9.2 Pre-IMP Evaluation

9.3 Steps in Evaluating the IMP and IMS

Appendix A. Action Verbs

Appendix B. Adaptive Acquisition Framework

Appendix C. IMP and IMS Development Checklist

Glossary

Acronyms

References

Figures

Figure 2-1. MCA Pathway

Figure 2-2. MTA Pathway

Figure 2-3. UCA Pathway

Figure 2-4. Software Acquisition Pathway

Figure 2-5. DBS Pathway

Figure 2-6. DAoS Pathway

Figure 3-1. WBS Example

Figure 3-2. Relationship Among OBS, WBS, IMP, and IMS

Figure 4-1. Action Verbs

Figure 4-2. Examples of IMP Numbering

Figure 4-3. Example Process Flow Diagram for a Technology Insertion Process

Figure 4-4. Relationship between IMP and IMS

Figure 5-1. Types of IMSs

VI

Figure 5-2. WBS, IMP, and IMS Relationship

Figure 5-3. IMS Development Process

Figure 5-4. IMS Numbering System

Figure 5-5. Initial Column Settings

Figure 5-6. Example of Long-Duration Tasks

Figure 5-7. Example of Lead Time

Figure 5-8. Example of Lag Time

Figure 5-9. Example of IMS Constraints

Figure 5-10. IMS “Combination” View with Network Relationship

Figure 5-11. IMS Sorted by IPT

Figure 6-1. Example Government MCA Project Roadmap

Figure 6-2. Generic Pre-Award IMS

Figure 6-3. IMP Summary of Effort Supporting an Event

Figure 6-4. IMS Implementation

Figure 7-1. Sample SRA Results

Figure 9-1. Example of a Constrained IMS

Tables

Table 4-1. IMP Table Example

Table 8-1. Non-Price Evaluation Factors/Subfactors

Table 8-2. Example of Additional Data Request for an IMS file://usr.osd.mil/Home/OSD/OUSDATL/careydd/2023_DDC_Files/2023-05-02-!-IMP-IMS-Guide-PublicRelease-withDOPSR/20230504-IMP-IMS-Guide-Cleared.docx#_Toc134094924

1. Introduction

1 INTRODUCTION

The Department of Defense (DoD), other agencies and DoD contractors use Integrated Master Plans (IMPs) and Integrated Master Schedules (IMSs) to plan and manage projects from inception to completion. Together the IMP and IMS integrate the activities and schedule components necessary to complete a project successfully.

The IMP typically describes three levels of activities: Events, Accomplishments, and Criteria.

The IMS adds a fourth level of detail: Tasks, with detailed timelines and deadlines. Each level consists of activities to fulfill the next level in the hierarchy. Programs complete Tasks to satisfy Criteria, which roll up to satisfy Accomplishments, which roll up to complete an Event. The IMP and IMS are integrated, so changes to the plan are reflected in the schedule.

1.1 Purpose

This guide will assist Program Managers (PMs), project officers, and contractors in preparing and implementing IMPs and IMSs for DoD programs. This guide updates earlier DoD IMP/IMS guidance and emphasizes the Government preparing an IMP and an initial execution (IE) IMS (a provisional IMS) early to influence the offerors’ proposals, and Government/contractor collaboration on developing a well-established plan for the contract. This guide intends to:

• Provide a consistent philosophy and approach to the IMP and IMS and their development.

• Foster improved IMP and IMS products that reflect a systematic approach.

• Allow tailoring to each project’s specific needs and permit offerors to build their IMPs and IMSs consistent with their own management and scheduling structure and formats.

• Improve the learning curve on the use of IMP and IMS for Government Program Management Offices (PMOs) and industry.

• Facilitate the development of well-defined and complete plans and schedules for use in day-to-day project execution, which can mitigate risk and increase the probability of project success.

The principles outlined in this guide apply to incremental and Family-of-Systems (FoS), or System-of-Systems (SoS) programs. This guide:

• Defines key terminology.

• Discusses the concept and purpose of the IMP and IMS.

• Provides guidance on developing and implementing IMP and IMS products.

• Discusses the importance of tailoring requirements in Request for Proposals (RFPs).

• Describes how to evaluate an offeror’s IMP and IMS.

• Defines key terminology and provides further supporting references.

Whereas DoD policy is mandatory, this guide is not mandatory but provides recommended methods and best practices from experienced practitioners, program leaders, and defense engineers. The guide references mandatory policy and related guidance to provide context.

The Office of the Under Secretary of Defense (OUSD) for Research and Engineering (R&E) prepared this guide in collaboration with OUSD for Acquisition and Sustainment (A&S) and subject matter experts from across DoD. OUSD(R&E) will develop and coordinate updates as required to incorporate policy changes and user feedback.

1.2 Value of the IMP and IMS

The IMP and IMS provide a framework for managing the project and tracking progress against goals and timelines. They help ensure team members are working toward the same objectives and that issues or delays are identified and addressed in a timely manner. IMPs and IMSs can help organizations manage risk, increase efficiency, and improve communication and collaboration among project stakeholders.

The IMP and IMS are applicable to competitive and sole source procurements with industry as well as Government in-house efforts. They provide ongoing insight into project status by Government and contractor personnel. They help the project develop and support “what-if” exercises and to identify and assess candidate problem work-arounds. Using the IMP and IMS can focus and strengthen the Government-contractor team.

A well-prepared IMP and IMS provide value-added management applications. In preparing for source selection and its activities, the IMP and initial IMS:

• Provide offerors with flexibility in performing detailed project execution planning, organization, and scheduling within any existing RFP constraints.

• Serve as the basis for the offeror’s detailed IMS showing how the contractor intends to meet the RFP requirements by accurately representing the offeror’s proposed project approach, which should be executable within the cost, schedule, and risk constraints.

• Provide the Government proposal evaluation team with the information needed to assess each offeror’s approach against the RFP’s requirements including proposal risk, performance confidence, and price and cost evaluation factors.

After contract award, the Government and contractor’s plans and schedule:

• Serve as the basis for ensuring mutual understanding of Government expectations and agreement on the project content, project plan, schedule, and risk.

• Provide the detailed integrated execution plan and supporting schedule, identifying what needs to be done and when it should be done.

During the project execution, the IMP and IMS provide a framework for insight into project performance for the PMO and the contractor’s management team. When properly integrated with earned value management (EVM) through a sound technical management approach as documented in the project’s Systems Engineering Plan (SEP), the IMP and IMS enable the PMO to:

• Identify and assess actual progress versus the planned progress.

• Monitor the project critical path, the series of Tasks that need to be completed on time to ensure the project remains on schedule.

• Assess project maturity.

• Assess the status of risk management activities based on the inclusion of the project risk mitigation activities in the IMP and IMS.

• Assess the progress on selected Key Performance Parameters (KPPs) and Technical Performance Measures (TPMs).

• Provide an objective, quantitative basis for the contractor’s performance assessment rating and award fee.

• Provide better insight into potential follow-on efforts that were not part of the original contract award. For example, the contractor should be able to define the activities, new interfaces, and other information more clearly for a potential project increment or contract option.

• Help develop and support “what-if” exercises, identify and assess candidate problem work-arounds, and help develop the work-arounds to problem areas.

2. Policy and Guidance

2 POLICY AND GUIDANCE

2.1 Engineering of Defense Systems

DoD Instruction (DoDI) 5000.88, Engineering of Defense Systems, directs Major Defense Acquisition Programs (MDAPs), Acquisition Category (ACAT) II, and ACAT III programs to develop a SEP, which includes a description of the IMP and IMS. The description should include definitions, updated schedules, audits, baseline control, and the integration between project-level and contractor detailed schedules. The project-level IMP is typically an attachment to the SEP, and the IMS should be made available in its native format to support independent technical risk assessments.

PMOs that serve as the system integrator should develop and maintain a system-level IMP and execution IMS (Technology Maturation and Risk Reduction (TMRR) and/or Production and Deployment (PD) phase). This guidance applies to most DoD programs following one of the formal Adaptive Acquisition Framework (AAF) pathways.

DoDI 5000.88 allows the approval authority for MDAPs or the DoD Component for ACAT II and III programs to waive the requirement for the IMP and IMS, which may be appropriate for programs that are well developed or less complex.

2.2 DoD Adaptive Acquisition Framework

The DoD AAF established in DoDI 5000.02 allows PMs to develop acquisition strategies and employ processes that match the characteristics of the capability being acquired. IMPs and IMSs are applicable to each AAF but should be tailored to the size and breadth of a project. When properly used, the tools enable programs to identify and mitigate risks.

At a minimum, all AAF pathways should incorporate IMPs and IE IMSs to provide to potential offerors during the pre-award phase of a project. Note that IMPs and IMSs for software acquisitions and the software portion of defense business systems vary greatly from those of traditional acquisition paths. Traditional paths rely on fixed requirements, whereas software acquisition depends on more fluid requirement evolution through the life of the project.

The DoD AAF consists of six pathways: MCA, Middle Tier of Acquisition (MTA), Urgent Capability Acquisition (UCA), Software Acquisition, Defense Business Systems (DBS), and Defense Acquisition of Services (DAoS). Appendix A illustrates the AAF. The Defense Acquisition University (DAU) AAF Document Identification (AAFDID) web page provides additional information for each pathway: https://www.dau.edu/aafdid/Pages/about.aspx.

Appendix B provides the complete AAF pathways.

The following paragraphs summarize each pathway in relation to the IMP and IMS.

https://www.dau.edu/aafdid/Pages/about.aspx

2.2.1 Major Capability Acquisition (MCA)

The goal of the MCA pathway is to acquire and modernize unique programs that provide enduring capabilities. The programs follow a structured, but not rigid, approach to analyze, design, develop, integrate, test, evaluate, produce, and support a system. Acquisition and product support processes, reviews, and documentation should be tailored based on project size, complexity, risk, urgency, and other factors. DoDI 5000.85, “Major Capability Acquisition”; the OUSD(R&E) “Test and Evaluation (T&E) Enterprise Guidebook, Chapter 4: Major Capability Acquisition”; and the DAU AAFDID web page provide more information. Figure 2-1 illustrates the MCA pathway. IMPs and IMSs should be developed or updated at or before each milestone

(MS).

Figure 2-1. MCA Pathway

2.2.2 Middle Tier of Acquisition (MTA)

The MTA pathway includes two subcategories: Rapid Prototyping and Rapid Fielding. The goal is to rapidly develop prototypes within an acquisition project to demonstrate new capabilities or to rapidly field production quantities of systems with proven technologies that require minimal development, integration, and investment. Rapid Fielding programs are expected to begin production within 6 months and proceed to system fielding within 5 years of the MTA project start date. DoDI 5000.80, “Operation of the Middle Tier of Acquisition,” and OUSD(R&E) “T&E Enterprise Guidebook, Chapter 3: Middle Tier of Acquisition” provide more information.

Figure 2-2 illustrates the MTA pathway. MTA project activities may be condensed. The IMP and IMS are critical to enable the project fielding within the prescribed time. Both products should be developed at project inception and updated as required.

Figure 2-2. MTA Pathway

2.2.3 Urgent Capability Acquisition (UCA)

UCA pathway programs provide capabilities to fulfill urgent operational needs and other quick action capabilities. Systems being developed and fielded under this framework must not exceed $525 million in research, development, and T&E, or $3.065 billion for procurements in Fiscal Year 2020 constant dollars for a single solution. The solutions need to be developed, tested, and fielded in under 2 years. DoDI 5000.81, “Urgent Capability Acquisition,” and OUSD(R&E) “T&E Enterprise Guidebook, Chapter 2: Urgent Capability Acquisition” provide more information.

Figure 2-3 illustrates the UCA pathway. Although IMPs and IMSs are not necessarily required for UCA programs, there are many benefits for having them. UCA programs are to be fielded in less than 2 years. During this period, many sequenced time-constrained activities need to be accomplished. In the case of a UCA, the IMP could be as simple as a spreadsheet laying out the Events, Accomplishments, and Criteria. The IMS assists the PM with managing tight schedules.

Figure 2-3. UCA Pathway

2.2.4 Software Acquisition

The Software Acquisition pathway is for the timely acquisition of custom software capabilities developed for the DoD. Software programs that meet the definition of a covered DBS should use the DBS pathway in accordance with DoDI 5000.75, “Business Systems Requirements and Acquisition,” but may elect to incorporate this pathway for custom developed software. This pathway integrates modern software development practice such as Agile software development, Development, Security, and Operations (DevSecOps), and Lean principles. Small cross-functional teams that include operational users, developmental and operational testers, software developers, and cybersecurity experts work to deliver software rapidly and iteratively to meet the highest priority user needs.

These mission-focused, Government-industry teams use automated tools for iterative development, builds, integration, testing, production, certification, and deployment of capability to the operational environment. These tools are not limited to just the Software Acquisition pathway. DoDI 5000.87, “Operation of the Software Acquisition Pathway,” and OUSD(R&E) “T&E Enterprise Guidebook, Chapter 2: Software Acquisition” provide more information.

Figure 2-4 illustrates the Software Acquisition pathway. Use of the IMP and IMS within the Software Acquisition pathway differs from the use in other pathways. Although an IMS typically would not include Level of Effort (LOE) activities, the program should schedule minimum viable product (MVP) and post minimum viable capability release (MVCR) sprints in the IMS.

Programs should work closely with their software development team to ensure the IMP structure matches the structure of Agile elements. For example, features or capabilities from an Agile perspective often correlate to the Criteria level of a project’s IMP.

Figure 2-4. Software Acquisition Pathway

2.2.5 Defense Business Systems (DBS)

The purpose of the DBS Business Capability Acquisition Cycle (BCAC) is to rapidly deploy business capabilities that address identified mission and capability needs within approved cost, schedule, and performance parameters. The PM develops documentation to apply commercial best practices and lessons learned to prioritize, rapidly develop, and deploy usable, affordable subsets of capability, such as a release. A release is a manageable subset of functionality, such as MVP, that provides utility in support of the business capability. The utility provided by a release does not have to fulfill the entire business capability. Additional utility may be added through iterative releases based on user feedback to minimize risk and increase adoption. DBS PMs can use IMPs and IMSs to define processes and schedules.

Figure 2-5 illustrates the DBS pathway. DoDI 5000.75 and the OUSD(R&E) “T&E Enterprise Guidebook, Chapter 6: Defense Business Acquisition” provide more information. DBS programs should develop IMPs and IMSs at project inception to assist PMs to navigate successfully through the DBS phases.

Figure 2-5. DBS Pathway

2.2.6 Defense Acquisition of Services (DAoS)

In the DAoS pathway, organizations acquire services from the private sector such as knowledge-based, construction, electronics and communications, equipment, facilities, product support, logistics, medical, research and development, and transportation services. The pathway assists organizations to identify the required services, research the potential contractors, contract for the services, and manage performance. DoDI 5000.74, “Defense Acquisition of Services,” provides more information. Figure 2-6 illustrates the seven steps of the DAoS pathway grouped into three phases: Plan, Develop, and Execute. Although the DAoS pathway does not require the IMP and IMS, the IMS could benefit the PM in planning and managing the schedule.

Figure 2-6. DAoS Pathway

2.3 IMP/IMS Guidance

This guide amplifies the event-based technical approach directed by DoDI 5000.88 and complements guidance provided in the following documents (see also References):

• Agile and Earned Value Management (EVM): A Program Manager’s Desk Guide

• Defense Acquisition University (DAU) Guidebook, “A Guide to Program Management Knowledge, Skills, and Practices”

• DAU Guidebook, “A Guide to DoD Program Management Business Processes”

• Defense Contract Management Agency (DCMA) EA PAM 200.1, Earned Value Management System Program Analysis Pamphlet

• DI-MGMT-81861C, Integrated Program Management Data and Analysis Report

(IPMDAR)

• DoD Digital Engineering Strategy (DES)

• DoD Earned Value Management Implementation Guide (EVMIG)

• DoD Earned Value Management System Interpretation Guide (EVMSIG)

• DoD Engineering of Defense Systems Guidebook

• DoD Guide for Integrating Systems Engineering into DoD Acquisition Contracts

• DoD Guide to Integrated and Process Development

• DoD IPMDAR Implementation and Tailoring Guide

• DoD Over Target Baseline and Over Target Schedule Guide

• DoD Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs

• DoD SEP Outline

• Government Accountability Office (GAO) Schedule Assessment Guide: Best Practices for Project Schedules

• Military Standard (MIL-STD)-881F, Work Breakdown Schedule (WBS) for Defense Materiel Items

• Systems Engineering Guidebook

Each Service, program executive office, or PMO may have unique procedures in their approach to developing IMPs, execution IMSs and other supporting documentation, depending on size and scope of each project. Government project teams should refer to their organization’s policies during the early stages of project planning for guidance and assistance in preparing these products. The IMP and IMS should be tailored and scaled according to the size, content, maturity, and risk of the project.

2.4 Digital Engineering Guidance

DoD is incorporating digital engineering methods throughout its acquisition processes. The DoD DES is a framework designed to leverage digital technologies to enhance the DoD’s engineering capabilities and support the acquisition and sustainment of defense systems. Three key objectives of the DES are to:

• Incorporate digital engineering (DE) principles and practices into the entire defense acquisition life cycle.

• Establish a common DE language, practices, and standards across DoD.

• Provide guidance and support for the development and deployment of the necessary DE tools and infrastructure.

To achieve these objectives, the strategy emphasizes modeling and simulation, data interoperability, and open architecture. The DES calls for the establishment of a DE ecosystem that includes a community of practitioners, a set of technical standards, and a network of digital infrastructure and tools. DE moves the primary means of communicating system information from documents to digital models and their underlying data. Digital models become ubiquitous and central to how engineering activities are performed. Project schedules are digital models and should be integrated with other digital models of the project to support the project’s DE effort.

3. Relationship of IMP and IMS to WBS

3 RELATIONSHIP OF IMP AND IMS TO WBS

The product that greatly influences the development of the IMP/IMS is the WBS. This section will provide an overview of the WBS and its relationship with the IMP and IMS. MIL-STD- 881F provides detailed information on types of WBSs and how they are developed.

3.1 Relationship to Work Breakdown Structure

The WBS is a hierarchical decomposition of a project into smaller, more manageable components, which are grouped into various levels and phases. It is a visual representation of the project scope, showing all the work that is required to be completed to achieve project objectives. Figure 3-1 provides an example of a WBS. MIL-STD-881F includes detailed information on the types of WBSs and how they are developed.

Figure 3-1. WBS Example

A WBS typically consists of the following levels:

• Project. The highest level of the WBS, which represents the overall project.

• Common Elements. Normally the 2nd level of the WBS, referring to elements that are applicable to all major systems and subsystems.

• Phases. Elements that are the major phases and sub-phases of the project.

• Deliverables. The tangible products or services that will be delivered to the customer or stakeholders. These can be broken down into smaller, more manageable deliverables.

• Work Packages. A group of related tasks or activities that are managed as a single unit.

They consume resources and are completed to satisfy specific Criteria. Work packages describe the expected way work is to be conducted. They are a subdivision of a control account, assignable to a single program organizational element. Through work packages a program plans the work, measures technical progress, and determines earned value.

• Planning Package. A logical aggregation of future work within a control account that cannot yet be planned in detail at the work package level. As the requirements and project schedule become clearer, planning packages are decomposed into work packages.

• Control Account. A management control point that represents a cluster of related work packages. It is a specific subset of the project’s overall WBS that represents a significant portion of the project’s work scope and budget. Every task and activity, work package, and planning package should be directly traceable to a control account. It is at the control account where EVM is used to measure progress of a project against its planned cost and schedule.

The WBS is the foundation of the IMP and IMS. The IMP Events, Accomplishments, and Criteria are derived from the WBS common elements, phases, and deliverables. The IMS Tasks and activities link to the WBS at the work package and planning package level.

3.2 Relationship to Organizational Breakdown Structure

The Organizational Breakdown Structure (OBS) allows assignment of roles and responsibilities and also intersects with the WBS. Work and planning packages are assigned to individuals, teams, or Integrated Product Teams (IPTs) and are managed at the control accounts. Figure 3-2 illustrates the relationship among the OBS, WBS, IMP, and IMS.

Figure 3-2. Relationship Among OBS, WBS, IMP, and IMS

4. Integrated Master Plan

4 INTEGRATED MASTER PLAN

4.1 IMP Overview

The IMP is an event-based plan consisting of a hierarchy of project events, with each event supported by specific accomplishments, which are to be satisfied by specific criteria. The approved contractor IMP generally becomes part of the contract and thus is legally binding on both the Government and contractor. Although fairly detailed, the IMP is a summary-level document compared with the IMS.

The three major levels of an IMP hierarchy are Events, Accomplishments, and Criteria. DAU defines these levels as follows:

• Event: A project assessment point that occurs at the culmination of significant project activities (Accomplishments and Criteria). An example could be “system testing.” In this case, all system testing activity needs to be completed to satisfy this Event.

• Accomplishment: The desired result(s) before or at the completion of an Event that indicates a level of the project’s progress. Therefore, Accomplishments are subsets of an Event. An example could be subsets of the Event “system testing,” which may include developmental testing (DT), operational testing (OT), and live-fire test and evaluation (LFT&E). These specific Accomplishments need to be completed for Event “system testing” to be considered achieved. In the case of testing, “desired results” refer to the completion of an Accomplishment, not necessarily positive outcomes of that Accomplishment.

• Criteria: The definitive evidence that a specific Accomplishment is accomplished.

Criteria are subsets of Accomplishments. For example, hull testing, fire control testing, and survivability testing are subsets of DT and therefore are the Criteria under the Accomplishment “DT.”

Developing the IMP and IMS involves some collaboration between the PMO and contractor to arrive at the best plan. The PMO should develop an IMP and IE-IMS (see also Section 1) during the solicitation phase to provide with the RFP. The IMP should be detailed enough to portray the PM’s vision of how the project should proceed so the offeror can provide a corresponding proposal in response to the RFP requirements. Potential offerors can provide additional insight as part of their proposed IMP and IMS.

Before developing their respective versions of the IMP and IMS, the Government and offeror’s team should understand the system acquisition requirements as outlined in the RFP. The Government should use the proposed IMP to evaluate the offeror’s understanding of, and approach to fulfilling, the requirements. The successful offeror’s IMP, incorporating any changes negotiated with the Government, should be included in the contract. The IMP should be kept as one integrated plan that encompasses all IPTs, WBS elements, and functional disciplines.

The post-award project team (Government and contractor) should select the system-level Events, which serve as progress checkpoints and indicate the project’s readiness to move to the next group of work efforts. The team then should reevaluate the Accomplishments and Criteria identified in the IMP to support each Event to ensure the elements captured at the post-award time are still correct for execution. IPTs from each functional discipline should perform this check, discussing the Criteria and Accomplishments with the system-level IPT to ensure the IMP includes the correct details. This way if the IMP requires a change, the appropriate personnel will be involved to approve and make the needed contractual changes.

The IMP should include significant subcontractor activities, which in turn should be supported by the subcontractor’s IMP and Subcontractor IMS (SC-IMS).

4.2 Developing and Formatting the IMP

This section provides a recommended approach to developing and formatting the IMP. Typical steps in developing an IMP include the following:

• Determine the IMP structure and organization.

• Identify Events, Accomplishments, and Criteria.

• Prepare the “Introduction” and “Narrative” sections.

• Complete the numbering system.

• Iterate Events, Accomplishments, and Criteria with the IPTs during IMS development.

The same principles apply to the IMP, whether developed by the Government or contractor.

4.2.1 Action Verbs

Standardizing verb forms in the IMP and corresponding IMS can help clarify the communication in these documents. A best practice is to phrase the Events, Accomplishments, and Criteria using verbs in the form of past participles such as “[Item] Completed” and “[Item] Conducted” to indicate the final desired state of that item. Similarly, a best practice is to phrase the IMS Tasks starting with an imperative verb, such as “Perform...” or “Develop...” to indicate what the program should do. Appendix A provides a list of commonly used action verbs.

Figure 4-1 illustrates the use of action verbs to describe Events, Accomplishments, Criteria, and Tasks. The Event “A: Preliminary Design Review (PDR) Completed” and the supporting Accomplishment A01 and Criterion A01a are assessment points. The four IMS Tasks (A01a01- A01a04) identify work that is required to be performed to enable the Events, Accomplishments, and Criteria to be designated completed. To satisfy the Event, the program must complete the

Tasks in the work package, which roll up to satisfy the Criterion. Criteria satisfy an Accomplishment, and Accomplishments roll up to complete the Event.

Figure 4-1. Action Verbs

4.2.2 Section 1. Introduction

The introduction should include the following:

4.2.2.1 Description. The IMP should provide a brief description of the project, system, and subsystems.

4.2.2.2 Assumptions. This is a very important paragraph. It documents “assumed” responsibilities among the Government, contractor, subcontractors, and vendors. These assumptions and ground rules need to be understood and agreed upon by both Government and contractor before the parties approve the joint Government and contractor IMP. Items may include:

• Assumptions o All stakeholders are committed to the project’s success.

o The project’s scope, requirements, and deliverables have been clearly defined.

o All necessary resources, including people, equipment, and funding, are available or will be made available on time.

o Risks and uncertainties have been identified and addressed in the plan.

o The project team has the necessary skills, experience, and knowledge to execute the plan.

• Ground Rules o Communication channels are established and adhered to.

o All project activities are documented and tracked.

o Milestones and deliverables are defined and monitored.

o Changes to the plan are managed through a formal change control process.

o Quality standards and metrics are established and monitored throughout the project.

o The project is regularly reviewed to assess progress and adjust as necessary.

In some cases, the procuring activity may want the IMP Event table to include expected completion dates, which would be the dates from the execution IMS. If used, these dates may be for information or they may be considered contractual dates that must be met and could be tied to other contractual items, such as the award fee. The procuring activity should clearly state whether the dates are intended to be contractual or simply for information. Although there may be circumstances in which the procuring activity chooses to impose certain dates in the IMP (e.g., Initial Operational Capability), as a best practice most IMP dates should be for information only, to avoid creating a potential need for contract modifications in the future.

4.2.2.3 Event and Action Dictionary. The Event and Action Dictionary (EAD) is a structured list of events and actions that are critical to the success of the project. It provides a common language and understanding of the key milestones and activities that must be accomplished to achieve the project’s objectives.

The EAD typically includes a detailed description of each Event or action, its dependencies, timing, and performance metrics. Each event or action is linked to specific tasks, resources, and deliverables required to complete it successfully. The EAD also provides a framework for tracking and reporting progress against the plan, identifying potential risks and issues, and making necessary adjustments to the project schedule and resources.

Some examples of events and actions that may be included in an IMP EAD include:

• Design reviews. A series of formal reviews to ensure that the design of the system meets requirements and is feasible within the project’s constraints.

• T&E. T&E events conducted to verify that the system functions as intended and meets the specified performance Criteria.

• Milestones. Significant events in the project schedule, such as completion of major deliverables or the achievement of a key performance milestone.

• Procurement and production events. Activities related to the acquisition and production of hardware, software, and other resources required for the project.

• Risk management events. Activities related to identifying, assessing, and mitigating risks that could affect the project’s success.

Overall, the IMP EAD serves as a roadmap for the project team, providing a clear and concise view of the critical events and actions that must be accomplished to achieve the project’s objectives.

4.2.2.4 Program Organization. For a sole-source contractor-executed program or competitive contracted programs, the offeror will describe their organizational structure to their IPT level.

The successful offeror’s IMP program organization description will provide insight to the Government PMO to allow proper alignment of the Government personnel for project oversight and formal communications between the Government and contractor.

4.2.2.5 Reference Documents. This IMP paragraph should include all Government and contractor reference documents that are critical to the project. Government reference documents may include:

• SEP

• Risk Management Plan (RMP)

• Technical Requirements Document (TRD)

• Test and Evaluation Master Plan (TEMP) and Test Strategy

• Configuration Management Plan (CMP)

• Government IMP and execution IMS

• Government WBS

• MIL-STDs

• Software Development Plan (SDP)

• Configuration Management/Data Management Plan (CM/DMP)

Contractor reference documents may include:

• Business Process Plans

• Project Management

• Test Plans and Procedures

• Contract Manuals

4.2.3 Section 2. Numbering, Event Details, and IMP Table

4.2.3.1 Numbering System. The IMP Section 2 begins with a description of the numbering system, which usually consists of hierarchical alphanumeric numbers for both the IMP and IMS.

This numbering system is a structured way of identifying and categorizing different Events, Accomplishments, Criteria, Tasks, activities, work packages, and planning packages. This numbering system is typically designed to be consistent and standardized across an entire project, so everyone in the project can understand and use the IMP and IMS.

Some programs may have multiple IMPs and IMSs for multiple contractors and subcontractors and for contractor proprietary reasons. For these cases, the overarching IMP should provide the numbering system of each sub-IMP and how they link to the overarching IMP. Each IMP on a program should use a unique numbering sequence.

Organizations can develop their own numbering systems based on organizational needs and the project management software they are using. The project management software should be able to automatically generate the alphanumeric code. Figure 4-2 provides examples of different IMP numbering methods.

Figure 4-2. Examples of IMP Numbering

4.2.3.2 Project Event Description. The project obtains Event definitions from several sources, primarily initial project planning documents. For example, high-level project roadmaps, implementation plans, or even requirements documents may contain Events that can be organized into a hierarchy using an IMP. A project Event description typically includes the following information:

• Event Title. A brief descriptive title for the Event or milestone.

• Event Description. A detailed description of the Event, including what is expected to be accomplished and why it is important to the project.

• Event Type. The type of Event, which could be a major milestone, a deliverable, or a decision point. DoD programs often use the abbreviation “MS” to mean “milestone.” For the purposes of this guide, the abbreviation MS refers to a major MS, such as MS A, B, or C. A project may choose to use “MS” for other project-defined Events and should clarify the definition in its IMP dictionary.

• Event Date. The planned date for this Event to occur. This could be a specific date or a range of dates, i.e., if the Government program schedule indicates a milestone to be completed in a specific quarter and fiscal year, this projected date is used.

• Event Dependencies. Any Event or milestone that needs to be completed before this Event can occur, i.e., the delivery of x, y, and z need to occur before MS X.

• Event Resources. The resources required to complete the Event, including personnel, funding, facilities, and equipment.

• Event Success Criteria. The specific Criteria that must be met to consider the Event a success.

Not all programs need to go into this level of detail. If developing a new combat helmet, this outline would be overkill, but if developing a new generation combat vehicle or aircraft requiring a manufacturing capability and new technology, then this level of detail would be required.

4.2.3.3 IMP Table. The program develops the IMP table using specific elements of the project’s WBS. A basic IMP table should include Events, Accomplishments, Criteria, and cross-reference to the appropriate WBS element(s). Table 4-1 illustrates an IMP table in which the level “F” represents an Event, level “F.01” represents an Accomplishment, and level “F.01.a” represents a Criterion.

Table 4-1. IMP Table Example

Activity

Event Accomplishment Criteria

WBS #

F Event F - System Testing 1.5 F.01 Developmental Testing (DT) Completed 1.5, 1.5.1 F.01.a Phase I Water Testing Conducted 1.5, 1.5.1, 1.5.1.1 F.01.b Hull Testing Conducted 1.5, 1.5.1, 1.5.1.2

Activity

Event Accomplishment Criteria

WBS #

F.01.c Gunnery Testing Conducted 1.5, 1.5.1, 1.5.1.3 F.01.d Interoperability Testing Conducted 1.5, 1.5.1, 1.5.1.4 F.01.e DT Failure Definition/Scoring Criteria Conducted 1.5, 1.5.1, 1.5.1.5 F.02 Live-Fire Test and Evaluation (LFT&E) Completed 1.5, 1.5.2 F.02.a Full-up LFT&E Waiver Approved 1.5, 1.5.2, 1.5.2.1 F.02.b Hull LFT&E Conducted 1.5, 1.5.2, 1.5.2.2 F.02.c Troop Compartment Panels LFT&E Conducted 1.5, 1.5.2, 1.5.2.3 F.03 Operational Testing (OT) Completed 1.5, 1.5.3, F.03.a Operational Assessment (OA) I (Mock-up) Conducted 1.5, 1.5.3, 1.5.3.1 F.03.b OA II (Mission Profile) Conducted 1.5, 1.5.3, 1.5.3.2 F.03.c OT FD/SC Scoring Conducted 1.5.3.3

The distinction between Events and Accomplishments, or between Accomplishments and Criteria, may vary. Often the choice depends on the complexity, size, or length of the project. It is not unusual to see the same activity designated as an Event in one IMP and an Accomplishment in another. Similarly, an Accomplishment in one project may be a Criterion in another or may be a Task in the IMS. If each IMP activity supports the one above it, progressing from specific to general, then the IMP meets the intent.

• Event (F). An Event (e.g., Event F - System Testing) is a project assessment point that occurs at the culmination of significant project activities. An Event includes Accomplishments and Criteria. For an Event to be considered completed, all Accomplishments under the Event must be completed. Summary lines should not use verbs.

• Accomplishment (F.01). An Accomplishment (e.g., DT Completed, LFT&E Completed, and OT Completed) is the desired result(s) before or at completion of an Event, indicating a level of the project’s progress. Although no typical number of Accomplishments are expected to be included, normally there will be two or more Accomplishments per Event. The important point is that each selected Accomplishment when completed should substantially contribute to the success of the related Event.

In Table 4-1, “Event F - System Testing” is composed of three Accomplishments that need to be completed to consider the Event completed. The action verb “completed” needs to be defined in the EAD. In this case, “completed” means “the item or action has been prepared or accomplished and is available for use and/or review.” The definition should be broad enough to cover all uses of the word in the IMP.

• Criteria (F.01a). Criteria (e.g., Operational Assessment (OA) I (Mock-up) Conducted;

OA II (Mission Profile Conducted; and OT failure definition/scoring Criteria (FD/SC) Scoring Conducted) provide evidence that a specific Accomplishment has been completed. Criteria can be either quantitative or qualitative yet must be measurable. Entry Criteria reflect what should be done to initiate a review, demonstration, or test. Exit Criteria reflect what should be done to ascertain the Event has been successfully completed. There is no typical or required number of Criteria for each Accomplishment in the IMP. Generally, there should be at least two Criteria to support an Accomplishment, but there may be occasions when one is appropriate. The important point is that completion of the Criterion should provide evidence of completion of the associated Accomplishment. In Table 4-1, “conducted” and “approved” are action verbs used for the Criteria. The IMP could define “conducted” as “review or meeting is held physically, and minutes and actions plans are generated, or test or demonstration is performed.”

F.01.a Phase I Water Testing Conducted

F.01.b Hull Testing Conducted

F.02.a Full-up LFT&E Waiver Approved

4.2.4 Section 3. IMP Narrative

Section 3 of the IMP provides narratives, if desired, to include: Task Narratives, Process Narratives, and others as necessary (e.g., risk discussion). These will be contractually binding, so the program should be careful when choosing narratives. An option may be to rely on the SEP submittal to discuss specific process approaches. In both the Government and contractor IMPs, the narrative should address only the key elements of developing or implementing a process or procedure (i.e., what it is and how it should be tailored or implemented on the specific project).

The IMP narrative does not need to provide supporting information or rationale. The contractor should provide supporting information in the technical volume of the proposal. The IMP process and Task narratives should reference a Statement of Work (SOW) paragraph number and WBS, if applicable.

4.2.4.1 Process Narratives. Process narratives may provide the Government with an understanding of the proposed critical processes and procedures before contract award. These narratives should consist of concise summaries describing key management and functional processes and procedures, how they relate to the integrated product development process, and an overview of efforts required to implement them. For example, if a SEP is not required the

Government might want an explanation of the offeror’s technical approach, risk management, or software development activities. Each process narrative should include the following:

• Reference to any governing documentation, such as the contractor’s standard process, or any governing DoD or Service guidance.

• An overview of the process, including process flow diagrams (see Figure 4-3).

• If the process is an existing one, a description of how the process should be tailored and implemented to the specific project.

• The description of any metrics that should be used to measure the process.

Figure 4-3. Example Process Flow Diagram for a Technology Insertion Process

4.2.4.2 Task Narratives. Task narratives may be used to describe the approach to executing those Tasks for which there may be no specific IMP Accomplishments. For example, the Government might want to define contractually how level-of-effort Tasks, such as configuration management or program control supporting the overall program, should be accomplished.

Practitioners debate whether process narratives should be included in the IMP. Some organizations use them; others discourage their use.

Reasons to include process narratives:

• Provide additional insight into critical processes to be used in executing the project.

• Provide contractual commitment to the use of processes in contractor-executed programs.

• Assist in the development of execution IMS Tasks.

Reasons not to include process narratives:

• Can significantly increase the size of the IMP.

• May necessitate a contract change if processes change.

• Decreases the contractor’s flexibility to make internal process changes.

• Inhibits continual process improvements.

In general, the narrative should address only key elements of developing or implementing a process or procedure (i.e., what the process or procedure should be or how it should be tailored or implemented on the specific project). The Government and contractor’s narrative need not provide detailed information or rationale. The contractor should provide amplifying information in the technical volume of the proposal. As with Task narratives, process narratives should reference a SOW paragraph number and WBS number, if applicable.

4.2.5 Section 4. Glossary

The IMP should include a glossary of terms and acronyms to ensure stakeholders have a common understanding of the terminology used in the IMP. This is especially true in complex programs involving multiple teams and stakeholders with various backgrounds and expertise.

4.3 Relationship Between IMP and IMS

Figure 4-4 shows the relationship between the IMP and IMS. The IMP tracks the completion of Events through their supporting Accomplishments and Criteria. The IMP should demonstrate the maturation of the product as it progresses through a disciplined systems engineering process.

The IMS reflects the Events, Accomplishments, and Criteria from the IMP and includes further detail in the form of Tasks with estimated dates. The IMS should display IMP traceability (e.g., through a customizable field) using a coding structure that allows for identifying IMP Events, IMP Accomplishments, IMP Criteria, and IMS Tasks supporting the Criteria.

IMP #

Event Accomplishment Criteria

WBS REF

A Systems Requirements Review (SRR) 1.5 A.01 SRR Preparation Accomplished 1.5.1 A.01.a Begin SSR Preparations 1.5.1, 1.5.2 A.01.b SRR Training Requirements Analysis Completed 1.5.1, 1.5.3 A.01.c Standard Test Equipment (STE) Requirements Analysis Completed 1.5.4 A.02 Systems Requirements Analysis Completed 1.7 A.02.a Requirements Analysis Completed 1.7.2 A.02.b Certification and Accreditation (C&S) 1.7.4, 1.7.5 A.03 SRR Accomplished 1.5.1 A.03.a SRR Contract Data Requirement Lists (CDRL) Delivered 1.5.1, 1.5.2 A.03.b SRR Meeting Conducted and Action Items Addressed 1.5.1, 1.5.2 B Pre-EMD Integrated Baseline Review (IBR) 1.4 B.01 Post Contract Award Conference Completed 1.4.1 B.01.a Contract Award Completed 1.4.1 B.07 Program Kickoff Completed 1.3.1 B.07.c Ops Kickoff Tasks Completed 1.3.1, 1.3.4 B.07.d Systems Engineering Kickoff Tasks Completed 1.3.1, 1.3.4

Integrated Master Plan (IMP)

Figure 4-4. Relationship between IMP and IMS

5. Integrated Master Schedule

5 INTEGRATED MASTER SCHEDULE

5.1 IMS Overview

The IMS lists the IMP Events, Accomplishments, and Criteria, and also includes detailed Tasks to depict the steps required to satisfy Criteria. The IMS provides a comprehensive overview of Tasks required to complete a project. It includes the start and end dates for each Task, as well as dependencies, durations, and resource requirements. It is an integrated, logically driven, networked-based schedule that is vertically and horizontally traceable.

The GAO Schedule Assessment Guide (GAO-16-89G 2015) lists the following as Best Practice 1: “The schedule should reflect all activities as defined in Program WBS, which defines in detail the work necessary to accomplish a program’s objectives, including activities both the owner and contractors are to perform.”

The IMS should include all elements associated with the development, production or modification, and delivery of the total product and project high-level plan.