Integrated Master Plan Development

Integrated Master Plan Development
INTEGRATED MASTER PLAN DEVELOPMENT Building the IMP as the basis of a credible IMS Niwot Ridge Consulting, LLC Copyright 2004, 2021
Introduction 2 ¨ This briefing focuses on the development of the Integrated Master Plan (IMP) with a hands-on exercise to define a Key Event List. The basic concepts of Integrated Product Development, Integrated Management Framework, and the Integrated Master Schedule (IMS) will also be introduced (IMS overview if time allows). ¨ Upon completion, the team will have: Developed an understanding of how an event driven plan is part of the Program technical solution; developed a Key Event List; developed an IMP elaboration for one or more Key Events; and discussed the IMP translation into an IMS.
Integrated Program Framework (IPF) 3 ¨ Used by the IPTs in the conduct of their efforts ¨ Product-oriented IPF concentrates effort on program products ¤ Links resources to products ¤ Links products to people Prod Tree SOW IPTs IMP IMS BOEs CWBS The IPF provides the upfront, integrated Planning Structure for program execution ¨ IPF products linked through use of single, CWBS-based, numbering system ¨ Creates a trackable, event-driven, program
Why Use an Integrated Approach? 4 ¨ Translates customer objectives, strategies, priorities and requirements and constraints into a contractually binding plan ¨ Evolves and reconciles the customer’s needs and contractor’s capabilities into a cost effective and verifiable contractual understanding ¨ Reduces uncertainties by forcing detailed planning and ownership of the plan up front ¨ Builds in flexibility to adjust the resources and schedule to manage the program risks and their uncertainties
Artifact Relationships 5 ¨ Every IPPD program element is focused on product delivery ¤ The Product Tree, CWBS, and IPT structure all look the same ¤ All Framework products are related through the CWBS Unambiguous traceability between all artifacts is the basis of success Product Tree Describes WHAT IPT Structure Describes WHO CWBS “The Cornerstone” • Structure directly tied to CWBS • Primarily used to scope assigned tasks CSOW • Tied to IMP events • Logic Network & Durations • Contains all work IMS • Program Success Events • PEs, SAs, and ACs • PEs may cross CWBSEs • Structure tied to CWBS • Includes Process Narratives IMP Describes WHEN Describes WHAT & HOW MUCH Describes WHAT & HOW
Artifact Traceability 6
IMP & IMS are the heart of the Integrated Management Framework 7 Requirements Contractor Work Breakdown Structure (CWBS) CWBS Dictionary Integrated Master Plan (IMP) System & Segment Specs and Statement of Work (SOW)/Statement of Objectives (SOO) Event-Driven Plan Providing Roadmap for Entire Program Determined by Execution • Tailored to and Outlines Entire Program/Products • Provides Single Numbering System for Entire Program Integrated Master Schedule (IMS) • Expands on IMP • Provides Details and Timing for all work Technical Performance Measures (TPMs) Earned Value Management System Links Cost to IMS Monitors Key Performance Characteristics Placed On Contract Used to Track Performance Used to Report Performance and Determine Award Fee • We Generate the Dictionary • Follows IPT/CWBS Structure • Cross Referenced to and encompasses all SOW, CDRL Evaluations/CPARs
IMP/IMS Team Interfaces 8 Manage Process, Volume Outlines Review & Integrate Products Program/ Proposal Management IMP/IMS Section Leads, Authors, Planners, Schedulers IPT Members, including Customer Gather, document, integrate data for each IPT • Program Arch. • Process IMP • Product IMP • IMS IMP/IMS Volume Leader, Planning Leadership Team • Provide existing data • Generate new data • Resolve discrepancies • Flow down strategy • Review evolving products
6-Step Process Summary 9 1 2 3 4 5 6 Understand The Product Develop The Product Structure Form Integrated Product Teams Create The Integrated Master Plan Create The Integrated Master Schedule Create The Basis Of Estimate § Identify Customers § Compile Customer Requirements: (SOO, CDRLs & Applicable Docs) § Document Ground Rules & Assumptions § Clarify Product Requirements § Create Product Tree from SOO & Processes § Create Top Level CWBS Structure § Assess Structure for workability & completeness § Write CWBS Dictionary § Develop top- level SOW task statements § Define Teams (Pgrm Mgmt, Segments, SEIT, etc) § Form Teams (Leaders & Key Resources) § IPTs validate and extend SOW, CWBS & CWBS Dictionary § Mgmt Team Selects Key Events & Decision Pts § Write Event Descriptions § Develop SAs and ACs § Sequence SAs into a Process § Integrate Processes § Write IMP Process Narratives § Define High Level Tasks § Decompose Tasks § Define Logic & Dependencies § Apply Constraints § Establish Durations § Add Resources § Assess Critical Paths § Perform Schedule Risk Assessment § Finalize / Approve § Receive flow- down from DTC/PTW § Determine appropriate method of quoting § Estimate Hours § Review/adjust to match DTC/PTW allocations
PM Team Responsibilities 10 1 2 3 4 5 6 Understand The Product Develop The Product Structure Form Integrated Product Teams Create The Integrated Master Plan Create The Integrated Master Schedule Create The Basis Of Estimate § Identify Customers § Compile Customer Requirements: (SOO, CDRLs & Applicable Docs) § Document Ground Rules & Assumptions § Clarify Product Requirements § Create Product Tree from SOO & Processes § Create Top Level CWBS Structure § Assess Structure for workability & completeness § Write CWBS Dictionary § Develop top- level SOW task statements § Define Teams (Pgrm Mgmt, Segments, SEIT, etc) § Form Teams (Leaders & Key Resources) § IPTs validate and extend SOW, CWBS & CWBS Dictionary § Mgmt Team Selects Key Events & Decision Pts § Write Event Descriptions § Develop SAs and ACs § Sequence SAs into a Process § Integrate Processes § Write IMP Process Narratives § Define High Level Tasks § Decompose Tasks § Define Logic & Dependencies § Apply Constraints § Establish Durations § Add Resources § Assess Critical Paths § Perform Schedule Risk Assessment § Finalize / Approve § Receive flow- down from DTC/PTW § Determine appropriate method of quoting § Estimate Hours § Review/adjust to match DTC/PTW allocations
IPT Lead Responsibilities 11 1 2 3 4 5 6 Understand The Product Develop The Product Structure Form Integrated Product Teams Create The Integrated Master Plan Create The Integrated Master Schedule Create The Basis Of Estimate § Identify Customers § Compile Customer Requirements: (SOO, CDRLs & Applicable Docs) § Document Ground Rules & Assumptions § Clarify Product Requirements § Create Product Tree from SOO & Processes § Create Top Level CWBS Structure § Assess Structure for workability & completeness § Write CWBS Dictionary § Develop top- level SOW task statements § Define Teams (Pgrm Mgmt, Segments, SEIT, etc) § Form Teams (Leaders & Key Resources) § IPTs validate and extend SOW, CWBS & CWBS Dictionary § Mgmt Team Selects Key Events & Decision Pts § Write Event Descriptions § Develop SAs and ACs § Sequence SAs into a Process § Integrate Processes § Write IMP Process Narratives § Define High Level Tasks § Decompose Tasks § Define Logic & Dependencies § Apply Constraints § Establish Durations § Add Resources § Assess Critical Paths § Perform Schedule Risk Assessment § Finalize / Approve § Receive flow- down from DTC/PTW § Determine appropriate method of quoting § Estimate Hours § Review/adjust to match DTC/PTW allocations
Program Planning and Controls 12 1 2 3 4 5 6 Understand The Product Develop The Product Structure Form Integrated Product Teams Create The Integrated Master Plan Create The Integrated Master Schedule Create The Basis Of Estimate § Identify Customers § Compile Customer Requirements: (SOO, CDRLs & Applicable Docs) § Document Ground Rules & Assumptions § Clarify Product Requirements § Create Product Tree from SOO & Processes § Create Top Level CWBS Structure § Assess Structure for workability & completeness § Write CWBS Dictionary § Develop top- level SOW task statements § Define Teams (Pgrm Mgmt, Segments, SEIT, etc) § Form Teams (Leaders & Key Resources) § IPTs validate and extend SOW, CWBS & CWBS Dictionary § Mgmt Team Selects Key Events & Decision Pts § Write Event Descriptions § Develop SAs and ACs § Sequence SAs into a Process § Integrate Processes § Write IMP Process Narratives § Define High Level Tasks § Decompose Tasks § Define Logic & Dependencies § Apply Constraints § Establish Durations § Add Resources § Assess Critical Paths § Perform Schedule Risk Assessment § Finalize / Approve § Receive flow- down from DTC/PTW § Determine appropriate method of quoting § Estimate Hours § Review/adjust to match DTC/PTW allocations
PMT Inputs for IMP/IMS Development 13 ¨ Defining the framework for the program is key to establishing the integrated plan and schedule ¤ Review proposal documentation to define the work scope at a high level n RFP n Statement of Objectives (SOO) / Statement of Work (SOW)/Specifications and/or n CDRL list n CWBS dictionary n Proposal Strategy ¤ Essential that this effort comprehensively defines all activities
Project/Program (cont.) 14 ¨ Once all of the discrete work scope components are identified, categorize them in multiple dimensions ¤ Who will be responsible for performing this? ¤ What are the constituent components of this ? ¤ When is this required to be completed ? ¤ Where will this be performed ? ¤ Why does this need to be done ? ¤ How does this support end of contract sign-off ?
The Product Tree 16 The Product Tree is the basis of the entire program ¨ Established based on understanding of program requirements and Government RFP guidance ¨ Identifies and decomposes essential program products ¨ Provides the basis of the CWBS Will NOT be placed on contract Subsystem A Subsystem B Subsystem C XYZ System Product A1 Product A2 Product A3
The Work Breakdown Structure (WBS) 18 ¨ Establishes the primary product and work partitioning ¨ Outlines the products and services to be provided ¨ Based on the Product Tree – CWBS adds functional “overhead” and lower-level details ¨ Level 3 is usually adequate for most programs ¨ Decompose the structure until all risks are visible The WBS is the key planning document for the definition and organization of all work activities WILL be placed on contract
The CWBS defines the logic of the program 19 ¨ ` Subsystem B Subsystem C XYZ System Product A1 Product A2 Product A3 SEIT PM 0000 1000 2000 3000 4000 5000 3100 3200 3300 Subsystem A Subsystem A Subsystem B Subsystem C XYZ System Product A1 Product A2 Product A3 Subsystem A Subsystem B Subsystem C XYZ System Product A1 Product A2 Product A3
The Statement of Work (SOW) 20 ¨ Identifies specific work to be accomplished and incorporated into the contract. The SOW is the contractor's mission statement. ¨ The work to be performed is described in terms of "what" is the required output rather than either "how" the work is accomplished or the number of hours provided. ¨ SOWs must be individually tailored to consider the period of performance, deliverable items, if any, and the desired degree of performance flexibility. ¨ Any government requirements beyond the SOW may expose the government to claims and increased costs. Subsystem B Subsystem C XYZ System Product A1 Product A2 Product A3 SEIT PM 0000 1000 2000 3000 4000 5000 3100 3200 3300 Subsystem A Subsystem B Subsystem C XYZ System Product A1 Product A2 Product A3 SEIT PM 0000 1000 2000 3000 4000 5000 3100 3200 3300 Subsystem A 0000 Satellite Control Network Khfjda djud sdaj jajsd sa sai saii ssaoioiuis sus a I sa idsj m ijdskc kjodsjk hojc kjs kid kikijc jhcn jnh kjsn jhc knsc n njhcxzknv hknca b mjb Khfjda djud sdaj jajsd sa sai saii ssaoioiuis sus a I sa idsj m ijdskc kjodsjk hojc kjs kid kikijc jhcn jnh kjsn jhc knsc n njhcxzknv hknca b mjb Khfjda djud sdaj jajsd sa sai saii ssaoioiuis sus a I sa idsj m ijdskc kjodsjk hojc kjs kid kikijc jhcn jnh kjsn jhc knsc n 1000 Program Management Khfjda djud sdaj jajsd sa sai saii ssaoioiuis sus a I sa idsj m ijdskc kjodsjk hojc kjs kid kikijc jhcn jnh kjsn jhc knsc n njhcxzknv hknca b mjb Khfjda djud sdaj jajsd sa sai saii ssaoioiuis sus a I sa idsj m ijdskc kjodsjk hojc kjs kid kikijc jhcn jnh kjsn jhc knsc n njhcxzknv hknca b mjb Khfjda djud sdaj jajsd sa sai saii ssaoioiuis sus a I sa idsj m ijdskc kjodsjk hojc kjs kid kikijc jhcn jnh kjsn jhc knsc n 2000 System Engineering, Integration & Test Khfjda djud sdaj jajsd sa sai saii ssaoioiuis sus a I sa idsj m ijdskc kjodsjk hojc kjs kid kikijc jhcn jnh kjsn jhc knsc n njhcxzknv hknca b mjb Khfjda djud sdaj jajsd sa sai saii ssaoioiuis sus a I sa idsj m ijdskc kjodsjk hojc kjs kid kikijc jhcn jnh kjsn jhc knsc n njhcxzknv hknca b mjb Khfjda djud sdaj jajsd sa sai saii ssaoioiuis sus a I sa idsj m ijdskc kjodsjk hojc kjs kid kikijc jhcn jnh kjsn jhc knsc n 3000 Satellite C&C Subsystem Khfjda djud sdaj jajsd sa sai saii ssaoioiuis sus a I sa idsj m ijdskc kjodsjk hojc kjs kid kikijc jhcn jnh kjsn jhc knsc n njhcxzknv hknca b mjb Khfjda djud sdaj jajsd sa sai saii ssaoioiuis sus a I sa idsj m ijdskc kjodsjk hojc kjs kid kikijc jhcn jnh kjsn jhc knsc n njhcxzknv hknca b mjb Khfjda djud sdaj jajsd sa sai saii ssaoioiuis sus a I sa idsj m ijdskc kjodsjk hojc kjs kid kikijc jhcn jnh kjsn jhc knsc n Statement of Work
The Integrated Product Teams (IPTs) 22 CWBS defines the logic structure of the program ¨ Provides summary points for assessing risk and technical progress and for measuring cost and schedule performance ¨ Don’t allow existing organization structure or technical design influence structure – Stick with Logic ¨ Build the CWBS to accommodate growth easily – put the fixed functional “overhead” at front of structure and products at end ¨ Strive for a balanced CWBS – consistent depth and content – structure reuse Subsystem B IPT Subsystem C IPT PMT Product A1 IPT Product A2 Product A3 SEIT 1000 2000 3000 4000 5000 3100 3200 3300 Subsystem A IPT Subsystem B Subsystem C XYZ System Product A1 Product A2 Product A3 SEIT PM 0000 1000 2000 3000 4000 5000 3100 3200 3300 Subsystem A Subsystem B Subsystem C XYZ System Product A1 Product A2 Product A3 SEIT PM 0000 1000 2000 3000 4000 5000 3100 3200 3300 Subsystem A
Notable Quote on IPTs 23 ¨ We trained hard, but it seemed that every time we were beginning to form up into teams, we would be reorganized. I was to learn later in life that we tend to meet any new situation by reorganizing; and a wonderful method it can be for creating the illusion of progress while producing confusion, inefficiency and demoralization ¤ Petronius Arbiter (210 B.C.)
The Integrated Master Plan (IMP) 25 Provides the overarching framework against which all work is accomplished ¨ Reflects an Event/Accomplishment/Criteria hierarchical structure – a format that facilitates measuring program accomplishments. ¨ Cost, schedule (specific dates), and non-essential tasks are not included in this plan. ¨ Functional and lifecycle inputs are required to integrate the program products and associated processes. ¨ This event-driven approach allows the program elements to be integrated properly and that the management process is based on significant events in the acquisition life cycle, and not on arbitrary calendar events. WILL be placed on contract
What is an IMP? 26 ¨ The IMP is an event-driven plan which consists of Events, Significant Accomplishments and Accomplishment Criteria, and process definitions (narratives) which encompass the scope of your program ¨ The IMP defines WHAT, WHO and HOW - but not WHEN. ¤ IMP Table ¤ IMP Narratives (process definitions) ¤ Verb Definitions ¨ The IMP may become contractually binding upon contract award.
IMP Attributes 27 ¨ The IMP is the program’s Top Level Plan that encompasses the Total Program Scope
An IMP is: 28 ¨ NOT a replacement for the WBS ¨ NOT a new framework for cost and schedule control ¨ NOT necessarily inclusive of all work on a program ¤ An IMP contains only key elements that have been selected to measure program progress ¤ Be sensitive to customer expectations ¨ NOT a complete framework for detail schedules ¤ Though a relationship from the IMP to the detail schedules (IMS) is identified, the IMP does not contain all program work elements ¨ NOT a schedule ¤ An IMP contains no schedule (date) information
The Integrated Master Plan (IMP) Table 29 The IMP Table is the hierarchical event-based plan for accomplishing the “measurable” objectives of the program • Identifies key program events, significant accomplishments (SAs), and accomplishment criteria (ACs) WILL be placed on contract Detailed Tasks Accomplishment Criteria Significant Accomplishments Event State of Process Accomplishment Criteria – Definitive measures substantiating the maturity level of the SA; Completion of specific work that ensures closure of a specified SA State of Program Events – Major program milestones or assessment points (PDR, CDR, launch, etc.) substantiating system maturity (initiation or conclusion) Significant Accomplishments – Specified result, substantiating an Event, that indicates design/production maturity (or progress) level for each product or process; Generally a discrete step in the progress of the planned development State of Product
IMP Table Example 30 Significant Accomplishment Accomplishment Criteria Event C C01 SP FY2004 Increment 1 Assessment – Completed 2 C0101 FY2004 SoS Performance Allocation Report – Submitted 2.2.1.7 B004 C0102 FY2004 SoS Oper. Reengineering Legacy Baseline Report Update – Submitted 2.2.1.8 B004 C0103 Systems Technology Insertion Report – Submitted 2.3.2.2 B004 C0104 Modeling & Simulation Report – Submitted 2.4.1.2 B004 C02 Cross-Program Integration Planning – Completed 2.5 C0201 Cross-Program Integration Plan Update – Submitted 2.5.1.2 B007 C0202 Cross-Program Integration Schedule Update – Submitted 2.5.2.1 B008 C0203 Cross-Program Integ. Readiness Review Procedures and Report – Submitted 2.5.3.2 B004 C03 Demonstration Programs Interfaces Assessment – Complete 2 C0301 Modernization Interface Control Document (ICD) Assessment – Completed 2.6.1.1 B004 C0302 Modernization API Assessment – Completed 2.6.1.2 B004 The Cross-Program Integration Review (CPIR) prioritizes, aligns, and integrates standalone program increments to provide SoS integrated capabilities. The CPIR details and maps the capabilities for the three nearest-term increments: x, x+1, and x+2. The CPIR will be updated prior to the start of a new increment. It will also be updated as required to capture necessary changes due to program dynamics. WBS # CDRL # IMP # Cross-Program Integration Review (CPIR) – Conducted Hierarchical Numbering Format and Outline-style indentation
IMP Dictionary Example 31 Sample Event Descriptions Event Code Full Title and Acronym Description C Preliminary Design Review (PDR) Phase The PDR Phase is the interval of the program in which the requirements are defined and allocated to the lowest testable entity in the system architecture. This phase is to ensure that a selected preliminary design meets all of the applicable requirements with acceptable margin and risk. The correct design option, identified interfaces and verification methods have been satisfactorily specified. It starts with the significant accomplishment of the System-level PDR in which system requirements are finalized and preliminary allocations made to the next level of the hierarchy. All system-level plans beyond those required at IBR also need to be finalized. Successful completion of the PDR Phase concludes with completion of a significant accomplishment related to the lowest testable unit. When configuration items are being procured to existing specifications (COTS and standard products) they may be addressed at the highest level of their integration into a deliverable product and need not have a lower level PDR. Successful completion of the PDR Phase results in establishment of an allocated baseline, the System-level and Segment PDRs have been conducted with action items closed or documented in a plan of closure, and Government approval of associated CDRL deliverables. Government approval for proceeding with detail design has authorized. E Critical Design Review (CDR) Phase The CDR Phase is the interval of the program in which the design compliant with the requirements is defined. This phase is to ensure that a detailed design, including internal and external interfaces, meets all of the applicable requirements with acceptable margin and risk. This phase begins with lowest level configuration item (CI) CDR that is being modified or designed for MUOS and concludes with the System-level CDR. Successful completion of the CDR Phase results in establishing a product baseline, 90% completion of manufacturing drawings, establishing the basis for proceeding with manufacturing, integration, assembly, and verification, the System-level and Segment PDRs have been conducted with action items closed or documented in a plan of closure, and Government approval of associated CDRL deliverables.
IMP Dictionary Verb Definitions 32 Sample IMP Terms Allocated: Segment requirement is flowed down from System Specification. Released: Approved item for delivery to intended customer or supplier; all internal distribution and sign-offs completed. An electronic version is made accessible on IDE or other media as required. Completed: The subject item, data document, or process is prepared or concluded, and reviewed and accepted by the responsible IPT team. Supporting documentation is available through IDE or other media. Reviewed: The subject item, data, document, or process is prepared or concluded, and documented for completion. Supporting documentation is available through IDE or other media. Conducted: The subject meeting or review has been held with all required program participants. The presentation charts or minutes are available through IDE along with assigned action items. Updated: The subject process, data, or document has been reevaluated using later information, and adjustments have been incorporated Defined: The subject configuration items, data, or document was submitted to customer. Validated: Requirements are validated, received contractor approvals, were distributed, and are available through IDE or other media. Established: The subject item is created and set into place in a manner consistent with its intended use after review and acceptance by the IPT team Verified: Requirements are verified or processed in accordance with established practice.
What Makes a Good ... ? 33 ¨ Event? ¤ Events represent the conclusion of an interval of major program activity. IMP events represent key decision transition points between major activities distributed over the contract period
What Makes a Good Program Event ? 34 Some Criteria For Establishing Program / Product Events: ¨ Customer Provided Events. ¨ Key Decisions Needed. [e.g., down-select of competitive developments; choosing a key implementation, such as ion thrusters vs. liquid propulsion] ¨ Risk Mitigation Event. [e.g., completion of a critical payload qualification].
Lifecycle Candidate Events 35 Incr 2 System Design/Development Incr 1 System Design/Development System INCREMENTAL System Requirements Incr 1 System Integration Incr 2 System Integration System Qualification Test EVOLUTIONARY 1st Acquisition Increment Acquisition 1st Launch PHASE A PHASE B PHASE C 1st System Increment SRR SDR System Design 2nd System Increment PDR CDR PDR CDR TRR TRR TRR Incr 2 System Design/Development Incr 1 System Design/Development System System INCREMENTAL System Requirements Incr 1 System Integration Incr 2 System Integration System Qualification Test EVOLUTIONARY 1st Acquisition Increment Acquisition Acquisition 1st Launch PHASE A PHASE B PHASE C 1st System Increment 1st System Increment SRR SRR SRR SDR SDR System Design 2nd System Increment 2nd System Increment PDR PDR CDR CDR PDR PDR CDR CDR TRR TRR TRR TRR TRR TRR SDR TRR TRR TRR PDR CDR PDR CDR
Event Examples 36 Technical And Management Review Post Award Conference (PAC) System Requirements Review (SRR) Preliminary Design Review (PDR) Critical Design Review (CDR) Functional Configuration Audit (FCA) Physical Configuration Audit (PCA) Development Events Subsystem Fabrication Review Subsystem Integration Review System Integration Complete Design Readiness Review Demonstration And Verification Events Test Readiness Review (TRR) First Flight Readiness Review (FFRR) First Flight Complete DT&E / OT&E Complete Key Decisions Points When Progress Needs To Be Measured, Demonstrated, Or Reviewed Program Status Reviews (PSR) Progress Review Number X Product In Progress Review (IPR) Low Rate Initial Production (LRIP) Decision Full Rate Production Decision Key Production / Operational Event Production Readiness Review (PRR) Low Rate Initial Production (LRIP) Complete Production Lot X Complete Site Activation Readiness Review Site Activation Initial Operational Capability (IOC)
A Good Significant Accomplishment 37 ¨ One working level IPT can manage it ¨ Shows completion/result of discrete steps in the development process ¨ Indicates maturity of the product ¨ It’s “significant” for measuring program event status ¨ It’s relevant and logically linked to the right event (just because it occurs during the time-frame for event A doesn’t mean it’s logically linked to A; it may support event C) ¨ Uses consistent language, style, format ¤ Segment build 4 detailed design completed ¤ Analysis of structural integrity completed ¤ Structural integrity verified
Significant Accomplishments (SA) 38 ¨ Significant Accomplishments are NOT a listing of “things” coincident with the system event ¨ SA’s represent a series of physical accomplishments leading to the Program Event ¨ Program Event = CDR completed ¤ SA # 1 = CDR meeting conducted ¤ SA # 2 = CDR action item work-off plan established ¤ SA # 3 = 85% drawings completed ¤ SA # 4 = CDR CDRLs delivered ¤ SA # 5 = Development environment operational ¤ SA # 6 = Critical methods analyses completed ¤ SA # 7 = RVTM approved
What Makes a Good ... ? 39 ¨ Criteria? ¤ Measurable and provides objective, explicit proof of completion, closure ¤ Defines conditions for closing the significant accomplishment ¤ Answers “how do I know when an accomplishment has been completed?”
A Bad Significant Accomplishment 40 ¨ Not significant ¤ Too small to significantly contribute to successful event completion ¤ Would lead to trivial tasks (e.g., 1 day duration) ¨ Ambiguous ¨ Wrong verb ¤ Uses a verb that’s not on the list (Dictionary) ¤ Uses a listed verb incorrectly ¤ Doesn’t have a verb at all ¨ Not measurable ¤ Can’t tell when we’re done ¨ Too Many
IMP Example 41 SDD IMP Detailed Events Event C: CDR Definition Completion of the last of the set of Critical Design Reviews (CDR) which start at the HWCI, CSCI, or Mega-Executable level and conclude at the System Level. Each review ensures 1) the detail design of the subject of the review is completed and satisfies allocated requirements and interfaces, 2) any risk assessment/reduction/avoidance efforts, studies, and prototypes are completed and 3) the subject of the review is ready to proceed into production Significant Accomplish- ments Accomplishment Criteria Acct No. WBS C100 System Critical Design Review Completed Final Program Plans Released System Specification incorporating all SCN Released Program External and Intersegment ICDs incorporating all Changes Released Design/Verification Critical Analyses Completed Final System Design Documented Final System Test Bed Design Documented System CDR Action Item Closure Plans Complete Security Targets Completed C1000101 C1000102 C1000103 C1000104 C1000105 C1000106 C1000107 C1000108 3100 3100 3100 3100 3100 6100 3100 3100 1180 1500 2700
Step 4 a & b Select & Define Key Events 43 ¨ Start with internal guidance, RFP, and proposed strategy to define initial events ¤ Key program measurement points ¤ Communicate the implementation strategy ¨ The program’s key planning members (PM, SE Lead, IPT leads, Planner) meet to define the events ¤ A top-down process that begins with defining each event ¤ Build the “verb table”
Step 4 c & d Define & Sequence SAs & ACs 44 ¨ Continue the top-down process: ¤ Identify the SAs that are the appropriate measurement points for the event ¤ Identify the specific ACs that are the success criteria for the SAs ¤ Identify any interrelationships and continue to identify any additional SAs or ACs that are needed to support them ¨ Validate with proposal leads ¨ Establish the IMP as the proposal baseline
Product Development Observations 45 ¨ Systems Engineering typically has the bulk of products upfront in a development program, then back off a little when design activities are started in earnest ¨ Design IPT products are typically in a support role up front, then expand as the design products are developed and delivered ¨ Program Management have some products assigned, but can have LOE activities as well ¤ IMP/IMS tries to avoid LOE, but sometimes it is warranted, e.g. BR
Creating an IMP Event Table 46 ¨ Once you have a collective set of products (e.g., CDRLs), responsibilities and interdependencies ¤ Capture data for use in generating appropriate Significant Accomplishments for the IMP ¤ Some stickies may be Accomplishment Criteria or lower level tasks ¤ Distribute to responsible parties to review and approve ¤ Configuration-manage the IMP when the program believes it is at a ~90% level.
Step 4e & f The IMP Narratives 48 The “IMP Narratives” is the IMP section that captures the program’s defined processes, and references key plans and procedures ¨ A concise description of the key functional processes/procedures, how they relate to the products, and an overview of the efforts required to implement them ¨ Provides a linkage between the functions involved in product development; Overview of the process (flow diagrams) and how it will be implemented ¨ Documents tailoring of standard processes and tools ¨ Description of any metrics that will be used to measure the process ¨ Reference to governing and additional program documentation ¨ Should be reviewed and approved by Functional stakeholders WILL be placed on contract
What Is In an IMP Narrative? 49 ¨ Tells the objective of the process ¨ Provides the governing documents, compliance and reference ¨ Explains the approach ¤ Portrays the key activities of the approach ¤ Illustrates the company processes tailored for the specific project Inputs Activity 3 Activity 5 Activity 4 Tools Activity 1 Activity 2 Outputs Metrics
Step 4e Integrate the Processes 50 System Build Process Program Management Process Risk Management Process Software Development, Modification, & Reuse Process Software Item XXX IPT Process Software Item YYY IPT Process Software Item ZZZ IPT Process System Integration and Ground Verification Process Flight Test Planning, Conduct, Analysis Process Support System Development Process Hardware Development/ Selection Process Know how your process fits in with the whole System Engineering Process
IMP Narrative Processes & Examples ¨ Select the processes that are going to have process narratives included ¤ Customer mandated processes (e.g. Substitute IMP Narrative with Systems Engineering Management Plan) ¤ Processes selected for competitive advantage / ghosting ¤ LOEs (e.g. Program Management Plan, Configuration and Data Management Plan) ¨ Examples: ¤ Affordability (LCC, DTUPC, CAIV) ¤ Cost/schedule control ¤ Electronic data interchange ¤ HW/SW configuration management ¤ Process improvement ¤ Producibility & manufacturing planning ¤ Product assurance ¤ Program management ¤ Risk management ¤ Subcontractor management ¤ System engineering, integration & test (SEIT) ¤ System, HW, SW, support system development ¤ Configuration and Data Management 51 WILL be placed on contract
Step 4e Typical Process IMP Narrative Outline 52 ¨ X.1 Objective ¨ X.2 Governing Documentation ¤ Commercial standards, e.g. ISO-9000 ¤ LM standards — may be tailored to (Your) Program ¤ Government standards ¨ X.3 Approach ¤ Process flow diagram is the key artwork ¤ Include: n Responsible IPT n Products of the process (CDRLs, plans, reports, HW/SW, …) and references to additional information that may be included with proposal (PM plan,…) n Unique tools or techniques n Metrics n Interaction with other IPTs and/or other processes ¤ Point out tailoring, streamlining, lessons learned features ¤ Address risk areas & point out process refinements to mitigate risk
IMP Narratives 53 From IMP Table Proposal Rep. Authors • Generate Module Specifications and Story Maps • Generate Annotated Mockups (One Graphic Will Be Your Detailed Process Flow OR a Summary Process Flow) • Generate Draft(s) = Review • Generate IMP Narrative Outline • Assign Authors IMP Narratives are Generated Like Other Proposal Narratives
Integrated Product Development Process 54 Earned Value Management System Performance Performance IMF CONOPS/ product tree Customer Reqmts WBS IMP Process Narratives Risks ORG IPTs Metrics • Performance • Schedule • Cost Events (E) Integrated Master Schedule Significant Accomplishments (SA) Accomplishment Criteria (AC) Program Standard Processes (SPP) Cost Account Work Package Work Package Tasks Analysis/ Management Review CWBS EVMS
What the IMP/IMS Team Must Do ¨ Embrace the task - it is important ! ¨ Review all processes and standards for conflict elimination, tailoring, streamlining, value added ¨ Focus on discriminators, high risk items, answering the mail ¨ Be creative — give your best in the initial proposal ¨ Seek out lessons learned we can apply ¨ Work as a team and communicate
IPPD & Event Based Planning make managing the Program easier ¨ Goals and priorities are clear — do the work that supports the upcoming accomplishments first ¤ Earned value (we get paid) based on completing schedule tasks IAW IMP criteria ¤ The network logic disallows starting work before it’s predecessors are done, makes impact assessment easy ¨ Support program streamlining: ¤ If an effort doesn’t support completing an accomplishment leading to an event, why is it in the program? (Shouldn’t even get into the plan) ¤ We’ve already detailed/tailored/streamlined the processes in our process IMP narratives
Program Directive documents the IMP/IMS development process 57 ¨ IMP/IMS development ground rules and assumptions ¨ IMP/IMS outline, development process and schedule ¨ Verb definitions ¨ Templates ¨ Numbering scheme ¨ IMP/IMS roles and responsibilities ¤ PM ¤ IPTs ¤ Functional organizations ¤ Subcontractors ¨ Author guidance for charging Contract or B&P
What We Must Look For in an IMP 58 ¨ Address the following items: ¤ Risk ¤ Trades ¤ Requirements ¤ Design ¤ LCC ¤ Software ¤ H/W and S/W Integration ¤ Test ¤ Manufacturing and deployment plans ¤ Transitions Plans ¤ Producibility Plans ¨ Have all IPTs participate when they should
INTEGRATED MASTER SCHEDULE (IMS) OVERVIEW
IMS Objectives ¨ Maintain consistency with the IMP ¨ Illustrate the interrelationships among events, accomplishments, criteria and tasks ¨ Illustrate the start and completion dates for each event, accomplishment, criteria and task ¨ Indicate the duration of each event, accomplishment, criteria and task ¨ Provides a critical path ¨ Provide the ability to sort schedules multiple ways (e.g., by event, by IPT) ¨ Provide schedule updates on a regular basis ¨ System (EVMS) ¨ Provide an indication of all completed actions ¨ Indicate schedule slips with original and reschedule dates ¨ Provide electronic access to the current master program schedule for contractor, government, and support contractor personnel ¨ Provide the capability for the government, contractor, or support contractors to perform “what if” schedule exercises without modifying the master program schedule ¨ Maintain consistency with the work package definitions and the Earned Value Management 60
CWBS, IMP & IMS are the core of the Planning Process IMP Number IMP Level Event/Accomplishments/Criteria CWBS Continued on Management Cross Reference Matrix (V2 App C) IMP Spacecraft Bus integration complete • Install EP subsystem • Install C&DH components • Install communications subsystem • Install GNC components • • WBS 1.2.1 CWBS 21000000 Sat AI&T WBS 1.4 CWBS 40000000 IDPS WBS 1.3 CWBS 30000000 C3S WBS 1.1 CWBS 10000000 Launch Segment WBS 1.2.2 CWBS 22000000 Spacecraft WBS 1.0 CWBS 00000000 NPOESS System WBS 1.2 CWBS 20000000 Space Segment WBS 1.2.3 CWBS 23000000 Payload C2AI0500 C2AI0501 C2AI0600 C2AI0601 A C A C 22200000 22200000 22200000 22200000 Spacecraft bus assembly and integration complete (Phase 1) Spacecraft bus assembly complete Satellite C2 (Vehicle 1) integration and test complete Spacecraft bus integration complete C T T T T Task Description CY 06 Level IMS Program structure for accountability Plan to achieve product delivery mission success Time phased task for SSPR management
Development of an IMS Requires Upfront Planning, Lots of Planning 62 Thinking and Deciding must happen before detailed planning and scheduling ¨ You must know what you’re trying to achieve ¤ Contract requirements, statement of work ¨ A Work Breakdown Structure (WBS) is required ¤ Allows work to be aligned along product lines ¤ Allows cost to be issued and collected along product lines ¨ Organizational decisions must be made ¨ Work assignments must be clearly made ¨ Hardware and software decisions must be made ¨ Make/Buy decisions are required ¨ Tooling decisions are required ¨ Work flow (dependencies) and processes are required ¨ Task durations are required
The IMP as a Framework for the IMS 63 ¨ Product IMP elements (Events, Accomplishments and Criteria) are embedded within the IMS ¤ Criteria are logically linked to Accomplishments ¤ Accomplishments are logically linked to Events ¤ Each Criteria is preceded by networked schedule tasks n Networked schedule task represent the work plan for a program ¨ The networking function of the scheduling software and the attributes associated with tasks provide dates for IMP elements and define the program schedule ¨ Tasks (unless directed otherwise) address the finite, measurable, discrete steps necessary to produce a product, whether that product is hardware, software or paper ¤ This is what’s referred to as “discrete scope” ¤ “Level-of-effort”, what is accomplished on a routine basis whether discrete scope is accomplished or not, is normally addressed within IMP process narratives
The IMP is Embedded in the IMS 64 Event Accomplishment Tasks FY 2004 Oct Nov Dec Jan Feb Mar Apr May Tasks Criteria Criteria
Activity (Task) 65 ¨ Represents work that consumes resources including time ¨ Has a relationship with other activities that may be presented in a network ¤ Start to Start ¤ Finish to Start ¤ Finish to Finish ¨ Has some uncertainty in the time to complete ¤ All durations are random variables ¤ Use Monte Carlo Simulation to assess the confidence in completing “on or before” a specific date Earliest Finish Most Likely Latest Finish
Definitions of Network Terms 66 ¨ Task relationships ¤ A logical connection between two activities relating start and completion time frames n Finish-to-start most common, others are Start-to-start and Finish-to-finish n Least common is Start-to-finish ¨ Predecessor task ¤ A task which logically precedes another task ¨ Successor task ¤ A task which logically follows another task
More Definitions of Network Terms 67 ¨ Critical path ¤ A contiguous set of activities in a schedule logic path having the longest duration and least amount of total float, thus defining the minimum project duration ¤ Also the path with the least amount of total float to any milestone or activity ¨ Free Float ¤ Amount of time by which an activity can be delayed without delaying any other task in the network ¨ Total float ¤ Amount of time by which an activity can be delayed on a critical path without delaying the end of the path (whether it’s the project, an activity or a milestone) ¨ What-if analysis ¤ Recalculation of the activity network after temporary insertion of hypothetical network data (revised logic, work schedules, task delays or improvement, etc.) ¨ Time now (data date) ¤ Effective date of status information
What is Float and Critical Path? 68 ¨ The Critical Path is formed by task A, C and D (minimum time to complete this group of tasks). ¨ Task B has float and is not critical. Month 0 Month 3 Month 2 Month 1 Month 4 Task A Task D Task C Task B float Early dates Task B Late dates Task B 1 Month 2 Months 1/2 Month 1 Month FS FS FS FS Task C Task A Task D
IMS Lessons Learned 69 ¨ Need a good scheduler who is an expert in the scheduling tool ¤ Many business and technical people are experienced with Project – work closely with them ¨ Get the right level for task durations ¤ A one day task is not the right level for a three year program, but may be good for a two month schedule ¨ Have principle dependencies between tasks (try to minimize) ¤ Interdependencies between groups push integrated schedules to do unwanted things ¨ Avoid event to event tasks ¤ Looks like LOE and not a well thought out plan ¨ Allow enough time for this effort ¨ Understand your critical path, PM will ask about it

Check these out next

Integrated Master Plan Development

Recommandé

Contenu connexe

Présentations pour vous(20)

Similaire à Integrated Master Plan Development(20)

Plus de Glen Alleman(20)

Dernier(20)

Integrated Master Plan Development