Designing, building, testing, and deploying complex systems is fraught with risk. And as always risk comes from uncertainty. And uncertainty comes in two forms - reducible (Epistemic) and irreducible (Aleatory). Much has been written about the sources of risk and how to Manage in the Presence of Uncertainty (This briefing describes how risk is managed for each element of the Integrated Master Plan).
What About the Plan to Manage in the Presence of Uncertainty
Plans are Strategies. A Strategy is a Hypothesis. The Hypothesis requires tests (experiments) to confirm that we're moving in the right direction along the path defined in the Plan. This is the role of a roadmap, a literal roadmap, folded and placed on the lap of the passenger in the car for our road trip. I miss those days, where you could trace the route of where you came from and the route of where you are going with your finger.
The role of the Integrated Master Plan is to provide the Strategy for the successful completion of the program.
So how do we build the Integrated Master Plan and the Integrated Master Schedule to supports the plan? First, let's look at what we're talking about
The Integrated Master Plan (IMP) and Integrated Master Schedule (IMS) are important tools that provide significant assistance in planning and scheduling work efforts. This document outlines an approach to support program and project teams in developing effective integrated execution plans for weapons systems and subsystems and component acquisition, modification, and sustainment.
The IMP is an Event-based plan consisting of a hierarchy of program Events, with each event being supported by specific Accomplishments, and each Accomplishment associated with specific Criteria to be satisfied for its completion. The IMP should provide sufficient definition to track the step-by-step completion of the required Accomplishments for each event and to demonstrate satisfaction of the completion Criteria for each Accomplishment. IMP the Events are not tied to calendar dates; each event is completed only when its supporting Accomplishments are completed as evidenced by satisfying the Criteria supporting each of those Accomplishments. This plan, the IMP, is placed on contract and becomes the baseline execution plan for the program/project. Although fairly detailed, the IMP is a top-level, foundational document compared to the IMS.
This methodology document uses a 5x5 solutions approach including the following:
- Five conditions that must be satisfied by the IMP
- Five steps in developing an IMP
- Five questions regarding IMP development
- Five most common mistakes in IMP development
- Five templates/samples of the key IMP sections
- The chart below shows the 5x5 Methodology
Five Conditions That Must Be Satisfied in an IMP
There are Five major conditions the IMP must meet:
- Complete – Reflects the entire contract scope of work
- Traceable – Aligns with other program management artifacts
- Transparent – Comprehensible display of what needs to be done and how completion is measured
- Usable – Useful for developing other program management artifacts and for tracking the status of program achievements
- Controlled – Configuration-controlled, approved, and kept aligned to contract modifications
Complete
The IMP is a top-down view of the contractual work scope. It is the foundation for the IMS that is developed from the bottom-up; detailed task planning that supports specific IMP Criteria. It is essential that the IMP represent the work that must be performed. Several documents may be used to ensure that the IMP is complete.
If the IMP is being prepared as part of a proposal, then the Request for Proposal (RFP) and RFP attachments will be the primary documents to define the work to be performed. The RFP normally includes a Statement of Work (SOW) and Contract Data Requirements List (CDRL) that are invaluable in determining the scope of the IMP. Often the customer includes a program roadmap or top-level schedule that also helps define the scope of the IMP.
If the IMP is being prepared or updated after contract award, a Work Breakdown Structure (WBS) may be available. The WBS and its accompanying WBS Dictionary helps ensure that the scope of work in the IMP is complete. The WBS should be completely addressed in the IMP.
Traceable
The IMP should trace to other program artifacts. As a minimum, the IMP should trace to the WBS, SOW, and the Organizational Breakdown Structure (OBS). The SOW is essential for vertical integration from the detailed tasks to contracted work scope. The OBS is essential to identify responsibility for Accomplishments. The WBS is essential to ensure that all elements of work are represented in the IMP.
To demonstrate traceability most IMPs include cross-reference fields for WBS, OBS, and SOW. Cross-references may be at the Accomplishment Criteria level. The granularity of the IMP must be sufficient that only one OBS is listed for each Accomplishment Criteria.
Usable
An IMP is not just prepared and delivered. There are benefits from the use of the IMP. Most IMPs in development programs include Events for major design reviews such as PDR or CDR. The IMP shows the Accomplishments and the measures of Accomplishments that are essential to get through a design review. The IMP is a good top-level checklist to see what needs to be done to reach each major milestone. The cross-references in the IMP such as OBS, SOW, and WBS elements tell the managers which groups are responsible for which efforts. Through continued use, the IMP paints a picture of the program in the Program Manager’s and program team’s minds and facilitates stakeholder understanding, relating work efforts and progress to program goals and objectives.
Controlled
The IMP reflects the contracted work. The IMP is normally an approval deliverable. For these reasons, the IMP should be a configuration controlled document. When the contract is modified with additional scope, the IMP should be updated and aligned with the IMS accordingly. In a controlled environment, anytime the contract is changed or a Baseline Change Request is approved that changes scope, the IMP should be reviewed and revised—if required. If the organization is restructured or the WBS is changed, review the IMP and update it accordingly.
Five Steps in IMP Development
Developing an IMP takes these five key steps:
- Collect input information
- Identify Events
- Populate Events, Accomplishments, and Criteria
- Populate supporting sections of document
- Validate information with cross-references
Each of these steps is further described below:
IMP Development Environments
Sometimes an IMP has to be provided with the contract proposal. In this environment, the IMP is developed with less input material than one developed after the contract has been awarded and the project teams formed. Primary inputs are contained in the RFP and will include the Statement of Work (SOW), a top-level schedule or roadmap of the program, and a deliverables list. The personnel available for providing inputs to the IMP may be limited to the proposal team and selected functional managers. Rarely are Control Account Managers (CAM) or work package managers available for input in this environment.
When the initial IMP is prepared after contract award, it is common to have the performance team in place. CAMs are available to generate the bottom-up detail planning that fits with the top-down planning of the IMP development process. Supporting artifacts such as the WBS, WBS Dictionary, Basis of Estimates (BOE), and the Systems Engineering Management Plan (SEMP) are available to help define the scope of the work to be performed and especially the entrance and exit criteria for key program Events.
Collect Input Information
One of the most challenging tasks in IMP development is taking different artifacts that each have a distinct view of the project and combine them to show the program by Events and Significant Accomplishments. The chart on the next page shows the key inputs for the development of the IMP.
Identify Events
Having collected the inputs for the IMP, the next significant step is to determine the Events that will represent the program. One way to do this is to have an experienced program planner review the input data and prepare a draft Events list. The next step is to convene a brainstorming session of key program stakeholders to review and update the draft Events list. Once the Events list is agreed to, the team should ensure each Event meets the guidelines for an IMP Event. The PM and Chief Engineer should be a part of the session that develops the Events. It is important to get their approval of the Events before developing the next level of detail in the IMP.
Populate Event Descriptions, Accomplishments, & Accomplishment Criteria
The next step for the IMP development team is to conduct a brainstorming session to take each Event and break it down into the Significant Accomplishments that support those Events. It is helpful to begin this session by preparing or reviewing the descriptions of each Event. A short two or three sentence description of each Event will ensure that the Accomplishments fit within the scope of each Event.
The Significant Accomplishments are the major elements that must be done to satisfy each event. Another way to look at the Accomplishments is that the Accomplishments should represent the high level “SHALL” statements in the project statement of work. Once the Accomplishments are reviewed and organized under the event they support, they should be reviewed and approved by the project manager.
Since the process to break down the Events down through Accomplishment Criteria can be time-consuming, it often best to set a separate session to develop the Accomplishment Criteria. It is important that the Criteria be of sufficient detail so the team executing the project can define IMS tasks under them. It is also important to remember that each project execution task should support one and only one Criteria and the Criteria should be at a high enough level that multiple tasks fit under each criterion. It is often helpful to take a “typical” list of project tasks and try to integrate them into the IMP to verify that Criteria are sufficiently developed. These tasks do not remain in the IMP, as the Criteria is the lowest level. The efforts of major subcontractors are usually integrated at the Criteria level of the IMP. Once the team believes they have a comprehensive set of Criteria, those Criteria should be reviewed with the project management team for approval prior to completing the IMP. The approval of the Criteria by the project manager is advised here despite the fact that the Criteria will probably be iterated as the IMS is built and tasks are developed.
Populate Supporting Sections of the IMP
There are several sections that one should consider including in an IMP. The first is “Ground Rules and Assumptions.” This material is normally combined in an “Introduction Section” that may also include a description of the contractor’s organization for the program and a review of the contents of the IMP. By listing the Ground Rules and Assumptions, it will key the need to revise the IMP should any of the assumed conditions change. Assumptions should address items such as the acquisition processes and policies that apply to the program, reference any top-level documents that drive the determination of Events, and the integration of participating organizations from prime contractor through subcontracted efforts.
Another important supporting section is the “Action Verb Listing”. The action verbs are normally collected as the Accomplishment Criteria are being defined. Some expansion of this initial list is expected as the wording of tasks and work packages in the IMS is considered. Action verbs and their definitions are a hedge against conflicts and confusion in the execution of the program.
Another section that should be included is the “Glossary or List of Terms and Acronyms”. Based on the audience the IMP author should consider whether a glossary is required. Since the IMP is a communication between the contractor and the customer, prior contract relations and team composition may not make a glossary required. An acronyms listing is normally needed as contractor and customer may not always use the same set of acronyms to define elements of the program.
The final supporting section that should be considered is “Narratives”. There are at least two types of narratives that may be considered for an IMP; Process Narratives and Task Narratives.
Process Narratives may be used to facilitate contractor commitment to the use of crucial processes and procedures and provide the Government with an understanding of the proposed crucial processes and procedures prior to contract award. In a proposal phase IMP, a contractor may use the IMP process narrative to bring attention to a unique process that may contribute to source selection. These process narratives would consist of concise summaries providing visibility into key management and functional processes and procedures, how they relate to the integrated product development process, and an overview of the efforts required to implement them. If the contractor has or will provide a description of a process in another document such as the Systems Engineering Process described in the SEP or SEMP, then that process should not be included in the IMP process narratives. Care should be taken in the inclusion of process narratives as the IMP is normally a contractual document and the contractor can be held to the processes described in the approval document.
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, will be accomplished. If a task narrative describes efforts related to a specific SOW task, then it is desirable to reference the SOW paragraph number, as well as the applicable WBS, in the narrative. Task narratives are often included when the government provides a Statement of Objectives rather than a more precise SOW.
Validating Information with Cross References
The validity of the IMP is increased by references to other program artifacts. This cross-referencing demonstrates that all the documents used to execute the program will be consistent with one another. IMP Events, Accomplishments and Criteria should be cross-referenced to the SOW, WBS, and OBS. If the IMP is included in the IMS, that cross-reference is also covered.
The IMP should cross reference other documents. For example, if a process narrative is included to describe configuration management, then the Program or Business Configuration Management Plan should be referenced in that narrative. Once the IMS is complete, a check of the action verbs in the IMP and IMS should be made to ensure consistency.
Five Questions regarding IMP Development
Five questions occur most frequently in IMP development:
- How are Events selected?
- How should Events, Accomplishments, and Criteria be coded?
- What should supporting sections be included?
- What cross-referencing is appropriate / required?
- How often should be IMP be updated?
Each of these questions is answered below:
How are Events selected?
The selection of Events is driven by several factors. The customer’s view of the program and their definition of Events must be considered. If in a prime/subcontractor situation, determine if the prime expects the same reviews performed at the system level to be held at the subsystem level. The SOW must be incorporated into the Events. Key terms to look for are “reviews”, “gates”, and “phases”. Finally, the methods the PM plans to use to execute the program must be taken into consideration. The event selection should be as much as possible a consensus building exercise with the program team.
How should Events, Accomplishments, and Criteria be coded?
A numbering schema for Events, Accomplishments, and Criteria will make the cross-referencing of the IMP to other artifacts easier to track. As stated earlier, the IMP narrative should also explain the IMP numbering scheme that is employed. This numbering scheme is important as it will be carried through to the IMS for the execution of the project and will be used throughout the life of the project. There are many different numbering approaches to select for integrated master plan identification. Regardless of the approach, use a single numbering system in the IMP and IMS. The number for each IMP entry should be unique. Typically, an IMP number contains three positions, and is obtained from the first column in the IMP, entitled “IMP Number.”
These numbers reflect:
- Event Code - the Event within the IMP section.
- Accomplishment Number - the Significant Accomplishment of the Event contains the Event code followed by a period, followed by a sequentially assigned Accomplishment number.
- Criteria Number - the Accomplishment Criteria within the Accomplishment contains the Event code followed by a period, the sequentially assigned Accomplishment number followed by a period, and a sequentially assigned Criteria number.
The core team should define the IMP-IMS numbering scheme to facilitate communications as well as sorting and viewing IMP-IMS information. If the customer specifies a particular format, any modifications must be explained to show how it adds value, e.g., to access particular information. An alphanumeric reference may be used to provide tracking between the IMP and the IMS. In this scheme, A010413 could designate the following:
- A - Program Event
- 01 - Significant Accomplishment
- 04 - Accomplishment Criteria
- 13 - Task
What supporting sections should be included?
The DoD Integrated Master Plan and Integrated Master Schedule Preparation and Use Guide recommend the following content items:
- Introduction (Program Description, Ground Rules and Assumptions, program team organization, Action Verbs, and any unique features of the IMP)
- IMP Events, Significant Accomplishments, and Accomplishment Criteria
- IMP Narratives
- Glossary (to include acronyms)
What cross-referencing is appropriate / required?
The minimum cross-references appropriate for the IMP include the WBS, the OBS, and the SOW. Additionally, the IMS has to cross-reference to the IMP. Either the IMP should be inserted into the IMS or the IMP coding for Events, Accomplishments, and Criteria should be included in a field within the IMS and assigned to tasks and milestones accordingly.
How often should the IMP be updated?
The IMP represents “what” should be done on the contract. If the scope of the contract changes, the IMP should be updated. If any of the cross-referenced related documents change, such as OBS, SOW or WBS, then the IMP should be revised if necessary. Some program teams include as part of the baseline change process, a check to see if the IMP should be revised.
Five Most Common IMP Mistakes
The five most common mistakes are:
- Not aligning the IMP to customer Events;
- Not including all scope and not having detailed entrance and exit Criteria;
- Inadequate cross-referencing;
- Not applying the IMP in subsequent artifact development; and
- Not using the IMP to educate and focus the program team.
Each of these common mistakes is further described below.
Not aligning the IMP to customer Events
The contractor’s immediate customer may be a government organization or a prime contractor. The government organization will often have a program roadmap or government IMP that lists the key Events and milestones for the program. This document is often provided as part of the RFP. Similarly, prime contractors may have already developed and delivered an IMP at their level prior to a subcontractor developing their own IMP. In either case, it is important for the IMP to align with the next higher IMP to the extent possible. In some large programs, the family of IMPs may even be cross-referenced. For example, a subcontractor IMP may have a separate field that reflects the next higher IMP item.
A subcontractor developing an aircraft avionics suite may have an event for PDR completed in their project IMP. That event in the lower tier IMP could be an Accomplishment Criteria in the next higher IMP. Alignment in this manner permits the family of IMPs to reflect the entire program from the government to subcontracted level.
Not aligning the IMP to customer Events most often occurs when an IMP is developed in isolation. To prevent this mistake, collect all relevant documents before initiating an IMP.
Not including all scope and not having detailed entrance and exit Criteria
Not including all scope is a common mistake in both IMP and IMS. This mistake can be avoided through the use of detailed Responsibility Assignment matrix (RAM). A RAM created as a pivot table that contains IMP Events, deliverables, OBS, WBS, and SOW will be an invaluable tool to ensure that all scope is collected in applicable artifacts. Sometimes when an IMP is generated by one or a few individuals it is possible to miss scope. Use large groups of program participants and stakeholders when breaking the Events into Significant Accomplishments and Accomplishment Criteria. The different perspective and experience levels will help to catch omissions.
Inadequate cross-referencing
Sometimes cross-referencing is being provided in the IMP, it is provided at too high a level. One example commonly observed is the SOW cross-reference. It is easy to roll the SOW up to level two when populating the cross-reference fields. Lack of granularity can lead to confusion and mudded responsibilities.
Not applying the IMP in subsequent artifact development
IMP is normally the second contractor artifact developed. It usually follows the WBS. The WBS is becoming easier to develop as the government contracts are looking for MIL-HDBK-881A compliant WBS structures so that they can compare data across systems. The IMS is often the next artifact to follow the IMP development. The close tie between the IMP and IMS has been discussed throughout this document. Other artifacts that should reflect the work defined in the IMP include the program-specific plans such as the SEMP, Test and Evaluation Master Plan (TEMP), Risk and Opportunity Management Plan (RMP or ROMP), and Configuration Management Plan (CMP).
Not using the IMP to educate and focus the program team
The benefits of the IMP imply its use in the execution of the program. The IMP beginning with the Government IMP establishes the expectations of program execution. Thus the IMP is intended for use in program execution. The IMP especially Accomplishment Criteria is often used to measure performance for award fee contracts. Where KPPs and TPMs are included as Accomplishment Criteria, the IMP can be used to measure the progress of the program toward system capabilities. The IMP is a good tool to educate new personnel coming on the program. It is a good tool to use to frame Accomplishments against the initial plan.
Sample Action Verbs
The DoD Integrated Master Plan and Integrated Master Schedule Preparation and Use Guide includes a sample action verb list and is shown below.
- Acquired - Procured and/or fabricated and available
- Analysis/Analyzed - The subject parameter(s) has been technically evaluated through equations, charts, simulations, prototype testing, reduced data, etc.
- Approved - The subject item, data, or document has been submitted to the Government and the Government has notified the contractor that it is acceptable
- Available - The subject item is in place/The subject process is operational/The subject data or document has been added to the Data Accession List
- Awarded - Contract /Subcontract is authorized to begin
- Completed - The item or action has been prepared or accomplished and is available for use and/or review
- Concurrence - The Government has expressed its agreement with the contractors proposed design, approach, or plan as documented in either formal correspondence or meeting minutes, presentations, etc.
- Conducted - Review or Meeting is held physically and minutes and action plans are generated/Test or demonstration is performed
- Deficiencies Corrected - New designs and/or procedures to correct documented deficiencies to requirements have been identified and incorporated into the baseline documentation. May include hardware fixes or retrofits.
- Defined - Identified, analyzed, and documented
- Delivered - Distributed or transferred to the Government (by DD 250, if applicable)
- Demonstrated - Shown to be acceptable by test and/or production/field application
- Developed - Created through analysis and documented
- Documented - Placed in a verifiable form (written/recorded/electronically captured)
- Drafted - An initial version (usually of a document) has been created, which will require updating to finalize
- Ended - Completed, over
- Established - the subject item has been set and documented
- Finalized - Last set of planned revisions has been made or final approval has been obtained
- Generated - Required information has been placed into written form.
- Identified - Made known and documented.
- Initiated - begun
- In-Place - At the physical location needed, ready to use or to perform.
- Obtained - received and documented
- Ordered - purchase order completed
- Met - Agreement reached that requirements have been satisfied.
- Prepared - information placed into written form.
- Provided - Given to in some traceable form (paper, briefing, electronically, etc.)
- Published - Distributed to team members, either formally (by CDRL), or placement on Data Accession List.
- Received - Shipped or delivered item is physically in possession of intended receiver
- Refined - Next level of detail has been added or updates made
- Reviewed - Presented for examination to determine the status and discuss issues.
- Submitted - Formally submitted to the Government.
- Trained - Type I training course completed.
- Updated - Revisions made to documents, metrics, and cost estimates to incorporate contractor and/or Government changes.
- Validated - Subject item, data or document has been tested for accuracy by the contractor.
- Written - Substantiated by analysis and/or test performed independently of builder/preparer.
Here's the Step-By-Step Guidance for Implementing the IMP/IMS
