The Integrated Master Plan (IMP) and Integrated Master Schedule( (IMS) provide a strategy for the incremental delivery of program outcomes through increasing maturity assessments with Measures of Effectiveness, Measures of Performance, Technical Performance Measures, and Key Performance Parameters.
These assessment assure the needed capabilities of the project are met at each assessment point to confirm physical percent complete as planned in the Integrated Master Plan
Building the Integrated Master Plan (and its Integrated Master Schedule) is a critical success factor in any project domain. It describes the increasing maturity of all deliverables in units of measure meaningful to the decision makers.
The IMP contains the Measures of Effectiveness and Measures of Performance. The IMS contains the Technical Performance Measures (as exit criteria for the Work Packages).
Risk and estimates are applied at all levels of the IMP and IMS, then definitized in the Performance Measurement Baseline on contract
The document discusses creating an integrated master schedule (IMS) to coordinate multiple construction projects for a military customer using available contractor schedule data. It provides steps to compile all relevant projects, map project details, identify USACE and non-USACE projects, connect the projects in Primavera software, and convert schedules from various formats into a consolidated IMS in Primavera to help the customer manage the projects. An example IMS is created for projects at Lackland Air Force Base to demonstrate the process.
The document discusses the development of an Integrated Master Plan (IMP) as the basis for an Integrated Master Schedule (IMS) for a program. It outlines a 6-step process for developing the IMP and IMS that includes understanding requirements, developing a product structure, forming integrated product teams, creating the IMP, creating the IMS, and developing the basis of estimate. It describes artifacts like the product tree, work breakdown structure, statement of work, and their relationships. It also outlines responsibilities of the program management team, integrated product team leads, and program planning and controls.
From WBS to Integrated Master ScheduleGlen Alleman
The document provides guidance on developing an integrated master schedule to increase the probability of project success. It discusses starting with a work breakdown structure (WBS) and developing an integrated master plan (IMP) and integrated master schedule (IMS) to show the sequence of work. It also covers adjusting the IMS for risks, and measuring progress using meaningful metrics. The overall aim is to provide processes and tools that communicate project information to stakeholders.
IMP & WBS - Getting Both Right is ParamountGlen Alleman
WBS is the starting point for program success. It tells us what DONE looks like in terms of deliverables.
Integrated Master Plan (IMP) tells us how the increasing maturity of the deliverables will be assessed at each Program Event.
Integrated Master Schedule (IMS) tells us the order of the Work Packages needed to produce this increasing maturity.
Control Account Plan (CAP) defines the authorized scope, budget, and period of performance for the work that produces the deliverables defined in the WBS, assessed in the IMP, and sequenced in the IMS.
Critical Chain Project Management (CCPM) is a methodology that improves project management through 3 key principles: 1) Buffer time is placed on the longest project path to protect the due date. 2) Projects are released based on constraint availability to reduce multitasking. 3) Execution priorities are driven by relative buffer consumption to focus on projects needing attention. CCPM has been successfully implemented by many companies resulting in reduced time to market, higher on-time delivery, more projects completed, and improved resource planning.
This document provides information about planning and scheduling for a metro rail project in Hyderabad, India. It includes details about various project managers and consultants involved in the project. It then discusses the advantages of planning and scheduling, different project phases, knowledge areas, and tools used for planning like Primavera, Microsoft Project, and Excel. It also covers work breakdown structures, resource and organization breakdown structures, activity costing, scheduling techniques, progress measurement, and variance analysis. Overall, the document outlines key concepts and processes for project planning and control used for large infrastructure projects.
Building the Integrated Master Plan (and its Integrated Master Schedule) is a critical success factor in any project domain. It describes the increasing maturity of all deliverables in units of measure meaningful to the decision makers.
The IMP contains the Measures of Effectiveness and Measures of Performance. The IMS contains the Technical Performance Measures (as exit criteria for the Work Packages).
Risk and estimates are applied at all levels of the IMP and IMS, then definitized in the Performance Measurement Baseline on contract
The document discusses creating an integrated master schedule (IMS) to coordinate multiple construction projects for a military customer using available contractor schedule data. It provides steps to compile all relevant projects, map project details, identify USACE and non-USACE projects, connect the projects in Primavera software, and convert schedules from various formats into a consolidated IMS in Primavera to help the customer manage the projects. An example IMS is created for projects at Lackland Air Force Base to demonstrate the process.
The document discusses the development of an Integrated Master Plan (IMP) as the basis for an Integrated Master Schedule (IMS) for a program. It outlines a 6-step process for developing the IMP and IMS that includes understanding requirements, developing a product structure, forming integrated product teams, creating the IMP, creating the IMS, and developing the basis of estimate. It describes artifacts like the product tree, work breakdown structure, statement of work, and their relationships. It also outlines responsibilities of the program management team, integrated product team leads, and program planning and controls.
From WBS to Integrated Master ScheduleGlen Alleman
The document provides guidance on developing an integrated master schedule to increase the probability of project success. It discusses starting with a work breakdown structure (WBS) and developing an integrated master plan (IMP) and integrated master schedule (IMS) to show the sequence of work. It also covers adjusting the IMS for risks, and measuring progress using meaningful metrics. The overall aim is to provide processes and tools that communicate project information to stakeholders.
IMP & WBS - Getting Both Right is ParamountGlen Alleman
WBS is the starting point for program success. It tells us what DONE looks like in terms of deliverables.
Integrated Master Plan (IMP) tells us how the increasing maturity of the deliverables will be assessed at each Program Event.
Integrated Master Schedule (IMS) tells us the order of the Work Packages needed to produce this increasing maturity.
Control Account Plan (CAP) defines the authorized scope, budget, and period of performance for the work that produces the deliverables defined in the WBS, assessed in the IMP, and sequenced in the IMS.
Critical Chain Project Management (CCPM) is a methodology that improves project management through 3 key principles: 1) Buffer time is placed on the longest project path to protect the due date. 2) Projects are released based on constraint availability to reduce multitasking. 3) Execution priorities are driven by relative buffer consumption to focus on projects needing attention. CCPM has been successfully implemented by many companies resulting in reduced time to market, higher on-time delivery, more projects completed, and improved resource planning.
This document provides information about planning and scheduling for a metro rail project in Hyderabad, India. It includes details about various project managers and consultants involved in the project. It then discusses the advantages of planning and scheduling, different project phases, knowledge areas, and tools used for planning like Primavera, Microsoft Project, and Excel. It also covers work breakdown structures, resource and organization breakdown structures, activity costing, scheduling techniques, progress measurement, and variance analysis. Overall, the document outlines key concepts and processes for project planning and control used for large infrastructure projects.
The document discusses project scheduling and tracking methods like PERT charts, Gantt charts, and the critical path method (CPM). PERT charts show task sequences and durations, while Gantt charts graphically present start/end dates. CPM identifies the critical path with the lowest schedule flexibility by performing forward and backward passes to calculate early/late starts and floats. The critical path has zero float and determines the project completion date.
This document provides an overview and outline for a 3-day, 8-hour per day basic Primavera training course. The course introduces participants to the Primavera interface and tools for project creation, work breakdown structures, activities, relationships, resources, and other functions. Each day focuses on a set of key topics, and includes exercises for participants to practice the skills learned.
Concepts and best practices for the risk register in primavera risk analysisp6academy
The document outlines concepts and best practices for using the risk register in Primavera Risk Analysis (PRA). It discusses primary risk register functionality such as risk scoring, creating and assigning risks to tasks, and mitigation options. It also provides an overview of risk functionality in Primavera P6 R8 and importing projects between the two systems.
The document is a summary of a webcast on P6 tips and tricks. It discusses common issues customers log in P6, including project privileges, import considerations, percent complete fields, and out of sequence activities. It then covers specific issues in P6 Release 8 for both the client and web, such as environment variable issues, HTML file problems, and Java errors. The goal is to help users avoid recurring issues and better understand how to troubleshoot problems.
Critical Chain Project Management (CCPM) addresses problems with traditional scheduling methods by focusing on completing the critical chain of tasks rather than individual tasks. It moves scheduling safety from task levels to the project level and prevents multitasking by requiring resources to focus on one task until its completion. CCPM identifies the critical chain of dependent tasks and establishes buffers to protect the project schedule from uncertainties.
The document discusses how to generate S-curves in Oracle Primavera P6 to analyze project progress. S-curves show cumulative costs, labor hours, or other metrics plotted against time and typically have an S-shape. In Primavera P6, S-curves can be generated by activity or resource in the usage profile windows. Various analysis can be done using S-curves, such as determining project growth, slippage, or progress by comparing baseline, target, and actual S-curves. The S-curves can then be published from Primavera P6 as prints or web pages for reporting to clients and management.
The document outlines a three step approach to eliminating crisis project management: 1) Developing a schedule-driven program, 2) Creating a project management recovery system, and 3) Developing a scheduling recovery system. Step one involves instituting senior management buy-in for dedicated scheduling. Step two develops strategies for addressing delays from various sources. Step three provides checklists for analyzing schedules and suggesting recovery solutions when slippage occurs. The overall approach aims to minimize costs from delays through proactive scheduling, recovery planning, and applying lessons learned from past issues.
The document visually breaks down a startup project into work packages, activities, and tasks. It includes a work breakdown structure, network diagram, activity descriptions and predecessors, estimated durations, and critical path analysis. The critical path of the project is the longest chain of activities from start to finish, taking 16 weeks. Project crashing techniques like shortening critical path activities could potentially reduce the project duration but increase risks.
This document provides guidance on updating project schedules. It discusses determining the frequency of updates based on schedule purpose and size. It also outlines the process for collecting progress data from the field, office, owners, and subcontractors. The document details how to status the schedule, calculate updates, check for out-of-sequence work, and verify the updated schedule. It provides recommendations for standard schedule analysis for on-time projects and slipped schedules, including reviewing historical trends, the critical path, and more.
The ART of Avoiding a Train Wreck - Global Payment Day of AgileEm Campbell-Pretty
Presented at the Global Payment Day of Agile - June 2020
The ART of Avoiding a Train Wreck
If you are thinking about launching your first ART or you are struggling with your existing ART(s) then this session is for you! In this session Em will share her “trade secrets” for launching and operating awesome Agile Release Trains. This will go well beyond the standard SAFe courseware, deep diving into practical tips and tricks that can be immediately applied in your context . Em will share war stories, experiments and lessons learnt over almost 10 years of real world experience with SAFe.
Learning Outcomes
The 4 ingredients for a successful train launch
How to “turn up the good” during PI execution
The common mistakes that lead to “train wrecks”
DCMA has enlisted 14-points to assess the project schedule quality. The article explains each of the 14-points in detail and in simple language. Knowledge of these points shall help you to prepare a better and efficient schedule that can be prepared, managed and executed.
A presentation proposing one method of integrating and managing a mega-project portfolio through the use of a KIM schedule without losing interproject relationships key to critical path calculation.
RCF Method-1 uses P6 as the only tool required to manage, execute and control the project schedule regardless of its daunting size. Here is a proposal on a workable method that will support accurate, quick date analysis and timely decision making.
إدارة القيمة المكتسبة مفيدة ومخادعة في التحكم في المشروعات
فيديو دورة الأساسيات: http://prof.planner.teachable.com/p/evm-basics/
دورة المستوى المتقدم: http://www.slideshare.net/MohamedMaged8/contracts-classification
للمزيد: https://www.facebook.com/groups/prof.cost.engineers/
This document provides an overview of earned value management (EVM) including its basic elements, performance analysis and forecasting, and key practices. EVM is an effective project management tool that illuminates the current status of a project compared to what was planned. It involves measuring, analyzing, and reporting on the scope, schedule, and cost of work performed. Critical data elements include planned value (budget), earned value (work completed), and actual cost. Variance, performance indices, and estimates are used to analyze schedule and cost performance and forecast project completion.
Project Closure Activities In Project Management PowerPoint Presentation Slides SlideTeam
Are you searching for professional templates and slides to outline a presentation on Project Closure Activities? Well if yes, then download our ready to use project closure activities in project management PowerPoint presentation slides. Highlight the performance of your business project to the client using this project closure tasks in project management PPT presentation. Using these project management presentation templates, you will be able to confirm if the team members have met all sponsor and consumer needs. This closing a project PowerPoint presentation includes relevant topics such as project brief, project description, project timeline, project progress summary, project status report, and project health card. It also covers a slide on project dashboard, project closure report, work breakdown structure, and project conclusion report-performance analysis, deadline, budget/costs. With the help of the project description presentation PPT, you will be able to represent throughout the progress of the project. Use of stunning graphics and visuals will help you describe the different project stages performance. Download this project closure checklist PPT presentation. Focus on earnings with our Project Closure Activities In Project Management PowerPoint Presentation Slides. Choose the correct asset to create.
The simple problem of schedule performance indicesGlen Alleman
Performance measurement involves tracking a project's cost, schedule, and technical performance against the plan. It is one of five principles of project success. Earned value management compares the budgeted cost of work scheduled (BCWS), actual cost of work performed (ACWP), and budgeted cost of work performed (BCWP) to measure performance and progress. Tracking variances in cost and schedule performance can identify issues needing corrective action to get the project back on track.
Performance-Based Project Management® id s deliverables based approach to project success. Deliverables start with the needed capabilities that the project produces to meet the mission objectives or fulfill a business case.
These deliverables fulfill the requirements, assessed through Measures of Effectiveness and Measures of Performance
The document discusses project scheduling and tracking methods like PERT charts, Gantt charts, and the critical path method (CPM). PERT charts show task sequences and durations, while Gantt charts graphically present start/end dates. CPM identifies the critical path with the lowest schedule flexibility by performing forward and backward passes to calculate early/late starts and floats. The critical path has zero float and determines the project completion date.
This document provides an overview and outline for a 3-day, 8-hour per day basic Primavera training course. The course introduces participants to the Primavera interface and tools for project creation, work breakdown structures, activities, relationships, resources, and other functions. Each day focuses on a set of key topics, and includes exercises for participants to practice the skills learned.
Concepts and best practices for the risk register in primavera risk analysisp6academy
The document outlines concepts and best practices for using the risk register in Primavera Risk Analysis (PRA). It discusses primary risk register functionality such as risk scoring, creating and assigning risks to tasks, and mitigation options. It also provides an overview of risk functionality in Primavera P6 R8 and importing projects between the two systems.
The document is a summary of a webcast on P6 tips and tricks. It discusses common issues customers log in P6, including project privileges, import considerations, percent complete fields, and out of sequence activities. It then covers specific issues in P6 Release 8 for both the client and web, such as environment variable issues, HTML file problems, and Java errors. The goal is to help users avoid recurring issues and better understand how to troubleshoot problems.
Critical Chain Project Management (CCPM) addresses problems with traditional scheduling methods by focusing on completing the critical chain of tasks rather than individual tasks. It moves scheduling safety from task levels to the project level and prevents multitasking by requiring resources to focus on one task until its completion. CCPM identifies the critical chain of dependent tasks and establishes buffers to protect the project schedule from uncertainties.
The document discusses how to generate S-curves in Oracle Primavera P6 to analyze project progress. S-curves show cumulative costs, labor hours, or other metrics plotted against time and typically have an S-shape. In Primavera P6, S-curves can be generated by activity or resource in the usage profile windows. Various analysis can be done using S-curves, such as determining project growth, slippage, or progress by comparing baseline, target, and actual S-curves. The S-curves can then be published from Primavera P6 as prints or web pages for reporting to clients and management.
The document outlines a three step approach to eliminating crisis project management: 1) Developing a schedule-driven program, 2) Creating a project management recovery system, and 3) Developing a scheduling recovery system. Step one involves instituting senior management buy-in for dedicated scheduling. Step two develops strategies for addressing delays from various sources. Step three provides checklists for analyzing schedules and suggesting recovery solutions when slippage occurs. The overall approach aims to minimize costs from delays through proactive scheduling, recovery planning, and applying lessons learned from past issues.
The document visually breaks down a startup project into work packages, activities, and tasks. It includes a work breakdown structure, network diagram, activity descriptions and predecessors, estimated durations, and critical path analysis. The critical path of the project is the longest chain of activities from start to finish, taking 16 weeks. Project crashing techniques like shortening critical path activities could potentially reduce the project duration but increase risks.
This document provides guidance on updating project schedules. It discusses determining the frequency of updates based on schedule purpose and size. It also outlines the process for collecting progress data from the field, office, owners, and subcontractors. The document details how to status the schedule, calculate updates, check for out-of-sequence work, and verify the updated schedule. It provides recommendations for standard schedule analysis for on-time projects and slipped schedules, including reviewing historical trends, the critical path, and more.
The ART of Avoiding a Train Wreck - Global Payment Day of AgileEm Campbell-Pretty
Presented at the Global Payment Day of Agile - June 2020
The ART of Avoiding a Train Wreck
If you are thinking about launching your first ART or you are struggling with your existing ART(s) then this session is for you! In this session Em will share her “trade secrets” for launching and operating awesome Agile Release Trains. This will go well beyond the standard SAFe courseware, deep diving into practical tips and tricks that can be immediately applied in your context . Em will share war stories, experiments and lessons learnt over almost 10 years of real world experience with SAFe.
Learning Outcomes
The 4 ingredients for a successful train launch
How to “turn up the good” during PI execution
The common mistakes that lead to “train wrecks”
DCMA has enlisted 14-points to assess the project schedule quality. The article explains each of the 14-points in detail and in simple language. Knowledge of these points shall help you to prepare a better and efficient schedule that can be prepared, managed and executed.
A presentation proposing one method of integrating and managing a mega-project portfolio through the use of a KIM schedule without losing interproject relationships key to critical path calculation.
RCF Method-1 uses P6 as the only tool required to manage, execute and control the project schedule regardless of its daunting size. Here is a proposal on a workable method that will support accurate, quick date analysis and timely decision making.
إدارة القيمة المكتسبة مفيدة ومخادعة في التحكم في المشروعات
فيديو دورة الأساسيات: http://prof.planner.teachable.com/p/evm-basics/
دورة المستوى المتقدم: http://www.slideshare.net/MohamedMaged8/contracts-classification
للمزيد: https://www.facebook.com/groups/prof.cost.engineers/
This document provides an overview of earned value management (EVM) including its basic elements, performance analysis and forecasting, and key practices. EVM is an effective project management tool that illuminates the current status of a project compared to what was planned. It involves measuring, analyzing, and reporting on the scope, schedule, and cost of work performed. Critical data elements include planned value (budget), earned value (work completed), and actual cost. Variance, performance indices, and estimates are used to analyze schedule and cost performance and forecast project completion.
Project Closure Activities In Project Management PowerPoint Presentation Slides SlideTeam
Are you searching for professional templates and slides to outline a presentation on Project Closure Activities? Well if yes, then download our ready to use project closure activities in project management PowerPoint presentation slides. Highlight the performance of your business project to the client using this project closure tasks in project management PPT presentation. Using these project management presentation templates, you will be able to confirm if the team members have met all sponsor and consumer needs. This closing a project PowerPoint presentation includes relevant topics such as project brief, project description, project timeline, project progress summary, project status report, and project health card. It also covers a slide on project dashboard, project closure report, work breakdown structure, and project conclusion report-performance analysis, deadline, budget/costs. With the help of the project description presentation PPT, you will be able to represent throughout the progress of the project. Use of stunning graphics and visuals will help you describe the different project stages performance. Download this project closure checklist PPT presentation. Focus on earnings with our Project Closure Activities In Project Management PowerPoint Presentation Slides. Choose the correct asset to create.
The simple problem of schedule performance indicesGlen Alleman
Performance measurement involves tracking a project's cost, schedule, and technical performance against the plan. It is one of five principles of project success. Earned value management compares the budgeted cost of work scheduled (BCWS), actual cost of work performed (ACWP), and budgeted cost of work performed (BCWP) to measure performance and progress. Tracking variances in cost and schedule performance can identify issues needing corrective action to get the project back on track.
Performance-Based Project Management® id s deliverables based approach to project success. Deliverables start with the needed capabilities that the project produces to meet the mission objectives or fulfill a business case.
These deliverables fulfill the requirements, assessed through Measures of Effectiveness and Measures of Performance
Project driven organization require lifecycle management to successfully deliver value to those paying for the outcomes of the project effort. This involves processes and data for Executive processes, Enterprise Governance, Program Management Office activities, Applications that enable the delivery of value, and overarching processes and data.
The management of software development is fraught with risk: technical risk, market risk, requirements risk, and financial risk. This paper describes nine (9) key management principles for
guiding the development of a software project. These principles are not original. They are taken directly from the work of Norm Brown, the founder and executive Director of the Software Program Managers Network (SPMN).
The document discusses using probabilistic risk analysis and Monte Carlo simulation to increase the probability of project success. It explains that modeling tasks as probability distributions rather than single point estimates allows for a more accurate assessment of overall schedule and budget risk. Capturing the uncertainty and dependencies between different tasks and cost/schedule drivers is important for generating reliable forecasts. The goal is to quantify confidence levels and establish appropriate margins to account for risks and uncertainties.
Start with defining the deliverables to produce the capabilities needed for project success. Then what work is needed, the order of that work, and the defined outcomes of that work become obvious. Sequence that work, assign durations and resources and you've generated the plans and schedule for success
The document discusses different levels of project complexity and their alignment with agile project management approaches. It uses the analogy of piloting different types of aircraft to represent different levels of projects, from simple solo projects to highly complex projects critical to national security. The levels progress from having full autonomy to operating within strict rules and oversight, where mistakes are not tolerated due to high stakes and consequences. Agile approaches are best suited for self-contained teams with flexibility and autonomy, while larger, more complex projects require more formal processes and governance.
This document discusses the differences between open loop and closed loop control systems and their application to project management and software development. An open loop system does not use feedback to adjust its output, while a closed loop system compares its actual output to a target and uses feedback to correct any errors. For software projects, an open loop approach does not ensure meeting a planned completion date, while a closed loop approach uses feedback from progress measurements to manage toward the target date if deviations occur.
Integrated Master Plan and Integrated Master ScheduleGlen Alleman
The document discusses Niwot Ridge's approach to developing Integrated Master Plans (IMPs) and Integrated Master Schedules (IMSs) for project proposals. Their process starts by capturing the key themes that will lead to success and ensuring they are traceable to the significant accomplishments and criteria for each program event. They establish accomplishments and criteria to demonstrate the increasing maturity of the program in the proposal. All activities and deliverables are vertically and horizontally traceable in the IMS to a risk-adjusted schedule. Their process differentiates proposals by clearly defining traceability and maturity of deliverables in the IMP/IMS from the beginning.
The document provides an overview of project planning and earned value management for a T24 project. It discusses defining deliverables, creating a work breakdown structure and project plan in Microsoft Project, tracking progress to calculate earned value, and using earned value trends and reports for project control. Graphics from Microsoft SharePoint and Project are shown as examples of how lower deliverables, the project schedule, and earned value metrics were managed for the T24 project.
Building a Credible Performance Measurement BaselineGlen Alleman
The document discusses establishing a credible Performance Measurement Baseline (PMB) for programs by integrating technical and programmatic plans. It recommends starting with a Work Breakdown Structure (WBS) that identifies system elements, associated risks, and processes to produce outcomes. An Integrated Master Plan (IMP) should then define how system elements mature at Program Events, with Measures of Effectiveness (MOEs) and Measures of Performance (MOPs) assigned. Finally, an Integrated Master Schedule (IMS) should arrange tasks to increase technical maturity, identify reducible and irreducible risks, and establish a risk-adjusted PMB to increase the probability of program success. Connecting these elements through the WBS, IMP and IMS
1) Current EVMS measures like CPI and SPI provide visibility into cost and schedule performance but do not capture other important factors like technical performance and risk.
2) A balanced approach is needed that connects EVM measures to integrated master plans which include measures of effectiveness, performance, technical milestones, and key parameters.
3) The recommended solution is to make integrated master plans mandatory, update guidance to show how to connect EVM to plans, use statistical analysis to forecast estimates, and require risk-adjusted estimates and regular risk register reviews.
Integrated master plan methodology (v2)Glen Alleman
The document describes a methodology for developing an Integrated Master Plan (IMP). It outlines five conditions an IMP must meet, five steps in the development process, five common questions about IMP development, five common mistakes, and provides five templates/samples for key IMP sections. The methodology is intended to help program and project teams create effective IMPs that integrate execution plans and align with contractual requirements.
Building A Credible Measurement BaselineGlen Alleman
Establishing a credible Performance Measurement Baseline, with a risk adjusted Integrated Master Plan and Integrated Master Schedule, starts with the WBS and connects Technical Measures of progress to Earned Value
EIA-748-C asks us to “objectively assess accomplishments at the work performance level.” As well §3.8 of 748-C tells us “Earned Value is a direct measurement of the quantity of work accomplished. The quality and technical content of work performed is controlled by other processes.”
Earning Value from Earned Value ManagementGlen Alleman
This document discusses how to create value from earned value management (EVM) using both bottom-up and top-down approaches. It emphasizes that EVM metrics like SPI and CPI do not capture the underlying statistical nature of projects, and that modeling this requires stochastic modeling and Monte Carlo simulation. It also stresses that creating value from EVM requires relating budgets to work, measuring progress objectively, and relating cost, schedule, and technical performance.
Building a Credible Performance Measurement BaselineGlen Alleman
Establishing a credible Performance Measurement Baseline, with a risk adjusted Integrated Master Plan and Integrated Master Schedule, starts with the WBS and connects Technical Measures of progress to Earned Value
IS EARNED VALUE + AGILE A MATCH MADE IN HEAVEN?
Increasing the Probability of Program Success requires by connecting the dots between EV and Agile Development.
Presented at
The Nexus of Agile Software Development and
Earned Value Management, OSD-PARCA,
February 19 – 20, 2015
Institute for Defense Analysis, Alexandria, VA
The document discusses the nine integration activities ("Nine I's") that are necessary for program success: 1) Integrated Master Plan, 2) Integrated Master Schedule, and 3) Integrated Risk Management. It emphasizes that risk management is paramount for program success, as all plans are wrong and underestimate risks. It also stresses that the Integrated Master Plan tells the program's execution strategy and how capabilities will increase in maturity, while the Integrated Master Schedule sequences the work activities to deliver the requirements. All nine integration activities must be connected vertically and horizontally.
EAI-748-C asks us to objectively assess accomplishments at the work performance level. As well §3.8 of 748-C tells us Earned Value is a direct measurement of the quantity of work accomplished. The quality and technical content of work is controlled by other processes. To provide visibility to integrated cost, schedule, and technical performance, we need more than CPI and SPI. We need measures of increasing technical performance.
Project cost management a simplified approach white paper - Oracle Primaver...p6academy
Project organizations struggle with predicting long-term project costs, assessing return on investment, and managing cash flow over a project's lifecycle. Integrating financial systems and Oracle Primavera applications can provide cost visibility and control. The document proposes integrating ERP, Primavera Unifier, and Primavera P6 to facilitate sharing accurate, timely data across teams. This would automate processes to improve productivity, empower stakeholders, streamline workflows, and improve task management for executing profitable projects aligned with organizational strategy.
The document provides an overview of Integrated Master Plans (IMPs) and Integrated Master Schedules (IMSs). It discusses how IMPs and IMSs are developed from user requirements and statements of work to provide event-driven plans and task-based schedules. IMPs define program events, accomplishments, and criteria, while IMSs contain detailed tasks and timelines. The development of IMPs and IMSs is an iterative process involving integrated product teams to map requirements to work breakdown structures and schedules.
There are four major questions that need answers when applying agile software development to DOD development programs
1. How can Agile Development methods increase the Probability of Program Success (PoPS) on Earned Value programs?
2. How can Agile development be integrated with the FAR / DFAR and OMB mandates for program performance measures using Earned Value?
3. What are the “touch” points (or possible collision points) between Agile and EIA-748-C?
4. What are the measures of success for Agile methods in the context of EIA-748-C?
How should we estimates agile projects (CAST)Glen Alleman
“Why do so many big projects overspend and
overrun? They’re managed as if they were merely
complicated when in fact they are complex. They’re planned as if everything was known at the start when in fact they involve high levels of uncertainty and risk.” ‒ Architecting Systems: Concepts, Principles and Practice, Hillary Sillitto
Managing risk with deliverables planningGlen Alleman
This document discusses managing risk through continuous risk management (CRM). It introduces the five principles of risk management and outlines the CRM process, which includes identifying risks, analyzing and prioritizing them, planning mitigations, tracking mitigation progress and risks, making decisions based on risk data, and communicating throughout the project. The presentation provides examples of risk statements, evaluation criteria, classification approaches, and integrating risks and mitigation plans into project schedules. The goal of CRM is to continually identify, assess, and mitigate risks to improve project outcomes.
Planning projects usually starts with tasks and milestones. The planner gathers this information from the participants – customers, engineers, subject matter experts. This information is usually arranged in the form of activities and milestones. PMBOK defines “project time management” in this manner. The activities are then sequenced according to the projects needs and mandatory dependencies.
Increasing the Probability of Project SuccessGlen Alleman
This document discusses principles and practices for increasing the probability of project success by managing risk from uncertainty. It defines risk as the effect of uncertainty on objectives. There are two types of uncertainty - epistemic (reducible) and aleatory (irreducible). Risk from epistemic uncertainty can be reduced through work on the program, while risk from aleatory uncertainty requires establishing margins. The document argues that effective risk management is needed to deliver capabilities on time and budget by identifying risks, understanding their interactions and impacts, and implementing risk handling strategies. This increases the likelihood of project success by preventing problems, improving quality, enabling better resource use, and promoting teamwork.
Process Flow and Narrative for Agile+PPMGlen Alleman
This document describes how an organization integrates agile software development practices with earned value management (EVM) to provide program status updates. It outlines a process that begins with developing a rough order of magnitude estimate of features needed. These features are then prioritized, mapped to a product roadmap and product backlog. Stories are developed from features and estimated, and tasks are estimated in hours. Physical percent complete data from tasks in Rally is used to calculate EVM metrics to inform stakeholders.
This document discusses principles of effective risk management for projects. It emphasizes the importance of clearly defining requirements and success criteria before releasing requests for proposals. This includes quantifying measures of effectiveness and performance for different use scenarios. Effective risk management also requires developing a funded implementation plan informed by historical risks and uncertainties. The document outlines key data and processes needed to reduce risks and increase the probability of a project's success, including defining requirements, developing plans and schedules, identifying risks and adjustments needed to plans. It discusses uncertainties from both known and unknown sources that can impact cost, schedule and performance.
Cost and schedule growth for complex projects is created when unrealistic technical performance expectations, unrealistic cost and schedule estimates, inadequate risk assessments, unanticipated technical issues, and poorly performed and ineffective risk management, contribute to project technical and programmatic shortfalls
From Principles to Strategies for Systems EngineeringGlen Alleman
From Principles to Strategies How to apply Principles, Practices, and Processes of Systems Engineering to solve complex technical, operational,
and organizational problems
Capabilities‒Based Planning the capabilities needed to accomplish a mission or fulfill a business strategy
Only when capabilities are defined can we start with requirements elicitation
Starting with the development of a Rough Order of Magnitude (ROM) estimate of work and duration, creating the Product Roadmap and Release Plan, the Product and Sprint Backlogs, executing and statusing the Sprint, and informing the Earned Value Management Systems, using Physical Percent Complete of progress to plan.
Program Management Office Lean Software Development and Six SigmaGlen Alleman
Successfully combining a PMO, Agile, and Lean / 6 starts with understanding what benefit each paradigm brings to the table. Architecting a solution for the enterprise requires assembling a “Systems” with processes, people, and principles – all sharing the goal of business improvement.
This resource document describes the Program Governance Road map for product development, deployment, and sustainment of products and services in compliance with CMS guidance, ITIL IT management, CMMI best practices, and other guidance to assure high quality software is deployed for sustained operational success in mission critical domains.
This document discusses the need for an underlying theory of software project management that can better handle uncertainties. It argues traditional, linear project management models are not well-suited for today's complex, rapidly changing software projects. Adaptive control theory may provide a better model than traditional approaches. Adaptive control systems and agile development processes use feedback loops and emergent solutions to adjust to changes in dynamics, disturbances, or other unplanned events, similar to how project management needs to respond.
Increasing the Probability of Project Success with Five Principles and PracticesGlen Alleman
There are many approaches to managing projects in every domain.
This seminar lays the foundations for increasing the probability of project success, no matter the domain, what technology, what approach to delivering the outcomes of the project.
The principles of this approach are immutable.
The practices for implementing the principles are universally applicable.
Each chart in this presentation, contains guidance that can be applied to your project, no matter the domain.
In our short hour here, we’re going to cover a lot of material.
The bibliography contains the supporting materials we can tailor to your individual project
Seven Habits of a Highly Effective agile project managerGlen Alleman
Recent neurological studies indicate that the role of emotion in human cognition is essential; emotions are not a luxury. Instead, emotions play a critical role in rational decision–making, in perception, in human interaction, and in human intelligence. Habits are the intersection of knowledge, skill, and desire.
"Choosing proper type of scaling", Olena SyrotaFwdays
Imagine an IoT processing system that is already quite mature and production-ready and for which client coverage is growing and scaling and performance aspects are life and death questions. The system has Redis, MongoDB, and stream processing based on ksqldb. In this talk, firstly, we will analyze scaling approaches and then select the proper ones for our system.
Have you ever been confused by the myriad of choices offered by AWS for hosting a website or an API?
Lambda, Elastic Beanstalk, Lightsail, Amplify, S3 (and more!) can each host websites + APIs. But which one should we choose?
Which one is cheapest? Which one is fastest? Which one will scale to meet our needs?
Join me in this session as we dive into each AWS hosting service to determine which one is best for your scenario and explain why!
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdfChart Kalyan
A Mix Chart displays historical data of numbers in a graphical or tabular form. The Kalyan Rajdhani Mix Chart specifically shows the results of a sequence of numbers over different periods.
zkStudyClub - LatticeFold: A Lattice-based Folding Scheme and its Application...Alex Pruden
Folding is a recent technique for building efficient recursive SNARKs. Several elegant folding protocols have been proposed, such as Nova, Supernova, Hypernova, Protostar, and others. However, all of them rely on an additively homomorphic commitment scheme based on discrete log, and are therefore not post-quantum secure. In this work we present LatticeFold, the first lattice-based folding protocol based on the Module SIS problem. This folding protocol naturally leads to an efficient recursive lattice-based SNARK and an efficient PCD scheme. LatticeFold supports folding low-degree relations, such as R1CS, as well as high-degree relations, such as CCS. The key challenge is to construct a secure folding protocol that works with the Ajtai commitment scheme. The difficulty, is ensuring that extracted witnesses are low norm through many rounds of folding. We present a novel technique using the sumcheck protocol to ensure that extracted witnesses are always low norm no matter how many rounds of folding are used. Our evaluation of the final proof system suggests that it is as performant as Hypernova, while providing post-quantum security.
Paper Link: https://eprint.iacr.org/2024/257
In the realm of cybersecurity, offensive security practices act as a critical shield. By simulating real-world attacks in a controlled environment, these techniques expose vulnerabilities before malicious actors can exploit them. This proactive approach allows manufacturers to identify and fix weaknesses, significantly enhancing system security.
This presentation delves into the development of a system designed to mimic Galileo's Open Service signal using software-defined radio (SDR) technology. We'll begin with a foundational overview of both Global Navigation Satellite Systems (GNSS) and the intricacies of digital signal processing.
The presentation culminates in a live demonstration. We'll showcase the manipulation of Galileo's Open Service pilot signal, simulating an attack on various software and hardware systems. This practical demonstration serves to highlight the potential consequences of unaddressed vulnerabilities, emphasizing the importance of offensive security practices in safeguarding critical infrastructure.
What is an RPA CoE? Session 1 – CoE VisionDianaGray10
In the first session, we will review the organization's vision and how this has an impact on the COE Structure.
Topics covered:
• The role of a steering committee
• How do the organization’s priorities determine CoE Structure?
Speaker:
Chris Bolin, Senior Intelligent Automation Architect Anika Systems
Building Production Ready Search Pipelines with Spark and MilvusZilliz
Spark is the widely used ETL tool for processing, indexing and ingesting data to serving stack for search. Milvus is the production-ready open-source vector database. In this talk we will show how to use Spark to process unstructured data to extract vector representations, and push the vectors to Milvus vector database for search serving.
Taking AI to the Next Level in Manufacturing.pdfssuserfac0301
Read Taking AI to the Next Level in Manufacturing to gain insights on AI adoption in the manufacturing industry, such as:
1. How quickly AI is being implemented in manufacturing.
2. Which barriers stand in the way of AI adoption.
3. How data quality and governance form the backbone of AI.
4. Organizational processes and structures that may inhibit effective AI adoption.
6. Ideas and approaches to help build your organization's AI strategy.
TrustArc Webinar - 2024 Global Privacy SurveyTrustArc
How does your privacy program stack up against your peers? What challenges are privacy teams tackling and prioritizing in 2024?
In the fifth annual Global Privacy Benchmarks Survey, we asked over 1,800 global privacy professionals and business executives to share their perspectives on the current state of privacy inside and outside of their organizations. This year’s report focused on emerging areas of importance for privacy and compliance professionals, including considerations and implications of Artificial Intelligence (AI) technologies, building brand trust, and different approaches for achieving higher privacy competence scores.
See how organizational priorities and strategic approaches to data security and privacy are evolving around the globe.
This webinar will review:
- The top 10 privacy insights from the fifth annual Global Privacy Benchmarks Survey
- The top challenges for privacy leaders, practitioners, and organizations in 2024
- Key themes to consider in developing and maintaining your privacy program
FREE A4 Cyber Security Awareness Posters-Social Engineering part 3Data Hops
Free A4 downloadable and printable Cyber Security, Social Engineering Safety and security Training Posters . Promote security awareness in the home or workplace. Lock them Out From training providers datahops.com
HCL Notes and Domino License Cost Reduction in the World of DLAUpanagenda
Webinar Recording: https://www.panagenda.com/webinars/hcl-notes-and-domino-license-cost-reduction-in-the-world-of-dlau/
The introduction of DLAU and the CCB & CCX licensing model caused quite a stir in the HCL community. As a Notes and Domino customer, you may have faced challenges with unexpected user counts and license costs. You probably have questions on how this new licensing approach works and how to benefit from it. Most importantly, you likely have budget constraints and want to save money where possible. Don’t worry, we can help with all of this!
We’ll show you how to fix common misconfigurations that cause higher-than-expected user counts, and how to identify accounts which you can deactivate to save money. There are also frequent patterns that can cause unnecessary cost, like using a person document instead of a mail-in for shared mailboxes. We’ll provide examples and solutions for those as well. And naturally we’ll explain the new licensing model.
Join HCL Ambassador Marc Thomas in this webinar with a special guest appearance from Franz Walder. It will give you the tools and know-how to stay on top of what is going on with Domino licensing. You will be able lower your cost through an optimized configuration and keep it low going forward.
These topics will be covered
- Reducing license cost by finding and fixing misconfigurations and superfluous accounts
- How do CCB and CCX licenses really work?
- Understanding the DLAU tool and how to best utilize it
- Tips for common problem areas, like team mailboxes, functional/test users, etc
- Practical examples and best practices to implement right away
Dandelion Hashtable: beyond billion requests per second on a commodity serverAntonios Katsarakis
This slide deck presents DLHT, a concurrent in-memory hashtable. Despite efforts to optimize hashtables, that go as far as sacrificing core functionality, state-of-the-art designs still incur multiple memory accesses per request and block request processing in three cases. First, most hashtables block while waiting for data to be retrieved from memory. Second, open-addressing designs, which represent the current state-of-the-art, either cannot free index slots on deletes or must block all requests to do so. Third, index resizes block every request until all objects are copied to the new index. Defying folklore wisdom, DLHT forgoes open-addressing and adopts a fully-featured and memory-aware closed-addressing design based on bounded cache-line-chaining. This design offers lock-free index operations and deletes that free slots instantly, (2) completes most requests with a single memory access, (3) utilizes software prefetching to hide memory latencies, and (4) employs a novel non-blocking and parallel resizing. In a commodity server and a memory-resident workload, DLHT surpasses 1.6B requests per second and provides 3.5x (12x) the throughput of the state-of-the-art closed-addressing (open-addressing) resizable hashtable on Gets (Deletes).
Biomedical Knowledge Graphs for Data Scientists and Bioinformaticians
The integrated master plan and integrated master schedule
1. The
Integrated
Master
Plan
And
Integrated
Master
Schedule
The
Integrated
Master
Plan
and
Integrated
Master
Schedule
are
one
of
the
six
elements
of
a
Credible
Performance
Measurement
Baseline
(PMB).
The
PMB
is
the
source
of
data
for
the
Program
Manager.
Some
of
this
data
is
used
in
the
Integrated
Program
Measurement
Report
(IPMR).
Some
is
used
in
the
assessment
of
the
Program’s
risk.
Some
define
the
deliverables
and
their
Technical
Performance
Measures.
1
5
V8.5
2. The
IMP
tells
us
where
is
the
program
going?
The
Plan
describes
where
we
are
going,
the
various
paths
we
can
take
to
reach
our
desLnaLon,
and
the
progress
or
performance
assessment
points
along
the
way
to
assure
we
are
on
the
right
path.
These
assessment
points
measures
the
“maturity”
of
the
product
or
service
against
the
planned
maturity.
This
is
the
only
real
measure
of
progress
–
not
the
passage
of
Lme
or
consumpLon
of
money.
The
Integrated
Master
Plan
(IMP)
Is
A
Strategy
For
The
Successful
Comple=on
Of
The
Project
2
5.0
Start
with
the
IMP
4. Quick
View
to
IMP/IMS
! VerLcal
traceability
defines
the
increasing
maturity
of
key
deliverables
! Horizontal
traceability
defines
the
work
acLviLes
needed
to
produce
this
increasing
maturity
! Both
are
needed,
but
the
verLcal
traceability
is
the
starLng
point
! Program
Events,
Significant
Accomplishments,
and
Accomplishment
Criteria
must
be
defined
before
the
horizontal
work
acLviLes
can
be
idenLfied
! For
all
IMP
elements,
Key
Risks
must
be
idenLfied
and
assigned
from
Day
One,
even
without
miLgaLons
4
5.0
Start
with
the
IMP
5. The
IMP/IMS
is
Needed
on
Both
Sides
of
the
Contract
! Ver%cal
traceability
defines
the
increasing
maturity
of
the
program’s
deliverables
measures
in
EffecLveness
(MoE)
and
Performance
(MoP)
for
the
Government.
! Horizontal
traceability
defines
the
progress
to
plan
for
MoE’s
and
MoP’s
with
tangible
evidence
for
both
the
Government
and
the
Contractor.
! Ver%cal
traceability
provides
the
Government
with
insight
into
the
progress
of
the
MoE’s
and
MoP’s
and
Technical
Performance
Measures.
! Horizontal
traceability
provides
insight
into
Cost
and
Schedule
performance
for
the
Contractor,
reportable
through
the
IPMR
to
the
Government.
5
5.0
Start
with
the
IMP
6. MisconcepLons
of
the
IMP
/
IMS
Why
we
don’t
need/want
an
IMP/IMS
! Only
required
for
ACAT
I
programs
! Too
big
and
burdensome
for
our
small
dollar
value
program
! Contractor
spends
B&P
and
program
budget
generaLng
and
maintaining
the
IMP,
without
measurable
benefit
! Doesn’t
apply
on
a
services
contractors
! Management
tool,
not
a
technical
tool
! Doesn’t
apply
to
technology
programs
! Doesn’t
apply
to
R&D
efforts
! Doesn’t
apply
to
the
government
! Help
me
get
a
waiver
so
I
don’t
have
to
use
an
IMP/IMS
6
5.0
Start
with
the
IMP
7. Aeributes
of
IMP
! Traceability
– Expands
and
complies
with
the
SOO,
Performance
Requirements,
CWBS,
and
CSOW
– Based
on
the
customers
WBS
– Is
the
basis
of
the
IMS,
cost
reports,
and
award
fees
! Implements
a
measurable
and
trackable
program
– Accomplishes
integrated
product
development
– Integrates
the
funcLonal
acLviLes
of
the
program
– Incorporates
funcLonal,
lower
level
and
S/C
IMPs
! Provides
for
evaluaLon
of
Program
Maturity
– Provides
insight
into
the
overall
effort
– Level
of
detail
is
consistent
with
risk
and
complexity
per
§L
– Decomposes
events
into
a
logical
series
of
accomplishments
– Measurable
criteria
demonstrate
compleLon
/
quality
of
accomplishments
7
5.0
Start
with
the
IMP
8. Aeributes
of
the
IMS
! Integrated,
networked,
mulL-‐layered
schedule
of
efforts
required
to
achieve
each
IMP
accomplishment
– Detailed
tasks
and
work
to
be
completed
– Calendar
schedule
shows
work
compleLon
dates
– Network
schedule
shows
interrelaLonships
and
criLcal
path
– Expanded
granularity,
frequency,
and
depth
of
risk
areas
! Resource
loading
! Correlates
IMS
work
with
IMP
events
8
5.0
Start
with
the
IMP
9. The
Importance
of
the
IMP
! The
IMP/IMS
is
the
single
most
important
document
to
a
program’s
success
– It
clearly
demonstrates
the
providers
understanding
of
the
program
requirements
and
the
soundness
of
the
approach
a
represented
by
the
plan
! The
program
uses
the
IMP/IMS
to
provide:
– Up
Front
Planning
and
commitment
from
all
parLcipants
– A
balanced
design
discipline
with
risk
miLgaLon
acLviLes
– Integrated
requirements
including
producLon
and
support
– Management
with
an
incremental
verificaLon
for
informed
program
decisions
9
5.0
Start
with
the
IMP
10. Just
A
Reminder,
before
moving
on
10
Page
47,
Defense
AcquisiLon
Guide,
January
10,
2012
Page
317,
Defense
AcquisiLon
Guide,
January
10,
2012
5.0
Start
with
the
IMP
11. Our
Goal
is
simple
…
How
can
we
recognize
the
Reality
of
the
Program’s
current
status
and
its
future
performance?
The
top
spins
conLnuous
while
in
a
dream
–
stops
spinning
in
the
real
world
–
Cobb’s
totem,
Incep=on
11
5.0
Start
with
the
IMP
13. Principles
of
Building
a
Credible
Integrated
Master
Plan
Building
the
IMP
is
a
Systems
Engineering
ac<vity.
The
Integrated
Master
Plan
is
the
Program
Architecture
in
the
same
way
the
hardware
and
soBware
are
the
Product
Architecture.
Poor,
a
weak,
or
unstructured
Programma<c
Architecture
reduces
visibility
to
the
Product
Architecture’s
performance
measures
of
cost
and
schedule
connected
with
Technical
Performance
Measures.
1
6
V8.5
14. Quick
View
of
Building
the
IMP
! Start
with
each
Program
Event
and
define
the
Significant
Accomplishments
their
entry
and
exit
criteria
to
assess
the
needed
maturity
of
the
key
deliverables
! Arrange
the
Significant
Accomplishments
in
the
proper
dependency
order
! Segregate
these
Significant
Accomplishments
into
swim
lanes
for
IPTs
! Define
the
dependencies
between
each
SA
2
6.0
Build
IMP
15. A
Cri<cal
Understanding
of
the
IMP
3
The
IMP
defines
the
connec<ons
between
the
Product
maturity
–
Ver<cal
–
and
the
implementa<on
of
this
Product
maturity
through
the
Func<onal
ac<vi<es
–
the
Horizontal
6.0
Build
IMP
16. Benefits
of
this
Formality
4
Objec&ve
Implementa&on
Event
Driven
Plan
versus
Schedule
Driven
Plan
is
based
on
comple<on
of
tasks
not
passage
of
<me
Separate
the
plan
(IMP)
from
the
schedule
(IMS)
but
link
elements
with
numbering
system
Condensed,
easy
to
read
“Plan”
showing
the
“Events”
rather
than
the
work
effort
Indentured,
outline
format
–
not
text
Pre-‐defined
entry
and
exit
criteria
for
major
Program
Events
Significant
Accomplishments
for
each
key
Program
Event
Objec<ve
measures
of
progress
and
comple<on
for
each
Accomplishment
Pre-‐defined
Accomplishment
Criteria
(AC)
for
each
Significant
Accomplishment
(SA)
Stable,
contracture
plan,
flexible
enough
to
portray
program
status
IMP
part
of
the
contract,
IMS
is
a
data
item
Capture
essence
of
the
func<onal
progress
without
manda<ng
a
par<cular
process
for
performing
the
work
Split
IMP
into
Product
and
Process
6.0
Build
IMP
17. Risk
Management
Building
the
IMP
Starts
at
the
RFP
5
SOW
SOO
ConOps
WBS
Techncial
and
Opera<onal
Requirements
CWBS
&
CWBS
Dic<onary
Integrated
Master
Plan
(IMP)
Integrated
Master
Schedule
(IMS)
Earned
Value
Management
System
Objec<ve
Status
and
Essen<al
Views
to
support
the
proac<ve
management
processes
needed
to
keep
the
program
GREEN
Performance
Measurement
Baseline
Measures
of
Effec<veness
Measures
of
Performance
Measures
of
Progress
JROC
Key
Performance
Parameters
Program
Specific
Key
Performance
Parameters
Technical
Performance
Measures
1.0
Introduc<on
18. The
IMP
/
IMS
Structure
6
IMS
IMP
Describes how program
capabilities will be
delivered and
how these
capabilities will
be recognized
as ready for
delivery
Supplemental Schedules
Work Packages and Tasks
Criteria
Accomplishment
Events
or
Milestones
1
6.0
Build
IMP
19. The
IMP/IMS
provides
Horizontal
and
Ver<cal
Traceability
of
progress
to
plan
! Ver<cal
traceability
AC
"
SA
"
PE
! Horizontal
traceability
WP
"
WP
"
AC
7
Program Events
Define the maturity
of a Capability at a point in
time.
Significant Accomplishments
Represent requirements
that enable Capabilities.
Accomplishment Criteria
Exit Criteria for the Work
Packages that fulfill Requirements.
Work
Package
Work
Package
Work
Package
Work
Package
Work
Package
Work
Package
Work
package
6.0
Build
IMP
20. The
IMP’s
role
during
Execu<on
8
Program ExecutionPMB for IBRProposal SubmittalDRFP & RFP
Performance Measurement Baseline
Tasks (T)
BOE
% Complete
Statement of Work
Program Deliverables
IMP
Accomplishments (A)
Criteria (C)
EVMS
Events (E)
Budget Spreads by CA & WPCAIV
Capabilities Based Requirements
X BCWS =
Probabilistic Risk Analysis
=
Time keeping and ODC =
Technical Performance Measure
BCWP
ACWP
Cost & Schedule Risk Model
BCWS
Decreasing technical and programmatic risk using Risk Management Methods
IMS
Physical % Complete
Continuity and consistency from DRFP through Program Execution
WBS
6.0
Build
IMP
21. 1st,
Principle
–
IMP
Building
is
a
Full
Contact
Sport
9
6.0
Build
IMP
22. Our
First
Approach
to
the
IMP
/
IMS
Paradigm
! The
1st
approach
defines
Program
Events
(PE),
Significant
Accomplishments
(SA),
and
Accomplishment
Criteria
(AC),
derived
from
the
Work
Breakdown
Structure
or
the
SOW
! This
1st
approach
can
be
done
in
6
easy
steps
10
6.0
Build
IMP
1. Iden<fy
the
Program
Events
(PE)
(as
the
ACQ
Guide
tells
us)
2. Iden<fy
the
Significant
Accomplishments
(SA)
from
the
WBS
deliverables
3. Iden<fy
the
Accomplishment
Criteria
(AC)
needed
to
produce
these
deliverables
4. Iden<fy
the
Work
Packages
for
each
Accomplishment
Criteria
5. Sequence
the
Work
Packages
6. Assemble
the
IMP/IMS
23. This
approach
doesn’t
give
us
visibility
into
what
“done”
looks
like
! We
must
measure
increasing
product
maturity
in
units
meaningful
to
the
decision
makers
! We
must
see
the
risks
before
they
arrive
so
we
can
take
correc<ve
ac<on
11
6.0
Build
IMP
24. First
Look
at
a
Significant
Accomplishment
(SA)
! SAs
are
interim
and
final
steps
to
define,
design,
develop,
verify,
produce,
and
deploy
the
product
or
system.
! SAs
must
occur
in
a
manner
that
ensures
a
logical
path
is
maintained
throughout
the
development
effort.
! SAs
are
event
related
and
not
just
<me
coincidental.
! SAs
should
have
one
or
more
of
the
following
characteris<cs:
– Consists
of
a
discrete
step
in
the
process
of
planned
development
that
must
be
complete
prior
to
an
event
– Produces
a
desired
result
at
a
specified
event
that
indicates
a
level
of
design
maturity
(or
progress)
directly
related
to
each
product
and
process
– Defines
interrela<onships,
interdependencies,
or
“hand-‐off”
points
of
different
func<onal
disciplines
applied
to
the
program
12
6.0
Build
IMP
25. First
look
at
an
Accomplishment
Criteria
(AC)
! ACs
are
defini<ve
measures
directly
suppor<ng
successful
comple<on
of
a
significant
accomplishment.
! ACs
show
objec<ve
evidence
of
work
progress
(maturity
of
a
product);
i.e.,
be
seen,
read,
demonstrated,
or
quan<fied.
These
results
are
usually
incorporated
into
a
report
or
document
as
evidence
of
accomplishment.
! ACs
are
prerequisites
for
comple<on
of
an
SA
(i.e.,
exit
criteria).
! The
ques<ons
that
need
to
be
repeatedly
asked
when
developing
ACs
are:
– How
do
I
know
when
an
accomplishment
has
been
completed?
– Is
the
criteria
directly
related
to
the
accomplishment?
– Is
it
proof?
– What
is
the
work
product?”
13
6.0
Build
IMP
26. The
IMP
speaks
to
Measures
of
Effec<veness
(MoE)
and
Measures
of
Performance
(MoP)
14
6.0
Build
IMP
! This
is
where
TPMs
are
connected
with
the
MoE’s
and
MoP’s
! For
each
deliverable
from
the
program,
all
the
“measures”
must
be
defined
in
units
meaningful
to
the
decision
makers.
! Here’s
some
“real”
examples.
1. Provide
Precision
Approach
for
a
200
FT/0.5
NM
DH
2. Provide
bearing
and
range
to
AC
plaporm
3. Provide
AC
surveillance
to
GRND
plaporm
Measures
of
Effec<veness
(MoE)
1. Net
Ready
2. Guidance
Quality
3. Land
Interoperability
4. Manpower
5. Availability
JROC
Key
Performance
Parameters
(KPP)
1. Net
Ready
! IPv4/6
compliance
! 1Gb
Ethernet
2. Guidance
quality
! Accuracy
threshold
p70
@
6M
!
Integrity
threshold
4M
@
10-‐6
/approach
3. Land
interoperability
! Processing
capability
meets
LB
growth
matrix
4. Manpower
! MTBC
>1000
hrs
! MCM
<
2
hrs
5. Availability
! Clear
threshold
>99%
! Jam
threshold
>90%
Measures
of
Performance
(MoP)
1. Net
Ready
! Standard
message
packets
2. Guidance
Quality
! Mul<path
alloca<on
budget
! Mul<path
bias
protec<on
3. Land
Interoperability
! MOSA
compliant
! Civil
compliant
4. Manpower
! Opera<ng
elapsed
<me
meters
! Standby
elapsed
<me
indicators
5. Availability
! Phase
center
varia<ons
Technical
Performance
Measures
(TPM)
Mission
Capabili<es
and
Opera<onal
Need
Technical
Insight
–
Risk
adjusted
performance
to
plan
27. The
1st
Problem
with
the
Ini<al
IMP/IMS
Paradigm
! There
is
no
single
source
of
guidance
for
construc<ng
a
credible
IMP
and
IMS
– A
DOD
Guidebook,
but
s<ll
in
Version
0.9
– A
few
DOD
service
pamphlets
– A
commercial
guidebook
– Many
contractor
guidelines
! No
defini<ve
guidance
from
DoD
on
what
makes
a
good
IMP
! No
defini<ve
DID
requiring
an
IMP
on
specific
programs
15
6.0
Build
IMP
28. The
IMP
is
a
good
start,
but
we’re
really
aBer
the
IMP
Narra<ves
! The
IMP
Narra<ves
start
with
the
Statement
of
Objec<ves
(SOO)
or
Concept
of
Opera<ons
(ConOps)
– These
iden<fy
the
top
level
program
objec<ves
– They
define
the
big
picture
and
provide
pre-‐award
trade
space
– They
provide
the
framework
for
the
Contractor
to
develop
the
proposal
through
the
IMP
! With
the
Government’s
Execu<ve
summary,
provides
the
contractor
an
understanding
of
what
is
needed
and
what
is
important
16
6.0
Build
IMP
29. The
IMP
Process
Narra<ve
The
IMP
Process
Narra<ve
describes
how
the
technical
and
business
elements
of
the
program
will
be
conducted,
monitored,
and
controlled.
Narra<ves
provide
the
customer
visibility
into
the
contractor’s
key
func<onal
processes
and
procedures,
the
rela<onship
of
these
processes
and
procedures,
and
an
overview
of
the
effort
required
to
implement
them.
17
6.0
Build
IMP
30. IMP
Narra<ve
for
PDR
Program
Event
Event
Descrip&on
PE
Maturity
Assessment
shown
in
SAs
PDR
PDR
establishes
the
“design-‐
to”
allocated
baseline
to
the
subsystem
level,
assures
this
design
meets
the
func<onal
baseline,
assures
system
requirements
have
been
properly
allocated
to
the
proper
subsystem.
PDR
establishes
the
feasibility
of
the
design
approach
to
meet
the
technical
requirements
and
provide
acceptable
interface
rela<onships
between
the
hardware
and
other
interfacing
items.
Any
changes
to
the
requirements
that
have
occurred
since
the
System
Requirements
Review
(SRR2)
will
be
verified
at
the
PDR.
PDR
assures
the
design
is
verifiable,
does
not
pose
major
IMS
or
Cost
risk,
and
is
mature
enough
to
advance
to
the
detailed
design
phase
–
CDR
! Subsystem
level
opera<onal
concepts
defined
! System
level
interfaces
baselined
! Supportability
plans
established
! SoBware
requirements
finalized
! Subsystem
requirements
finalized
&
allocated
! System
verifica<on,
valida<on
&
cer<fica<on
plans
updated
! PDR
subsystem
design
completed
18
6.0
Build
IMP
31. What
the
IMP
Narra<ve
Tells
Us?
! States
the
objec<ve
of
the
processes
used
to
build
the
products
! Provides
the
governing
documents,
compliance,
and
reference
for
the
process
ac<vi<es
! Explains
the
process
approach
– Portrays
the
key
ac<vi<es
of
the
approach
– Illustrates
the
processes
tailored
for
the
specific
program
19
Inputs
Ac<vity
3
Ac<vity
5
Ac<vity
4
Tools
Ac<vity
1
Ac<vity
2
Outputs
Metrics
6.0
Build
IMP
35. 5000.01
Part
2.B.3
Acquisi<on
Strategies,
Exit
Criteria,
and
Risk
Management
“Event
driven
acquisi<on
strategies
and
program
plans
must
be
based
on
rigorous,
objec<ve
assessments
of
a
program’s
status
and
the
plans
for
managing
risk
during
the
next
phase
and
the
remainder
of
the
program.
The
acquisi<on
strategy
and
associated
contrac<ng
ac<vi<es
must
explicitly
link
milestone
decision
reviews
to
events
and
demonstrated
accomplishments
in
development,
tes<ng,
and
ini<al
produc<on.
The
acquisi<on
strategy
must
reflect
the
interrela<onships
and
schedule
of
acquisi<on
phases
and
events
based
on
logical
sequence
of
demonstrated
accomplishments
not
on
fiscal
or
calendar
expediency.”
23
6.0
Build
IMP
36. What
makes
a
good
Program
Event
(PE)?
! Events
are
the
conclusion
of
an
interval
of
major
program
accomplishments
(SA)
with
their
criteria
(AC)
! IMP
events
represent
key
decision
transi<on
points
between
major
ac<vi<es
distributed
over
the
contract
period
– The
IMP
is
a
Mini
Authoriza;on’s
to
Proceed
(ATP)
to
the
next
Program
Event
(PE)
! Some
guidance
for
establishing
program/product
events:
– Customer
Given
Events.
– Key
Decisions
Needed
– Risk
Mi<ga<on
Event
– DOD
Systems
Engineering
Technology
Review
(SETR)
Guidance
24
6.0
Build
IMP
37. What
makes
a
good
Significant
Accomplishment
(SA)?
! IPT
can
manage
it
at
a
working
level
! Shows
comple<on
and
result
s
of
discrete
steps
in
the
development
process
! Indicates
maturity
of
the
product
through
MoEs
and
MoPs
! Its
“significance”
measures
program
event
status
! Relevant
and
logically
linked
to
the
proper
PE
– Just
because
the
work
occurs
during
the
<me-‐frame
for
PE
A
doesn’t
mean
it’s
logically
linked
to
PE
A
! Uses
consistent
language,
style,
format
through
verb
dic<onary,
for
example:
– Segment
build
4
detailed
design
completed
– Analysis
of
structural
integrity
completed
– Structural
integrity
verified
25
6.0
Build
IMP
38. IMP
Significant
Accomplishments
! SAs
are
NOT
just
a
list
of
“things”
to
do
before
the
Program
Event
(PE)
! They
are
sequenced
accomplishments,
each
of
which
leads
to
the
PE,
e.g.
Cri<cal
Design
Review
(CDR)
– SA
#
1
=
CDR
mee<ng
conducted
– SA
#
2
=
CDR
ac<on
item
work-‐off
plan
established
– SA
#
3
=
85%
drawings
completed
– SA
#
4
=
CDR
CDRLs
delivered
– SA
#
5
=
Development
environment
opera<onal
– SA
#
6
=
Cri<cal
methods
analyses
completed
– SA
#
7
=
RVTM
approved
26
6.0
Build
IMP
39. What
makes
a
good
Accomplishment
Criteria
(AC)?
! Provides
objec<ve,
measureable
and,
explicit
proof
of
comple<on
and
closure
of
the
work
ac<vi<es
! Defines
condi<ons
for
closing
the
Significant
Accomplishment
(SA)
! Answers
the
ques<on
how
do
we
know
when
a
Significant
Accomplishment
has
been
completed?
27
6.0
Build
IMP
40. ! Not
Significant
– Too
small
to
significantly
contribute
to
successful
event
comple<on
– Would
lead
to
trivial
tasks
(e.g.,
1
day
dura<on)
! Ambiguous
– Read
can’t
tell
what
Done
looks
like
! Wrong
verb
– Uses
a
verb
that’s
not
on
the
list
(Dic<onary)
– Uses
a
listed
verb
incorrectly
– Doesn’t
have
a
verb
at
all
! Not
measurable
– Can’t
tell
when
we’re
done
! Too
Many
SAs
or
ACs
– Confuses
the
reader
and
confuses
the
execu<on
process
of
the
program
– Dilutes
the
MoE
and
MoP
– Reduces
visibility
into
increasing
maturity
28
What
makes
a
Not
So
Good
SA
or
AC?
6.0
Build
IMP
41. ! Program
Event
(PE)
– A
PE
assess
the
readiness
or
comple<on
as
a
measure
of
progress
– First
Flight
Complete
! Significant
Accomplishment
(SA)
– The
desired
result(s)
prior
to
or
at
comple<on
of
an
event
demonstrate
the
level
of
the
program’s
progress
– Flight
Test
Readiness
Review
Complete
! Accomplishment
Criteria
(AC)
– Defini<ve
evidence
(measures
or
indicators)
that
verify
a
specific
accomplishment
has
been
completed
– SEEK
EAGLE
Flight
Clearance
Obtained
29
F-‐22
Example
6.0
Build
IMP
42. ! PE’s
are
easy,
they
are
in
the
SETR
and
Integrated
Logis<cs
Lifecycle
Management
System
! The
SA’s
can
be
defined
from
the
program’s
deliverables
–
these
may
not
be
obvious
but
can
be
discovered
with
a
Product
Development
Kaizen
process
(more
later)
! It’s
the
AC’s
that
are
hard
part
–
the
ACs
must
represent
the
exit
criteria
for
the
series
of
Work
Packages
that
do
the
work
to
produce
the
product
30
Now
the
Hard
Part
6.0
Build
IMP
43. 6
Steps
to
IMP
Development
Let’s
start
to
build
the
IMP.
This
step-‐by-‐step
process
needs
to
be
followed
carefully.
The
IMP
is
constructed
one
Program
Event
at
a
Cme
–
LeE
to
Right
in
Cme.
To
do
otherwise
allows
confusion
and
disconnecCon
between
Program
Events
to
occur
and
dilutes
our
focus
on
defining
what
Done
looks
like
for
each
Program
Event.
1
7
V8.5
45. Quick
View
of
Step-‐By-‐Step
IMP
IdenCfy
Program
Events
IdenCfy
Significant
Accomplishments
IdenCfy
Accomplishment
Criteria
IdenCfy
Work
Packages
needed
to
complete
the
Accomplishment
Criteria
Sequence
the
Work
Packages
(WP),
Planning
Packages
(PP),
Summary
Level
Planning
Packages
(SLPP)
in
a
logical
network.
Adjust
the
sequence
of
WPs,
PPs,
&
SLPPs
to
miCgate
major
risks.
3
7.0
6
Steps
1
2
3
4
5
6
47. Outcomes
of
Step
! Confirm
the
end
to
end
descripCon
of
the
increasing
maturity
of
the
program’s
deliverables
! Establish
of
RFP
or
Contract
target
dates
for
each
Event.
! Socialize
the
language
of
speaking
in
“Events”
rather
than
Cme
and
efforts
5
1
7.0
6
Steps
48. Events
Define
the
Assessment
of
the
Program’s
Maturity
6
! Program
Events
are
maturity
assessment
points
in
the
program
! They
define
what
levels
of
maturity
for
the
products
and
services
are
needed
before
proceeding
to
the
next
maturity
assessment
point
! The
entry
criteria
for
each
Event
defines
the
units
of
measure
for
the
successful
compleCon
of
the
Event
! The
example
below
is
typical
of
the
purpose
of
a
Program
Event
The
Cri+cal
Design
Review
(CDR)
is
a
mul+-‐disciplined
product
and
process
assessment
to
ensure
that
the
system
under
review
can
proceed
into
system
fabrica+on,
demonstra+on,
and
test,
and
can
meet
the
stated
performance
requirements
within
cost
(program
budget),
schedule
(program
schedule),
risk,
and
other
system
constraints.
1
7.0
6
Steps
49. IdenCfy
the
Significant
Accomplishments
(SA)
for
Each
Program
Event
(PE)
7
Actors
Processes
Outcomes
System
Engineer
IdenCfy
Integrated
Product
Teams
(IPT)
responsible
for
the
SA’s
! Define
the
boundaries
of
these
programmaCc
interfaces
! Define
technical
and
process
risk
categories
and
their
bounds
Technical
Lead
Confirm
the
sequence
of
SA’s
has
the
proper
dependency
relaConships
! Define
the
product
development
flow
process
improves
maturity
! Define
technical
risk
drivers
Project
Engineer
Confirm
logic
of
SA’s
for
project
sequence
integrity
! Define
the
program
flows
improves
maturity
Control
Account
Manager
Validate
SA
outcomes
in
support
of
PE
entry
condiCons
! Confirm
budget
and
resources
adequate
for
defined
work
effort
IMP/IMS
Architect
Assure
the
assessment
points
provide
a
logical
flow
of
maturity
at
the
proper
intervals
for
the
program
! Maintain
the
integrity
of
the
IMP,
WBS,
and
IMS
2
7.0
6
Steps
50. Outcomes
of
Step
! The
Significant
Accomplishments
are
the
“road
map”
to
the
increasing
maturity
of
the
program
! The
“Value
Stream
Map”
resulCng
from
the
flow
of
SA’s
describes
how
the
products
or
services
move
through
the
maturaCon
process
while
reducing
risk
! The
SA
map
is
the
path
to
“done”
8
2
7.0
6
Steps
51. SAs
define
the
entry
criteria
for
each
Program
Event
9
Preliminary
Design
Review
Complete
3
7.0
6
Steps
52. IdenCfy
Accomplishment
Criteria
(AC)
for
each
Significant
Accomplishment
(SA)
Actors
Processes
Outcomes
CAM
Define
and
sequence
the
contents
of
each
Work
Package
and
select
the
EV
criteria
for
each
Task
needed
to
roll
up
the
BCWP
measurement
! Establish
ownership
for
the
content
of
each
Work
Package
and
the
Exit
Criteria
–
the
Accomplishment
Criteria
(AC)
Project
Engineer
IdenCfy
the
logical
process
flow
of
the
Work
Package
to
assure
the
least
effort,
maximum
value
and
lowest
risk
path
to
the
Program
Event
! Establish
ownership
for
the
process
flow
of
the
product
or
service
Technical
Lead
Assure
all
technical
processes
are
covered
in
each
Work
Package
! Establish
ownership
for
the
technical
outcome
of
each
Work
Package
IMP/IMS
Architect
Confirm
the
process
flow
of
the
ACs
can
follow
the
DID
81650
structuring
and
Risk
Assessment
processes
! Guide
the
development
of
outcomes
for
each
Work
Package
to
assure
increasing
maturity
of
the
program
10
3
7.0
6
Steps
53. Outcomes
of
Step
! The
definiCon
of
“done”
emerges
in
the
form
of
deliverables
rather
than
measures
of
cost
and
passage
of
Cme.
! At
each
Program
Event,
the
increasing
maturity
of
the
deliverables
is
defined
through
the
Measures
of
EffecCveness
(MoE)
and
Measures
of
Performance
(MoP)
11
3
7.0
6
Steps
54. ACs
are
higher
fidelity
descripCons
of
“Done”
than
SAs
12
Cri9cal
Design
Review
Complete
4
7.0
6
Steps
55. IdenCfy
the
Work
for
Each
Accomplishment
Criteria
in
Work
Packages
Actors
Processes
Outcomes
Control
Account
Manager
IdenCfy
or
confirm
the
work
acCviCes
in
the
Work
Package
represent
the
allocated
work
! Define
bounded
work
effort
defined
“inside”
each
Work
Package
Technical
Lead
Confirm
this
work
covers
the
SOW
and
CDRLs
! Define
all
work
effort
for
100%
compleCon
of
deliverable
visible
in
a
single
locaCon
–
the
Work
Package
! Confirm
risk
drivers
and
duraCon
variances
IMP/IMS
Architect
Assist
in
the
sequencing
the
work
efforts
in
a
logical
manner
! Develop
foundaCon
of
the
maturity
flow
starCng
to
emerge
from
the
contents
of
the
Work
Packages
Earned
Value
Analyst
Assign
iniCal
BCWS
from
BOE
to
Work
Package
! ConfirmaCon
of
work
effort
against
BOEs
! Define
EVT
for
measures
progress
to
plan
13
4
7.0
6
Steps
56. Outcomes
of
Step
! The
work
idenCfied
that
produces
a
measurable
outcome.
! This
work
defined
in
each
Work
Package
! The
Accomplishment
Criteria
(AC)
state
explicitly
what
“done”
looks
like
for
this
effort
! With
“done”
stated,
measures
of
Performance
and
measures
of
EffecCveness
can
be
defined
14
4
7.0
6
Steps
57. Work
is
done
in
“packages”
that
produce
measureable
outcomes
15
Launch
Readiness
Review
Complete
5
7.0
6
Steps
58. Sequence
Work
Packages
(ACs)
for
each
Significant
Accomplishment
(SA)
16
Actors
Processes
Outcomes
Control
Account
Manager
Define
the
order
of
the
Work
Packages
needed
to
meet
the
Significant
Accomplishments
for
each
Program
Event
! Define
the
process
flow
of
work
and
the
resulCng
accomplishments.
! Assure
value
is
being
produced
at
each
SA
and
the
AC’s
that
drive
them
IMP/IMS
Architect
Assure
that
the
sequence
of
Work
Packages
adheres
to
the
guidance
provided
by
DCMA
and
the
EVMS
System
descripCon
! Begin
the
structuring
of
the
IMS
for
compliance
and
loading
into
the
cost
system
Program
Controls
Staff
Baseline
the
sequence
of
Work
Packages
using
Earned
Value
Techniques
(EVT)
with
measures
of
Physical
Percent
Complete
! Develop
insight
to
progress
to
plan
with
measures
of
physical
progress
for
each
Work
Packages
(EVT)
5
7.0
6
Steps
59. Outcomes
of
Step
! Work
Packages
parCCon
work
efforts
into
“bounded”
scope
! Interdependencies
constrained
to
Work
Package
boundaries
prevents
“spaghek
code”
style
schedule
flow
! Visibility
of
the
Increasing
Flow
of
Maturity
starCng
to
emerge
from
the
flow
of
Accomplishment
Criteria
(AC)
17
5
7.0
6
Steps
61. Assemble
Final
IMP/IMS
Actors
Processes
Outcomes
IMP/IMS
Architect
StarCng
with
the
AC’s
under
each
SA’s
connect
Work
Packages
in
the
proper
order
for
each
Program
Event
! Establish
the
Performance
Measurement
Baseline
framework.
! IdenCfy
MoE
and
MoP
points
in
the
IMP
Program
Manager
Confirm
the
work
efforts
represent
the
commiled
acCviCes
for
the
contract
! Review
and
approval
of
the
IMS
–
ready
for
baseline.
! Review
and
approve
risk
drivers
and
duraCon
variance
models
Project
Engineer
Assess
the
product
development
flow
for
opCmizaCons
! Review
and
approval
of
the
IMS
–
ready
for
baseline.
! IdenCfy
risk
drivers
and
their
miCgaCons
Systems
Engineer
Confirm
the
work
process
flows
result
in
the
proper
products
being
built
in
the
right
order
! Confirm
risk
drivers
and
duraCon
variances.
! Review
and
approval
of
the
IMS
–
ready
for
baseline
19
6
7.0
6
Steps
62. Outcomes
of
Step
! Both
the
maturity
assessment
criteria
and
the
work
needed
to
reach
that
level
of
maturity
are
described
in
a
single
locaCon
! Risks
are
integrated
with
the
IMP
and
IMS
at
their
appropriate
levels
– Risks
to
EffecCveness
–
risk
to
JROC
KPPs
– Risks
to
Performance
–
risk
to
program
KPPs
and
TPMs
! Leading
and
Lagging
indicator
data
provide
through
each
measure
to
forecast
future
performance
20
6
7.0
6
Steps
63. The
Previous
6
Steps
Result
In
A
Credible
IMP/IMS
21
! The
IMP
is
the
“Outer
Mold
Line”,
the
Framework,
the
“Going
Forward”
Strategy
for
the
Program.
! The
IMP
describes
the
path
to
increasing
maturity
and
the
Events
measuring
that
maturity.
! The
IMP
tells
us
“How”
the
program
will
flow
with
the
least
risk,
the
maximum
value,
and
the
clearest
visibility
to
progress.
! The
IMS
tells
us
what
work
is
needed
to
produce
the
product
or
service
at
the
Work
Package
level.
Our
Plan
Tells
Us
“How”
We
are
Going
to
Proceed
The
Schedule
Tells
Us
“What”
Work
is
Needed
to
Proceed
7.0
6
Steps
65. Horizontal
and
VerCcal
Traceability
of
the
IMP/IMS
Integrated
Master
Schedule
Work
sequenced
to
produce
outcomes
for
each
WP.
! VerCcal
traceability
AC
"
SA
"
PE
! Horizontal
traceability
WP
"
WP
"AC
Program Events
Define the maturity
of a Capability at a point in
time.
Significant Accomplishments
Represent requirements
that enable Capabilities.
Accomplishment Criteria
Exit Criteria for the Work
Packages that fulfill Requirements.
Work
Package
Work
Package
Work
Package
Work
Package
Work
Package
Work
package
Work
Package
Work
Package
23
7.0
6
Steps
66. The
IMP’s
connecCon
to
the
WBS
! Start
with
the
Significant
Accomplishments
and
sequence
them
to
the
maturity
flow
for
each
Program
Event
! The
WBS
connecCons
then
become
orthogonal
to
this
flow
24
7.0
6
Steps
Program
Event
SRR
SDR
PDR
CDR
TRR
ATLO
Work
Breakdown
Structure
4.920-‐SDAI
A01,
A02
B01
C01,
C02
D01
E01
F01
4.200-‐Sys
Test
A05
B03,
B04
D02,
D03
E02
F02
4.300-‐Radar
A03
B02
C03
E03
4.330-‐O&C
Sys
A06,
A07
B05
C04
D04
E04
F03,
F04
4.400-‐
I&T
A08
C05
E05,
E06
F05
4.500-‐Support
A09
D05
E07
F06,
F07
73. Nuances
Of
These
6
Steps
Building
the
Program
Event,
to
Significant
Accomplishment,
to
Accomplishment
decomposi?on
is
straight
forward.
For
each
Program
Event,
simply
iden?fy
what
are
the
needed
Significant
Accomplishment
for
the
entry
and
exit
criteria,
and
the
Accomplishment
Criteria
for
the
Work
Packages
that
produce
the
AC.
Yea
Right,
no
problem
1
8
V8.5
75. Quick
View
of
the
Nuances
! Unfortunately
building
a
credible
IMP/IMS
is
a
nuanced
process,
subject
to
many
opportuni?es
for
diversions,
blind
alleys,
and
false
starts
! It
is
slightly
counter
intui?ve
from
the
tradi?onal
scheduling
approach
to
start
with
the
ver?cal
integra?on
–
but
it
is
cri?cal
to
start
ver?cally
! Success
requires
the
full
par?cipa?on
of
Systems
Engineering,
CAMs,
and
the
Program
Manager
! Success
requires
everyone
to
understand
the
nuances
of
the
IMP
building
efforts
3
8.0
Nuances
78. The
3rd
Nuance
Everything
Foot
and
Ties
to
the
IMP
&
IMS
Beginner
Intermediate
Advanced
! The
IMS
contains
all
the
proper
fields
in
columns
and
is
horizontally
linked
! The
WBS
elements
can
be
found
for
all
work
elements
! CDRL’s
are
visible
and
their
mul?ple
delivery
dates
connected
to
each
Program
Event
! WBS
is
structured
in
a
product
manner
or
possibly
a
func?onal
manner
with
some
deliverables
defined
in
the
terminal
nodes
! The
WBS
is
properly
formed
inside
each
AC
with
incremental
deliverables
! WBS
numbers
form
a
“well
structured”
tree,
but
s?ll
is
not
“pure”
in
the
sense
of
deliverables
only,
no
func?onal
! Each
column
and
each
field
can
be
“pivoted”
to
form
a
proper
“tree”
of
value
flow.
! The
WBS
is
a
“pure”
Product
Breakdown
Structure
(PBS)
and
the
services
needed
to
produce
those
products
! The
WBS
defines
the
structure
of
the
delivered
product
or
service
! The
Ver?cal
trace
of
the
IPM
describes
the
flow
of
increasing
maturity
of
these
products
or
services
! The
Horizontal
trace
of
the
IMP
describes
to
work
to
be
done
to
produce
this
maturity
6
8.0
Nuances
79. The
4th
Nuance
IMP/IMS
is
Programma?c
Architecture
Beginner
Intermediate
Advanced
! The
IMP
is
built
from
the
WBS
for
each
Program
Event.
! The
IMP
is
seen
as
a
compliance
document
that
lists
the
Program
Events
and
a
“bunch
of
stuff”
underneath.
! The
IMP
is
structured
around
separate
Program
Events,
but
below
the
SA’s
looks
like
a
“shop
floor”
schedule
with
lijle
ver?cal
connec?vity.
! The
IMP
is
built
as
a
“value
stream”
flow
for
the
program
but
the
Systems
Engineers
! This
programma?c
architecture
is
built
in
the
same
way
the
technical
system
architecture
is
built
! It
is
derived
from
the
ConOps
and
Tier
1
System
Requirements
! The
IMP
shows
explicitly
how
these
are
supported
in
the
flow
of
the
SA’s
7
8.0
Nuances
80. The
5th
Nuance
The
IMP/IMS
connects
all
the
dots
8
8.0
Nuances
Measure
of
Effec?veness
Measure
of
Performance
Technical
Performance
Measure
Risk
Aleatory
Uncertainty
Epistemic
Uncertainty
Reference
Classes
Past
Performance
SME
Past
Performance
System
Architecture
AHP
81. Connec&ng
The
IMP
To
Program
Performance
Measures
Assembling
the
IMS
from
the
IMP
appears
to
be
a
straight
forward
process
–
details
the
tasks
that
support
the
Accomplishment
Criteria.
But
there
are
some
cri&cal
steps
that
must
be
done
in
the
right
order
to
end
up
with
a
risk
tolerant
IMS.
Let’s
do
this
for
TSAS
1
9
V8.5
82. The
Primary
Role
for
the
IMP
is
to
describe
what
done
looks
like
in
MoE’s
and
MoP’s
2
19
October
1899
Robert
Goddard
decided
that
he
wanted
to
"fly
without
wings"
to
Moon.
9.0
Framework
83. Quick
View
to
IMP/IMS
Framework
! Measures
of
increasing
maturity
for
the
key
deliverables
is
the
founda&on
for
increasing
the
Probability
of
Program
Success
! Measures
of
Effec&veness
(MoE)
and
Measures
of
Performance
(MoP)
are
defined
in
the
Integrated
Master
Plan
(IMP)
Narra&ve
! Key
Performance
Parameters
(KPP)
–
both
JROC
and
program
specific
are
needed
! Technical
Performance
Measures
(TPM)
are
needed
for
all
key
deliverables
3
9.0
Framework
84. Star&ng
out
on
the
Right
Foot
…
! Most
IMP/IMS
literature
states
how
to
build
an
IMP
from
the
RFP
and
contractual
elements,
in
simple
and
maybe
simple
minded
terms
– Decompose
the
events
into
SAs,
ACs,
and
their
Tasks
–
sounds
easy
! This
approach
fails
to
provide
advice
for
several
things:
– How
to
minimize
the
topological
connec&ons
between
Events
– How
to
increase
the
concurrency
between
IPTs
– How
to
increase
the
tolerance
of
the
IMS
to
disrup&ve
events
• Known
and
knowable
risk
• Unknown
and
possibly
unknowable
risk
! The
construc&on
of
the
IMS
needs
to
take
place
in
what
seems
to
be
a
reverse
order
– Build
the
IMP
as
a
Value
Stream
Map
describing
the
increasing
maturity
–
and
therefore
the
increasing
VALUE
of
the
deliverables
to
the
customer.
– It’s
the
delivery
of
Customer
Value
that
inverts
the
management
process,
and
focuses
on
Keeping
the
Program
GREEN
as
planned
that
maximizes
value
to
the
customer
(the
Government)
4
9.0
Framework
85. SETR
Program
Events
5
hdps://acc.dau.mil/docs/technicalreviews/dod_tech_reviews.htm
9.0
Framework
86. Build
PEs
Leg
to
Right
Start
with
SRR
(or
something
on
the
leA)
and
completely
define
its
compleDon,
before
moving
to
the
next
PE
! Define
the
SAs
for
an
Event
and
construct
a
work
flow
of
the
ac&vi&es
needed
to
sa&sfy
the
SA
– These
ac&vi&es
are
yet
tasks,
so
don’t
commit
too
soon
to
defining
the
detailed
work
– Isolate
the
SAs
by
event
first
–
only
work
on
one
event
at
a
&me
! Iden&fy
the
par&cipants
in
the
work
– What
IPTs
par&cipate
in
this
work?
– What
swim
lanes
are
needed
to
isolate
the
IPTs?
! Define
the
elements
– Ac&vi&es
performed
to
sa&sfy
the
SA
– Deliverables
that
result
from
these
ac&vi&es
! There
are
s&ll
not
Accomplishment
Criteria
(AC),
but
that
comes
next
6
9.0
Framework
87. The
Accomplishment
Criteria
(AC)
! A
defini&ve
measure
or
indicator
that
verifies
comple&on
of
work
for
the
accomplishment
– Completed
work
effort
• Manufacturing
Plan
Completed
– Confirma&on
of
performance
compliance
• Flight
Test
Report
Approved
– Incremental
verifica&on
• Maintenance
Demonstra&on
Completed
– Completed
cri&cal
process
ac&vi&es
• Risk
Management
Plan
Approved
7
9.0
Framework
88. The
Accomplishment
Criteria
(AC)
! Defines
the
measure
by
which
an
Accomplishment
(SA)
is
considered
“done”
! Terms
like
complete,
delivered,
closed
have
no
“units
of
measure”
in
the
context
of
a
Significant
Accomplishment
(SA)
and
are
open
to
interpreta&on
! Terms
like
…
– Measures
of
comple&on
–
80%
of
drawings
approved
for
release
– Counts
of
available
items
–
75%
of
pin-‐outs
assigned
voltage
– Fidelity
of
a
design
–
outer
mold
line
defined
within
90%
of
target
– Error
bounds
–
spacecraA
mass
known
to
±20%
– Performance
parameters
–
disconnect
force
within
allowed
limits
– Maturity
parameters
–
flight
arDcle
successful
in
last
3
tests
…
are
used
to
define
the
“exit
criteria”
8
9.0
Framework
89. 2
Types
of
Accomplishment
Criteria:
Entry
and
Exit
! Entry
Criteria
–
Substan&ates
readiness
for
the
review
! Exit
Criteria
–
Substan&ates
successful
comple&on
of
the
review
! Cri&cal
Design
Review
(CDR)
example
– Are
we
ready
for
the
Flight
Test
Readiness
Review?
– How
do
we
know
the
FTRR
a
success?
– What
did
we
learn
from
the
FTRR
that
increases
the
maturity
of
the
program’s
deliverables.
9
9.0
Framework
90. The
IMP
Focuses
us
on
Measures
of
Effec&veness
and
Performance
10
MoE
KPP
MoP
TPM
Mission
Need
Acquirer
Defines
the
Needs
and
Capabili&es
in
terms
of
Opera&onal
Scenarios
Supplier
Defines
Physical
Solu&ons
that
meet
the
needs
of
the
Stakeholders
Opera3onal
measures
of
success
related
to
the
achievement
of
the
mission
or
opera3onal
objec3ve
being
evaluated.
Measures
that
characterize
physical
or
func3onal
aAributes
rela3ng
to
the
system
opera3on.
Measures
used
to
assess
design
progress,
compliance
to
performance
requirements,
and
technical
risks.
9.0
Framework
91. Measure
of
Effec&veness
(MoE)
! Measures
of
Effec&veness
…
! Are
stated
in
units
meaningful
to
the
buyer,
! Focus
on
capabili&es
independent
of
any
technical
implementa&on,
! Are
connected
to
the
mission
success.
The
opera&onal
measures
of
success
that
are
closely
related
to
the
achievements
of
the
mission
or
opera&onal
objec&ves
evaluated
in
the
opera&onal
environment,
under
a
specific
set
of
condi&ons.
“Technical
Measurement,”
INCOSE–TP–2003–020–01
MoE’s
Belong
to
the
End
User
11
9.0
Framework
92. Measure
of
Performance
(MoP)
! Measures
of
Performance
are
…
! Adributes
that
assure
the
system
has
the
capability
to
perform,
! Assessment
of
the
system
to
assure
it
meets
design
requirements
to
sa&sfy
the
MoE.
Measures
that
characterize
physical
or
func&onal
adributes
rela&ng
to
the
system
opera&on,
measured
or
es&mated
under
specific
condi&ons.
“Technical
Measurement,”
INCOSE–TP–2003–020–01
MoP’s
belong
to
the
Program
–
Developed
by
the
Systems
Engineer,
Measured
By
CAMs,
and
Analyzed
by
PP&C
12
9.0
Framework
93. Key
Performance
Parameters
(KPP)
Both
JROC
and
Program
Specific
! Key
Performance
Parameters
…
! Have
a
threshold
or
objec&ve
value,
! Characterize
the
major
drivers
of
performance,
! Are
considered
Cri&cal
to
Customer
(CTC).
Represent
the
capabili&es
and
characteris&cs
so
significant
that
failure
to
meet
them
can
be
cause
for
reevalua&on,
reassessing,
or
termina&on
of
the
program
“Technical
Measurement,”
INCOSE–TP–2003–020–01
The
acquirer
defines
the
KPPs
during
the
opera&onal
concept
development
–
KPPs
say
what
DONE
looks
like
13
9.0
Framework
94.
Technical
Performance
Measures
(TPM)
for
key
deliverables
! Technical
Performance
Measures
…
! Assess
design
progress,
! Define
compliance
to
performance
requirements,
! Iden&fy
technical
risk,
! Are
limited
to
cri&cal
thresholds,
! Include
projected
performance.
“Technical
Measurement,”
INCOSE–TP–2003–020–01
Adributes
that
determine
how
well
a
system
or
system
element
is
sa&sfying
or
expected
to
sa&sfy
a
technical
requirement
or
goal
14
9.0
Framework
95. What
are
Technical
Performance
Measures
Really?
! TPMs
are
measures
of
the
system
technical
performance
that
have
been
chosen
because
they
are
indicators
of
system
success.
They
are
based
on
the
driving
requirements
or
technical
parameters
of
high
risk
or
significance
-‐
e.g.,
mass,
power
or
data
rate.
! TPMs
are
analogous
to
the
programma&c
measures
of
expected
total
cost
or
es&mated
&me-‐to-‐comple&on.
There
is
a
required
performance,
a
current
best
es&mate,
and
a
trend
line.
! Actual
versus
planned
progress
of
TPMs
are
tracked
so
the
systems
engineer
or
project
manager
can
assess
progress
and
the
risk
associated
with
each
TPM.
! The
final,
delivered
system
value
can
be
es&mated
by
extending
the
TPM
trend
line
and
using
the
recommended
con&ngency
values
for
each
project
phase.
! The
project
life
trend-‐to-‐date,
current
value,
and
forecast
of
all
TPMs
are
reviewed
periodically
(typically
monthly)
and
at
all
major
milestone
reviews.
15
9.0
Framework
96. ! Tracking
TPMs
and
comparing
them
to
the
resource
growth
provides
an
early
warning
system
to
detect
deficiencies
or
excesses
! Reserve
alloca&ons
narrow
as
design
proceeds
! TPMs
that
violate
reserve
alloca&ons
or
have
trends
that
do
not
meet
the
final
performance
trigger
correc&ve
ac&ons
16
Tracking
the
Technical
Performance
Measures
9.0
Framework
98. Sample
IMP:
A
Flight
Avionics
System
(Con&nued)
Hardware
PDR
–
Purpose
! Ensure
system
hardware
ini&al
design
has
been
updated,
and
meets
func&onal
and
allocated
performance
requirements
within
program
constraints.
! Opera&onal
security
concept
assessed.
! Ensure
training
requirements
have
been
analyzed
and
their
objec&ves
have
been
defined
for
training
missions.
! Confirma&on
training
objec&ves
and
MTC
design
and
integra&on
conform
to
the
Air
Force
syllabus
and
Ready
Aircrew
Program
(RAP).
! Training
plan
will
be
updated.
! Hardware
PDR
–
Expecta&ons
! Team
agrees
system
hardware
ini&al
design
has
been
updated
and
can
proceed
to
the
detailed
design
phase.
! Team
agrees
training
plans
and
objec&ves
correlate
with
the
Air
Force
syllabus,
RAP
and
training
planning,
development
can
con&nue.
! System
Specifica&on
and
TTL
requirements
are
traceable
to
the
allocated
hardware
design.
18
9.0
Framework
99. Sample
IMP:
A
Flight
Avionics
System
(Con&nued)
! Hardware
PDR
–
Entry
Criteria
! Func&onal
Baseline
Authen&cated
(FBA)
! Ini&ate
system
hardware
ini&al
design
and
allocate
func&ons
to
the
appropriate
Configura&on
Items
! All
specifica&ons
updated
and
required
documenta&on
is
made
available
including
an&cipated
lower
level
design
documenta&on
! All
SRR/SFR
ac&on
items
closed
or
disposi&oned
19
9.0
Framework
100. Sample
IMP:
A
Flight
Avionics
System
(Con&nued)
Hardware
PDR
–
Accomplishments
! System
hardware
ini&al
design
complete.
– Func&ons
allocated
to
one
or
more
hardware
configura&on
items
and
are
traceable
to
the
MTC
SSS
and
TSSC
SSS.
– Human,
safety,
R&M,
EMI,
opera&onal
security,
instructor
and
operator
interfaces,
etc,
design
factors
have
been
reviewed.
! Drag
instructor
and
operator
manuals
reviewed
! Program
risks
updated,
assessed,
and
reviewed.
– Mi&ga&on
plans
in
place.
! Program
schedule
and
constraints
updated
and
reviewed.
– Cri&cal
schedule
path
drivers
reviewed.
! Design
criteria
for
the
simula&on
and
database
development
reviewed
and
updated.
! Program
processes
and
metrics
reviewed.
! Test
Planning
ac&vi&es
and
relevant
documenta&on
reviewed
by
test
team.
20
9.0
Framework
101. Sample
IMP:
A
Flight
Avionics
System
(Concluded)
Hardware
PDR
–
Exit
Criteria
! Hardware
(ownership,
visual,
IOS,
brief/debrief)
design
reviewed,
allocated
to
a
hardware
configura&on
item
and
updated
to
include
instructor
and
operators
interfaces,
malfunc&on
and
control
requirements,
etc.
! RTM
updated,
MTC
SSS,
TSSC
SSS
and
TTL
traceable
to
allocated
hardware
design
to
include
ESOH
requirements.
! Human,
safety,
R&M,
EMI,
opera&onal
security,
instructor
and
operator
interfaces,
etc,
design
factors
reviewed.
! MTC
and
TSSC
allocated
baselines
established
and
controlled
by
appropriate
level
documenta&on
for
PDR.
! Drag
instructor
and
operator
manuals
reviewed
with
user
concurrence
and
incorporate
sa&sfactory
human
factor
design
factors
into
the
operator
interfaces.
! Risk
management
and
mi&ga&on
plans
updated,
in
place,
addresses
ESOH
plans
and
risks,
and
within
program
constraints.
! Risks
assesses,
understood,
documented,
accepted
and
understood
by
team.
! Program
schedule
reviewed
– Cri&cal
path
drivers
iden&fied
– IMS
Updated
and
reflects
cri&cal
paths
21
9.0
Framework
102. One
More
IMP
Sample
! (SA)
System
&
Segment
Requirements
Updated
&
Allocated
– (AC)
SRR
/
SDR
Update
Review
Conducted
– (AC)
Preliminary
System
Specifica&on
Documents
(A011)
Baselined
– (AC)
Preliminary
Spacecrag
Segment
Specifica&on
Baselined
– (AC)
Preliminary
Ground
Segment
Specifica&on
Baselined
– (AC)
Preliminary
Specifica&on
Tree
Baselined
! (SA)
Preliminary
ICDs
Baselined
For
Customer
Review
– (AC)
Preliminary
Space-‐Ground
ICD
Baselined
! (SA)
PDR
System
Design
Completed
– (AC)
Top
Level
System
Architecture
Updated
– (AC)
PDR
Level
System
Analyses
Completed
– (AC)
PDR
Level
Reliability
/
Availability
Analysis
Completed
– (AC)
Preliminary
System
Level
Risk
Assessment
Completed
– (AC)
System
Level
Plans
Updated
For
PDR
– (AC)
Flight
Long
Lead
Review
Conducted
22
Preliminary
Design
Review
9.0
Framework
103. The
“But”
for
this
Guidance
! With
these
samples
and
the
SETR
guidance
we’ve
just
started
! The
program
needs
to
define
program
specific
events
to
assure
the
actual
maturity
measures
are
captured
– The
IMP
provides
sufficient
definiDon
to
track
the
step-‐by-‐step
compleDon
of
the
required
accomplishments
for
each
event
and
to
demonstrate
saDsfacDon
of
the
compleDon
criteria
for
each
accomplishment.
[AFMC
PAMPHLET
63-‐5]
23
9.0
Framework
104. IMP
Verbs
for
Significant
Accomplishments
24
Integrated
Master
Plan
Allowable
Verbs
Allocated:
Segment
requirement
is
flowed
down
from
the
System
Specifica&on
Released:
Approved
item
for
delivery
for
intended
customer
or
supplier;
all
internal
distribu&on
and
sign
offs
complete.
An
electronic
version
is
made
accessible
on
the
IDE
Completed:
The
subject
item,
data,
document,
or
process
is
prepared
or
concluded,
and
reviewed
and
accepted
by
the
responsible
IPT.
Suppor&ng
documenta&on
is
available
through
IDE
Reviewed:
The
subject
item,
data,
document,
or
process
is
prepared
or
concluded,
and
documented
for
comple&on.
Suppor&ng
documenta&on
is
available
through
IDE
Conducted:
The
subject
mee&ng
or
review
has
been
held
with
all
required
par&cipants.
The
charts
or
minutes
are
available
through
the
IDE
Updated:
The
subject
process,
data,
or
document
has
been
reevaluated
using
later
informa&on,
and
adjustments
incorporated.
Defined:
The
subject
configura&on
items,
data,
or
document
was
submided
to
the
customer
Validated:
Requirements
are
validated,
received
contractor
approvals,
were
distributed,
and
are
available
through
the
IDE
Established:
The
subject
items
is
created
and
set
in
place
in
a
manner
consistent
with
its
intended
use
ager
review
and
accepted
by
the
IPT
Verified:
Requirements
are
verified
or
processed
in
accordance
with
established
prac&ce.
9.0
Framework
105. The
IMP
Process
Narra&ve
! ObjecFve:
a
brief
statement
explaining
why
this
process
set
is
applied
for
this
program
! Governing
DocumentaFon:
lists
of
the
guidance
or
compliance
documents;
e.g.,
specifica&ons,
manuals,
and
procedures
including
company,
government,
and
industry
references
! Approach:
concise
descrip&on
as
to
who
owns
each
process;
what
are
the
roles
and
responsibili&es;
and
the
overall
process
including
a
process
flow
diagram.
25
9.0
Framework
106. Generic
IMP
Evalua&on
Criteria
! Do
the
Program
Events
and
Accomplishments
reflect
the
logical
evolu&on
and
progress
of
the
overall
Program?
– Do
program
events
and
their
defini&ons
clearly
demonstrate
the
maturity
of
the
program
over
its
life?
– Do
the
selected
Accomplishments
and
associated
Criteria
iden&fy
meaningful
and
measurable
progress
toward
the
key
goals
of
the
Program?
! Do
the
Accomplishments
for
each
event
demonstrate
a
meaningful
understanding
of
the
program
requirements
or
are
they
tasks
that
anyone
could
do
for
any
contract?
– Do
they
reflect
your
SOW
requirements?
! Does
the
IMP
structure
readily
map
to
the
IPT
structure
such
that
each
IPT
can
easily
visualize
the
scope
of
their
responsibility?
! When
awarded,
could
the
contractor
use
the
Accomplishments
as
discrete
ac&vity
cost
accounts
in
their
earned
value
system?
Or
are
they
level
of
effort
in
nature?
! Is
sufficient
visibility
provided
to
iden&fy
and
track
the
Program
Risk
Plan
and
associated
risk
mi&ga&on
accomplishments
and/or
con&ngencies?
– Does
criteria
suppor&ng
the
accomplishments
include
key
performance
requirements?
! Are
IPT
cross-‐dependencies
and
dependencies
external
to
the
Program
appropriately
reflected
if
they
reflect
poten&al
schedule
or
performance
risks
to
the
success
of
the
Program?
! Is
the
submided
"Contract
IMP"
(the
Product
IMP
that
is
to
be
included
as
part
of
the
Program
Contract)
defined
to
the
appropriate
level:
– Do
the
Accomplishments
and
associated
Criteria
go
down
to
a
level
sufficient
to
provide
visibility
into
key
subcontractor
ac&vi&es
upon
which
the
success
of
the
Program
may
be
dependent?
– Are
the
Events
and
Accomplishments
included
in
the
IMP
at
such
a
level
as
to
make
the
maintenance
of
the
'Contractual
IMP'
prac&cal
or
does
it
include
an
unnecessary
level
of
detail?
26
9.0
Framework
107. Program
Management
Levels
Program Levels" IMP/IMS Elements" CWBS"
Tier 1!
Program Manager!
Technical Leads!
IPT Manager!
Technical performance goals!
Major Program Events
(PE)!
!
!
!
Significant
Accomplishments (SA)!
Level 1 & 2!
Links to CLINs!
Level 3 & 4!
Control Packages!
Link to PBS!
Integrated EVMS!
Tier 2!
Control Account Managers !
Product Work Plan!
Responsible organization
elements!
!
Accomplishment
Criteria (AC)!
!
!
!
!
Tasks (NA)!
Level 5!
Cost Account
Package!
Cost Collection Level!
Links to WBS by OBS!
Resource summaries!
Early warning EVMS
analysis!
Tier 3!
Work Package Manager!
Detailed plans! Work package!
Earned value
calculations!
27
9.0
Framework
108. Connec&ng
the
Components
of
the
IMP/IMS
! The
assembled
IMP/IMS
links
all
work
ac&vi&es
ver&cally
to
the
ACs,
SAs,
and
PEs
28
IMS
Customer
Requirements
IMP
ORG
IPTs
ORG
IPTs
Performance
Analysis/
Management
Review
Events (E)
Events (E)
Accomplishments
Process
Narratives
Criteria
Integrated Master
Schedule (IMS)
Integrated Master
Schedule (IMS)
Control Account
Control Account
Work Package
Work Package
Work Package Tasks
Work Package Tasks
WBS
Program
Performance
Management
System
Supplemental Schedules
Risk and
opportunity
Risk and
opportunity
9.0
Framework