SlideShare a Scribd company logo
Niwot Ridge, LLC
DELIVERABLES BASED PLANNING®
Principles and Practices that increase the Probability of
Program Success (PoPS).
V8.3.a
12/23/20
2 DBP
Chapter Title Page
Chapter 0 Deliverables Based Planning in a Nutshell 5
Chapter I Principles and Practices of Deliverables Based Planning® 45
Chapter II The 10 Principles of Deliverables Based Planning® 55
Chapter III Deploying Deliverables Based Planning® 79
Chapter IV Process 1.0 – Identify Needed Systems Capabilities 87
Chapter V Process 2.0 – Establish the Requirements Baseline 97
Chapter VI Process 3.0 – Establish the Performance Measurement Baseline 107
Chapter VII Process 4.0 – Execute the Performance Measurement Baseline 117
Chapter VIII Process 5.0 – Continuous Risk Management 127
Chapter IX Graded Application of Deliverables Based Planning® 147
Chapter X Tools and Artifacts used in Deliverables Based Planning® 159
Append A References for each Chapter 207
Table of Contents
3
Deliverables Based Planning ® is a registered trademark of Niwot Ridge LLC,
DBP4
Deliverables Based Planning®
integrates five critical program
management principles with:
§ Cost,
§ Schedule, and
§ Technical Performance
Measures,
… assuring actionable
information is provided to the
decision makers to increase the
probability of program success.
5
0Deliverables Based Planning® in a Nutshell
Chapter
Deliverables Based Planning®
In A Nutshell
Increasing Your Probability of Success(sm)
Chapter 06
Why Deliverables Based Planning®?
¨ The customer bought
capabilities to fulfill the
mission:†
¤ Not the work effort,
¤ Not the cost
expenditures, and,
¤ Not, the documentation,
test results, or the work
processes.
¨ All successful programs
deliver tangible
beneficial outcomes,
defined in units of
measure meaningful to
the decision makers.
Deliverables Based Planning®
† Mission defines the fundamental purpose of an organization or an enterprise, and states why it exists and what it does to achieve its Vision.
7
Chapter0
1. What Does DONE Look
Like?
2. How Do We Get There?
3. Is There Enough Time,
Resources, And Money To
Get There?
4. What Impediments Will
Be Encountered Along The
Way?
5. What Are The Units Of
Measures For Progress To
Plan?
All Successful Projects Must Know The
Answer To 5 Questions
8Lewis & Fowler, Copyright © 2011
11 Critical Practices Needed to Answer the
5 Questions of Project Success
9
¨ Define the Work Breakdown
Structure(WBS).
¨ Indentify the Organizational
Breakdown Structure (OBS).
¨ Integrate the WBS and OBS.
¨Organization
¨ Schedule the work.
¨ Identify the Products and
Milestones.
¨ Set the time phased budget.
Planning and Budgeting
¨ Record direct costs.
Accounting
¨ Determine variances.
¨ Sum Data and variances.
¨ Manage action plans.
Performance Analysis
¨ Incorporate Changes.
Revision Management
Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
Chapter0
Credible Data Is Need to Increase The
Probability Of Program Success
¨ Concept of
Operations (ConOps)
¨ Operational
Scenarios and Use
Cases
¨ Integrated Master
Plan (IMP)
¨ Value Stream Maps
(VSM)
¨ Key Performance
Parameters (KPP)
¨ Measures of
Effectiveness (MoE)
¨ Program Planning and
Controls (PP&C)
¨ Integrated Master
Schedule (IMS)
¨ Work Packages (WP)
and Planning
Packages (PP)
¨ Earned Value
Management (EVM)
¨ Technical and
Programmatic Risk
Management (RM)
¨ Measures of
Performance (MoP)
¨ Estimate At
Completion (EAC)
¨ Estimate To Complete
(ETC)
¨ To Complete
Performance Index
(TCPI)
¨ Independent Estimate
At Completion (IEAC)
¨ Technical Performance
Measures (TPM)
10
Chapter0
Systems Management Guides the Conversion of
this Data to Actionable Information
¨ Systems Management is the set of organizational
structures and processes that rapidly deliver
dependable technological outcomes within a
predictable time and budget.
¨ Complexity in large scale systems is not driven by the
scale, but rather by the heterogeneity of the
components and their individual underlying complexity.
¨ Managing the complex individual components, their
interactions, their cost, schedule, and technical
performance elements is the role of Systems
Management.
¨ DBP®
connects the data to provide actionable
information to the decision makers.
11
Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
Chapter0
16 Program Management Processes
12
Program Enablers
Program Process Capabilities
Business Enablers
Chapter0
Origins of Deliverables Based Planning®
13
¨ This planning in
the large.
¨ This is planning
in the presence
of change.
¨ The focus is on
transformational
outcomes.
¨ Capabilities start with a mission
level analysis.
www.rand.org
Chapter0
Deliverables Based Planning®
Answers
4+1 Questions Needed for Success
Lewis & Fowler’s Deliverables Based Planning® integrates
five critical program management process areas with – Cost,
Schedule, and Technical Performance Measures.
The inclusion of Technical Performance Measures (TPM)
separates our approach from conventional methods based
solely on managing cost and schedule. In conventional
approaches, the cost and schedule baseline and their
variances generate the data for Earned Value variables that
are used to make programmatic decisions.
In Deliverables Based Planning®, Earned Value measures are
integrated with measures of Physical Percent Complete (PPC)
derived from Technical Performance Measures (TPM) at
planned assessment points in the Integrated Master Schedule
(IMS).
The Events and Milestones define in the Integrated Master
Plan (IMP) describe the planned technical or operational
maturity of the products or services measured against their
actual technical performance.
The Earned Value measurements are used with Technical
Performance measures for each deliverable to produce a
credible measure of progress and a credible forecast of
future performance using the To Complete Performance
Index (TCPI). The result is increased visibility and credibility
of the Independent Estimate at Completion (IEAC).
As the program progresses, technical and programmatic risks
are identified, their mitigation or retirement planned and
executed, and adjustments to the program made to assure
planned progress is maintained.
Successfully executing a program requires a Program
Planning and Controls discipline that identifies what “Done”
looks like, measures progress toward “Done,” identifies the
risks and impediments to reaching “Done,” and assures timely
corrective action to maintain progress toward “Done.”
“Done” is always defined in units of measure meaningful to
the customer. The best tangible evidence are the
Deliverables needed to meet the requirements that fulfill the
system’s requested capabilities that are recognized as
success for the program.
Using this approach, Deliverables fulfill the requirements that
meet the system or business performance criteria, produced
at the planned time, using the planned budget. This
performance is measured as Physical Percent Complete and
is the only Credible measurement of progress.
With the planned requirements fulfilled, the system or
operational capabilities become available to the customer at
the planned time.
14
Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
Chapter0
The 4+1 Questions Every Project
Must Answer to be Successful
Capabilities Requirements Plans Execution
2. What technical and operational requirements are needed to
deliver these capabilities?
1. What capabilities are needed to fulfill the Concept of Operations†, the
Mission and Vision, or the Business System Requirements?
3. What schedule delivers the product or services on
time to meet the requirements?
4. What periodic measures of
physical percent complete assure
progress to plan?
What impediments to success, their mitigations, retirement plans, or “buy
downs are in place to increase the probability of success?”
+ Continuous Risk Management
† A Concept of Operations (ConOps) describes the characteristics of a system from the point of view of an individual who will use that system. It is
used to communicate the quantitative and qualitative system characteristics to all stakeholders.
Œ

Ž


Chapter 015
Deliverables Based Planning®
Addresses …
Project Management Case Study, Pierre Bonnal, CNAM IIM MBA Program, June 2004
16
Chapter0
Identify Needed
Capabilities
Establish a
Performance
Measurement
Baseline
Execute the
Performance
Measurement
Baseline
Capabilities
Based Plan
Operational
Needs
Earned Value
Performance
0% /100%
Technical
Performance
Measures
System Value
Stream
Technical
Requirements
Identify
Requirements
Baseline Technical
Performance
Measures
PMB
Changes to
Needed Capabilities
Changes to
Requirements Baseline
Changes to
Performance Baseline
Œ

Ž


Chapter 017 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
Increasing the Maturity of Project
Deliverables
1. Identify Needed Capabilities to achieve program
objectives or the particular end state. Define these
capabilities through scenarios from the customer point of
view in units of Measure of Effectiveness (MoE)
meaningful to the customer.
2. Define The Technical And Operational Requirements that
must be fulfilled for the system capabilities to be
available to the customer at the planned time. Define
these requirements in terms that are isolated from any
implementation technical products or processes. Only
then bind the requirements with technology.
3. Establish The Performance Measurement Baseline
describing the work to be performed, the budgeted cost
for this work, the organizational elements that produce
the deliverables from this work, and the Measures of
Performance (MoP) showing this work is proceeding
according to cost, schedule, and technical performance.
4. Execute the PMB’s Work Packages in the planned order,
assuring all performance assessment are 0%/100%
complete before proceeding. No rework, no forward
transfer of activities to the future. Assure every
requirement is traceable to work and all work is
traceable to requirements.
5. Perform Continuous Risk Management for each
Deliverables Based Planning®
process area to Identify,
Analyze, Plan, Track, Control, and Communicate
programmatic and technical risk.
The integration of these five process areas is the foundation
of Deliverables Based Planning®
.
Each process area stands alone and at the same time is
coupled with the other process areas. Each process area
contains specific process steps for producing beneficial
outcomes to the project, while establishing the basis for
overall project success.
Each process can be developed to the level needed for
specific projects. All five process areas are critical to the
success of any project.
If a process area is missing or poorly developed, the
capability to manage the project will be jeopardized,
possibly in way not know until the project is too far along to
be recovered.
Each process provides information needed to make decisions
about the flow of the project. This actionable information is
the feedback mechanism needed to keep a project under
control. These control processes are not impediments of
progress of the tools needed to increase the probability of
success.
Chapter0
18
Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
Increasing the Maturity of Project
Deliverables
Identify
Needed
Capabilities
Indentify
Baseline
Requirements
Establish
Performance
Measurement
Baseline
Execute
Performance
Measurement
Baseline
§Define Capabilities
§Define ConOps
§Assess Needs, Cost, and
Risk
§Defined Balanced and
Feasible Alternatives
§Fact Finding
§Gather And Classify
§Evaluate And
Rationalize
§Prioritize
§Integrate And Validate
§Decompose Scope
§Assign Accountability
§Arrange Work
§Develop BCWS
§Assign Performance
§Perform Work
§Accumulate
Performance
§Analyze Performance
§Take Corrective Action
Continuous Risk Management (CRM)
Define the Measurable
Capability Outcomes
Assure All Requirements
Are Met In Support of
Capabilities
Define Measures of
Performance and
Effectiveness
Ensure Cost, Schedule,
and Technical
Performance
Chapter0
19
What is a Deliverable?
Project Management Case Study, Pierre Bonnal, CNAM IIM MBA Program, June 2004.
Chapter0
20
Define the set of capabilities needed to achieve the project objectives or the particular end state
for a specific scenario. Using the Concept of Operations (ConOps), define the details of who,
where, and how this capability is to be accomplished, employed, and executed.
Œ
Define the technical and operational requirements for the system capabilities to be fulfilled. First,
define these requirements in terms isolated from any implementation details. Only then bind the
requirements with technology.

Build a time–phased network of work activities describing the work to be performed, the
budgeted cost for this work, the organizational elements that produce the deliverables, and the
performance measures showing this work is proceeding according to plan.
Ž
Execute work activities, while assuring all performance assessment represent 100% completion
before proceeding. This means – No rework, no forward transfer of activities to the future. Assure
all requirements are traceable to work & all work is traceable to requirements.

Apply the processes of Continuous Risk Management for each Deliverables Based Planning®
process area to: Identify, Analyze, Plan, Track, Control, and Communicate programmatic and
technical risk.

Chapter 021 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
§Partition system capabilities into classes of service within operational scenarios.
§Connect the capabilities to system requirements using some visual modeling notation.
§Define Measures of Effectiveness (MoE) and Measures of Performance (MoP).
§Define the delivery schedule for each measure of performance and effectiveness.
§Define scenarios for each system capability.
§Connect these scenarios to a Value Stream Map of the increasing maturity of the program.
§Assess value flow through the map for each needed capability.
§Identify capability mismatches and make corrections to improve overall value flow.
§Assign costs to each system element using a value flow model.
§Assure risk, probabilistic cost and benefit performance attributes are defined.
§Use cost, schedule and technical performance probabilistic models to forecast potential
risks to program performance.
§Make tradeoffs that connect cost, schedule, and technical performance in a single location
that compares the tradeoffs and their impacts.
§Use Measures of Effectiveness (MoE) and Measures of Performance (MoP) for these
alternative tradeoffs.
Define the capabilities needed to achieve the desired objectives or a particular end state for a
specific scenario. Define the details of who, where, and how these capabilities are to be
accomplished, employed, and executed.
1.1
1.2
1.3
1.4
Œ
Chapter 022
What Does A Capability “Sound” Like?
Chapter0
23
Identifying Needed System Capabilities
Identifying System Capabilities is the starting point for any
successful program. Systems Capabilities are not direct
requirements, but a statements of what the system should
provide in terms of “abilities.” For example there are three
capabilities needed for the Hubble Robotic Servicing Mission:
1. Do no harm to the telescope.
2. Change the Wide Field Camera.
3. Connect the battery umbilical cable.
How is this to be done and what are the technical,
operational, safety and mission assurance requirements?
Don’t really know yet, but the Capabilities guide their
development.
The critical reason for starting with capabilities is to establish
a home for all the requirements. To answer the question “why
is this requirement present?” “Why is this requirement
needed?” “What business or mission value does fulfilling this
requirement provide?”
Capabilities statement can then be used to define the units of
measure for program progress. Measuring progress with
physical percent complete at each level is mandatory. But
measuring how the Capabilities are being fulfilled is most
meaningful to the customer.
The “meaningful to the customer” unit of measures are critical
to the success of any program. Without these measures the
program may be cost, schedule, and technically successful
but fail to fulfill the mission.
The process flow to the right is the starting point for
Identifying the Needed Capabilities and determining their
priorities.
Starting with the Capabilities prevents the “Bottom Up”
requirements gathering process from producing a “list” of
requirements – all needed – that is missing a well formed
topology. This Requirements Architecture is no different than
the Technical or Programmatic architecture of the system.
Capabilities Based Planning (CBP) focuses on “outputs”
rather than “inputs.” These “outputs” are the mission
capabilities that fulfilled by the program.
In order to fulfill these capabilities, requirements need to be
met. But we need the capabilities first. Without the
capabilities, it is never clear the mission will be a success,
because there is no clear and concise description of what
success means.
The concept of CBP recognizes the interdependence of
systems, strategy organization, and support in delivering the
capability, and the need to examine options and trade‒offs
in terms of performance, cost and risk to identify optimum
development investments. CBP relies on scenarios to provide
the context to measure the level of capability.
24
Chapter0
What Should We Do?
Where Are We Now?
Identifying Needed System Capabilities
Abstracted from:
“Capabilities‒Based Planning – How It Is Intended
To Work And Challenges To Its Successful
Implementation,” Col. Stephen K. Walker, United
States Army, U. S. Army War College, March
2005
Identifying Needed System Capabilities
25
Chapter0
§Produce an overall statement of the problem in the operational context.
§Develop the overall operational and technical objectives of the target system.
§Defined the boundaries and interfaces of the target system.
§Gather required system capabilities, functional, nonfunctional and environmental
requirements, and design constraints.
§Build the Top Down capabilities and functional decomposition of the requirements in a
Requirements Management System.
§Answer the question “why do I need this?” in terms of operational capabilities.
§Build a cost / benefit model using probabilistic assessment of all variables, their
dependencies, and impacts.
§For all requirements, perform a risk assessment to cost and schedule.
§Determine criticality for the functions of the system.
§Determine trade off relationships for all requirements to be used when option
decisions must be made.
§For all technical items, prioritize their cost and dependency.
§Address the completeness of requirements by removing all “TBD” items.
§Validate that the requirements are traceable to system capabilities, goals, and mission.
§Resolve any requirements inconsistencies and conflicts.
Define the technical and operational requirements that must be present for the system capabilities to be
delivered. Define these requirements in terms isolated from any technology or implementation. Assure
each requirement is connected to a need system capability.
2.1
2.2
2.3
2.4
2.5

Chapter 026
What Is a Requirement?
27
Chapter0
Identifying Requirements
Requirements are the necessary attributes defined for an
item prior to the efforts to develop a design for the item.
System requirements analysis is a structured, or organized,
methodology for identifying an appropriate set of resources
to satisfy a system need (the needed capabilities) and the
requirements for those resources that provide a sound basis
for the design or selection of those resources.
It acts as the transformation between the customer’s system
needs and the design concept implemented by the
organization’s engineering resources.
The requirements process decomposes a statement of the
customer need through a systematic exposition of what that
system must do to satisfy that need. This need is the ultimate
system requirement which all other requirements and designs
flow.
There are two fundamental classes of requirements.
§ Process Performance Requirements
§ Product Performance Requirements
The Process Performance Requirements define how the work
processes are used to produce a beneficial outcome to the
customer.
The Product Performance Requirements define the product
specifications and how they are related to the process
requirements.
As well as the product and process requirements, there are
functional and non‒functional requirements.
These non‒functional requirements play a significant role in
the development of the system. Non‒functional requirements
are spread across the entire system or within individual
services and cannot be allocated to one specific software
artifact (e.g., class, package, component).
This makes them more difficult to handle than functional
requirements. The specifics of the system’s architecture, such
as highly distributed services bring up additional difficulties.
The distinction between process and product requirements
lays the foundation for the Work Breakdown Structure. The
WBS, the Related Integrated Master Plan (IMP) and
Integrated Master Schedule (IMS), also focus on this
separation.
The success of the project or program depends on defining
both the product and the processes that support or
implement the product.
When properly connected, the Requirements Taxonomy, the
Work Breakdown Structure, the IMP and the IMS “foot and
tied” to the Performance Measurement Baseline (PMB)
provides the traceability of the increasing maturity of the
deliverables (vertical) and the physical percent complete of
the work efforts (horizontal).
28
Chapter0
Identifying Requirements†
†Systems Requirements Practices, Jeffery O. Grady, McGraw Hill, 1993
29
Chapter0
Build a time–phased network of activities describing the work to be performed, the budgeted cost for
this work, the organizational elements that produce the deliverables from this work, and the
performance measures showing this work is proceeding according to plan.
Decompose the program Scope into a product based Work Breakdown Structure (WBS), then further
into Work Packages describing the production of the deliverables traceable to the requirements, and to
the needed capabilities.
3.1
Assign responsibility to Work Packages (the groupings of deliverables) to a named owner
accountable for the management of the resource allocations, cost and schedule baseline, and
technical delivery.
3.2
Arrange the Work Packages in a logical network with defined deliverables, milestones, internal
and external dependencies, with credible schedule, cost, and technical performance margins.
3.3
Develop the Time–Phased Budgeted Cost for Work Scheduled (BCWS) for the labor and material
costs in each Work Package and the Project as a whole. Assure proper resource allocations can be
met and budget profiles match expectations of the program sponsor
3.4
Assign objective Measures of Performance (MoP) and Measures of Effectiveness (MoE) for each Work
Package and summarize these for the Project as a whole.
3.5
Establish a Performance Measurement Baseline (PMB) used to forecast the Work Package and
Project ongoing and completion cost and schedule performance metrics.
3.6
Ž
Chapter 030
What Does a Credible Plan and
Schedule Look Like?
31
Chapter0
Establishing the Three Elements of the
Performance Measurement Baseline
The Performance Measurement Baseline (PMB) is the primary
assessment document for assuring the credibility of a
program plan. The PMB is the baseline of the cost, schedule
and deliverables for each Work Package in the plan.
Constructing the PMB requires knowledge of the business
requirements, skill in developing the Work Packages that
produce the deliverables for these requirements, and
discipline in assembling the cost, schedule and relationships
between the Work Packages. It is the discipline that requires
the most focus for the planners and program controls staff.
Without this discipline, the development of a credible
baseline is simply not possible.
In the end the planners and program controls staff must
“know” in intimate detail each Work Package, its
deliverables and resource requirements, the performance
measurement criteria and the dependencies that form the
critical path through the program schedule.
The concept of a Deliverables Based Plan (DBP) is at the core
of the Performance Measurement Baseline (PMB).
§ Deliverables are the units of measure of progress to plan.
§ Deliverables are what the customer has paid money for.
§ Deliverables contain the business capabilities, the
associated value that fulfill the requirements of the
business plan.
The Technical Performance Baseline is the requirements flow
down and traceability map for each deliverables in the
program.
§ A critical performance measure of the Technical
Performance Baseline is the stability of requirements. The
expected technical achievement for the actual progress is
compared using periodic measurements or tests starts with
the Technical Performance Baseline.
§ An important aspect of the Technical Performance Baseline
is to define the units of measures for each deliverable that
defines what “done” looks like at each incremental
assessment of maturity.
The Schedule Performance Baseline is the sequence of Work
Packages and Planning Packages that produce the products
or services from the program. This baseline contains the
schedule margin derived from the Monte Carlo simulation
described in DID 81650.
The Cost Performance Baseline is the “authorized
time‒phased budget‒at‒completion (BAC) used to measure,
monitor, and control overall cost performance on the
program.” This budget (BCWS) is held in the Control
Accounts, the Work Packages and Planning Packages owned
by the Control Account Manager.
32
Chapter0
Establishing the Three Elements of the
Performance Measurement Baseline
Cost Baseline
Schedule Baseline
Technical Baseline
Perform
Functional
Analysis
Determine
Scope and
Approach
Develop
Technical
Logic
Develop
Technical
Baseline
Develop
WBS
Define
Activities
Estimate
Time
Durations
Sequence
Activities
Finalize
Schedule
Identify
Apportioned
Milestones
Determine
Resource
Requirements
Prepare Cost
Estimate
Resource
Load
Schedule
Finalize
Apportioned
Milestones
Determine
Funding
Constraints
Approve
PMB
33
Chapter0
Execute the planned work, assuring all work is 100% complete before proceeding to the
next planned work package. No rework, no forward transfer of activities or features.
Assure every requirement is traceable to work and all work is traceable to requirements.
§ Using the Work Package sequencing, release work to be performed as planned.
§ With the responsibility assignments, identify the accountable delivery manager to guide the
development of the products or services for each Work Package.
4.1
§ Using Physical Percent Complete or Apportioned Milestones, capture measures of progress to plan
for each Work Package.
§ Report this Physical Percent Complete in a centralized database for each Work Package and the
program as a whole.
4.2
§ Compare the Physical Percent Complete against the Planned Percent Complete for each period of
performance.
§ Construct cost and schedule performance indices from this information and the Physical Percent
complete measures.
4.3
§ With Cost and Schedule performance indices, construct a forecast of future performance of cost,
schedule, and technical performance compliance.
§ Take management actions for any Work Packages not performing as planned.
4.4
§ Record past performance based on Work Package completion criteria.
§ Record past future forecast performance estimates in a historical database.
§ Forecast next future performance estimate against the Performance Measurement Baseline.
§ Report this next future performance estimate to the program stakeholders.
4.5

Chapter 034
How Do We Know We Are Making
Progress to Plan?
35
Chapter0
Executing the Performance Measurement
Baseline
With the Performance Measurement Baseline established, its
execution becomes critically important.
The execution process is called the “program rhythm.” this
means the processes are performed in a repeated manner –
at least on a monthly basis and many times on a weekly
basis.
This business rhythm must create actionable information for
the program manager on a time scale that actually allows
actions to be taken.
For Government programs this time scale is at a minimum
once a month – the Contract Performance Report – in the
form of DI‒MGMT‒81466A.
A larger question must be answered though. How long is the
Program Manager willing to wait before she discovers she is
late? Waiting one month seems risky.
Many programs have weekly status reviews which answer the
question “where are we in terms of progress to plan?”
In the Deliverables Based Planning method, the measure of
this “progress to plan” is provided by the tangible physical
deliverables from the work efforts.
These tangible, physical deliverables must be defined in the
work packaged created during the Planning process of
Deliverables Based Planning.
The measures of physical percent complete can be applied
on weekly boundaries in a variety if ways:
1. To actually have weekly deliverables.
2. Have apportioned milestones for each week.
3. Have tasks that are one week long and record
0%/100% complete at the end of each week.
In all cases, a measure of physical percent complete is
mandatory if the program manager is to receive actionable
information.
The important process here is to have an agreed on measure
of performance that is defined before the work starts.
Keep these measures and the work efforts that produce to
“fine grained” durations.
Focus on answering the question How long are we willing to
wait before we find out we’re late?
The answer to this question must be short enough to take
corrective action so you are in fact not late.
36
Chapter0
Executing the Performance Measurement
Baseline (PMB)
37
Chapter0
§ Identify and classify risks in a Risk Register.
§ Manage this Risk Register through a Risk Management Board.
§ Connect these risks and their handling in the Master Schedule.
§ Convert risk data into risk decision‒making information.
§ Use this analysis information as the decision basis for the program manager to work on the “right”
risks.
§ Turn risk information into decisions and actions (both present and future).
§ Develop actions to address individual risks, prioritize risk actions, and create an integrated risk
management plan.
§ Monitor the status of risks and actions taken to ameliorate risks.
§ Identify and monitor risks to enable the evaluation of the status of risks themselves and of risk
mitigation plans.
§ Risk communication lies at the center of the model to emphasize both its pervasiveness and its
criticality.
§ Without effective communication, no risk management approach can be viable.
Continuous Risk Management starts the underlying principles, concepts, and functions of risk
management and provides guidance on how to implement risk management as a continuous
practice in programs and the organizations that management programs.
5.1
5.2
5.3
5.4
5.5

Chapter 038
Analyze
Plan
Track
Control
Identify Risks, Issues, and
Concerns
Evaluate, classify, and prioritize
risks
Decide what should be done
about each risk
Monitor risk metrics and
verify/validate mitigations
Make risk decisions
Subproject and partner
data/constraints, hazard
analysis, FMEA, FTA, etc.
Risk data: test data, expert
opinion, hazard analysis,
FMEA, FTA, lessons learned,
technical analysis
Resources
Replan Mitigation
Program/project data
(metrics information)
Statement of Risk
Risk classification, Likelihood
Consequence, Timeframe
Risk prioritization
Research, Watch (tracking
requirements)
Acceptance Rationale, Mitigation
Plans
Risk status reports on:
Risks
Risk Mitigation Plans
Close or Accept Risks
Invoke contingency plans
Continue to track
Perform Continuous Risk Management
39
Chapter0
Chapter 040 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
Chapter 041 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
4+1Critical Success Processes
Capabilities,
Requirements &
Deliverables
Program
Architecture &
Dependencies
Work
Planning and
Sequencing
Performance
Measurement
Baseline
Programmatic
& Technical Risk
Management
§Balanced
Scorecard
§Aligned
Organization
Strategy
§Integrated Master
Plan (IMP)
§Gaps
§Overlaps
§Interfaces
§Integrated Master
Schedule (IMS)
§Cost And Schedule
Baseline
§WBS, RAM,
Resource Loaded
IMS
§Risk Registry
§Risk Handling
Plans
§Contingency And
Management
Reserve
§Requirements
Traceability
§Value Stream
Mapping
§Work Packages
§Planning Packages
§Technical
Performance
Measures (TPM)
§Risk Integrated
With IMS
§Risk Trending
§Measures Of
Effectiveness (MoE)
§Design Structure
Matrix (DSM)
§Earned Value
Management
§Measures Of
Performance
(MoP)
§Monte Carlo
Simulation
42
Chapter0
Program Support Services
Business
Process
Reengineering
Balanced
Scorecard
Organizational
Change
Management
DCMA
Compliance
DCAA
Compliance
§ Michael Hammer
trained
reengineering
processes
§ Program
governance
scorecard
§ Integrated Project
Team
development
§ Earned Value
Management
System
Deployment
§ Cost Accounting
Standard (CAS)
system
deployment
§ Project
Management
process
improvement
§ Program
performance
dashboards
§ Performance
management
training
§ EVM System
Description
development and
application
§ Integration of the
EV Engine with a
CAS compliant
accounting system
§ Value stream
mapping
§ Strategic
management
connected with
execution
§ Measurable
Process
improvement
§ EVMS Validation
preparation
§ DCAA and DCMA
compliance of
EVMS
43
Chapter0
Benefits of Deliverables Based Planning®
DBP® Capability Benefits to the Customer
Program, Planning, and Controls
Rapid creation of the risk adjusted Performance
Measurement Baseline.
Earned Value Management ANSI‒748B compliant processes, tools, and training.
Programmatic and Technical Risk
Management
Credible integrated risk management process guided
by DoD, DOE, AACE, and PMI standards.
Management Process Improvement Value focused organizational change management.
Program Performance Assessment Unbiased External Independent Reviews (EIR).
Proposal support – Management Volume IMP/IMS, Basis of Estimate (BoE), and Risk sections.
44
Chapter0
Deliverables Based Planning® Puts You On the
Road to Success …
Where are we going?
How do we get there?
Are there enough resources?
What are impediments to progress?
How do we measure progress?
Chapter 045 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
Chapter 046 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
The10 Organizing Principles of
Deliverables Based Planning®
guide the application of the 5
Practice Areas in this
handbook.
These principles define the
reasons for each practice,
connect each practice to a
beneficial outcome, and
integrate the processes into a
seamless delivery system.
47
IConnecting Principles With
Practice
Chapter
The 10 Organizing Principles of
Deliverables Based Planning®
Principles are the source of guidance for the Deliverables
Based Planning®
Practices.
A principle is a “general truth, a law on which other are
founded or from which others are derived.” [Webster]
For the principles of program and project management to be
effective they must :
§ Express a basic concept
§ Be universally applicable
§ Be capable of straightforward expression
§ Be self evident
The 10 Principles of Deliverables Based Planning®
guide the
application of the four process areas. These principles
encompass the entire life cycle of a project or program, from
inception and the discovery of the business or system
capabilities, through requirements elicitation, to the creation
of the Performance Measurement Baseline (PMB), to the
execution of this baseline.
The principles of Deliverables Based Planning®
provide
several feedback loops to assure that subsequent activities
provide measurable information to correct gaps that exist in
the previous activities. This iterative and incremental
approach to program management assures the periods of
assessment for corrective actions are appropriately spaced
to minimize risk while maximizing the delivered value to the
program.
Deliverables Based Planning® can be the basis of
conventional as well as Lean program management methods.
The illustration the next page are the 10 Principles of
Deliverables Based Planning®. Each principle is developed in
detail later in this handbook. For now understanding the
dependencies between the principles is important.
Information produced by the practices derived from the
principles must be done in a sequential manner. This is not a
“waterfall” approach, but rather an incremental elicitation of
the information needed to successfully manage the program.
Skipping forward in the sequence of principle, creates
systemic risk for both the programmatic and technical
elements of the program.
48
ChapterI
The 10 Organizing Principles of
Deliverables Based Planning®
Assess the capabilities being provided through the deliverables
Fulfill the requirements through effort held in the Work Packages
Produce deliverables
from Work Packages
Planned BCWS
Physical % Complete
WP’s contain
deliverables that fulfill
requirements
Capabilities
topology
defines
requirements
flow down
WP flow must describe
the increasing maturity of
the product or service
Producing the deliverables in the
planned sequence maintains the
value stream to the customer
ChapterI
49
The 5 Process Areas of
Deliverables Based Planning®
Five core process form the basis of Deliverables Based
Planning®
. These processes represent a sequence of activities
that increase the maturity of the programmatic aspects of a
project or program.
The plans that result from these efforts describe the
increasing maturity of the product or services that are the
deliverables from the program.
In order to develop and execute a Plan, a set of
requirements is needed. Before these requirements can be
developed, an understanding of the system capabilities
should be developed.
1. Identify Needed System Capabilities ‒ Define the set of
capabilities (business, operational, or technical) needed
to achieve the program objectives or a particular end
state for a specific scenario using the Concept of
Operations (ConOps). CONOPs is a verbal or graphic
statement, in broad outline, of an assumption or intent in
regard to an operation or series of operations, mission,
or system.
2. Establish Requirements Baseline – defines the technical,
organizational, and operational requirements that must
be in place for the system capabilities to be fulfilled.
Define these requirements in terms isolated from the
implementation details. Only then, bind these
requirements with the technical alternatives.
3. Establish Performance Measurement Baseline – build a
time‒phased network of scheduled activities describing
the work to be performed, the budgeted cost for this
work, and the organizational elements that produce the
deliverables from this work. Define the technical
performance measures showing how this work proceeds
according to the technical and programmatic plan.
4. Execute the Performance Measurement Baseline –
execute the Performance Measurement Baseline Work
Packages, while assuring all performance assessments
represent measures of Physical Percent Complete.
5. Continuous Risk Management – identify, plan, and
budget risk mitigation or retirement activities at assure
impediments to progress are handled.
These five process areas must all be present in some form,
for program success. To skip any process area, or
performance the process area out of order Capabilities,
Requirements, Baseline, and Execution, with Continuous Risk
Management lays the foundation for a Troubled Project.
Each process area builds on the previous area to increase
the fidelity of the actionable information needed by the
decision makers.
This method is independent of any specific development of
engineering process – iterative, incremental, and linear
processes are all equally effective
ChapterI
50
Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
The 5 Process Areas of Deliverables Based Planning®10OrganizingPrinciplesofDeliverablesBasedPlanning®
Chapter I
5
Identify Needed
Capabilities
Establish a
Performance
Measurement
Baseline
Execute the
Performance
Measurement
Baseline
Capabilities
Based Plan
Operational
Needs
Earned Value
Performance
0% /100%
Technical
Performance
Measures
Business or
Mission Value
Stream
Technical
Requirements
Identify
Requirements
Baseline Technical
Performance
Measures
PMB
Changes to
Needed Capabilities
Changes to
Requirements Baseline
Changes to
Performance Baseline
Œ

Ž


Chapter I51
Deliverables Based Planning® Processes
Deliverables Based Planning® is a comprehensive approach
to managing cost, schedule, and technical performance of
programs and projects by assessing the interaction between
programmatic and technical processes. The method starts by
capturing the technical and operational needs of the
proposed system. These are stated in a Concept of
Operations describing how the system operates, how it fulfills
the stated mission, what major components comprise the
system, and how they interact with each other.
From the capabilities description of the Concept of
Operation, technical and operational requirements are
elicited. These requirements define the development progress
of the deliverables captured in the Performance
Measurement Baseline (PMB). This PMB is constructed from a
collection of Work Packages, arranged in a logical network
describing the increasing maturity of the products or services
needed to deliver the stated capabilities. Measures of
physical percent complete are used for each Work Package
and the deliverables they produce. Deliverables Based
Planning® is a Systems Engineering approach to program
and project management [INCOSE], [Stevens].
This method incorporates all three aspects of a program
performance measurement process – Cost, Schedule, and
Technical Performance Measures (TPM).
The inclusion of the TPMs distinguishes the Lewis & Fowler
Deliverables Based Planning® from more conventional
approaches to Program, Planning, and Controls.
In conventional approaches, the cost and schedule baseline
and the variances generate the values for Earned Value.
In the Deliverables Based Planning®
method, measures of
Physical Percent Complete are derived from pre–defined
targets of Technical Performance. The Earned Value
variables are augmented with adjustments from the Technical
Performance compliance for each deliverable to produce a
true assessment of progress.
Technical Performance Measures integrate technical
achievement with earned value using risk assessments that
provides a robust program management tool to identify
early technical and programmatic disruptions to a program.
[Pisano] TPMs:
Provide an integrated view across all programmatic and
technical elements.
Support distributed empowerment implicit in the IPT
approach, through interface definitions.
Logically organizes data resulting from systems engineering,
risk management, and earned value processes.
Provide a "real time" indication of contract performance and
future cost and schedule risk.
Support the development of systems thinking within an
integrated program model focused on the interface
definitions.
ChapterI
52
Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
Deliverables Based Planning® Processes
ChapterI
53
Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
1. Identify Needed Systems Capabilities – Define the Measures of Effectiveness (MoE) Deliverables Based Planning®
DEFINE OPERATIONAL CONCEPTS THROUGH SCENARIOS OR USE CASES
Partition system capabilities into classes of service within operational scenarios
Connect capabilities to system requirements using sysML
Define Measures of Effectiveness (MoE) for these capabilities in units meaningful to the customer
Define in the master schedule the achievement of measure of Technical Performance
DEFINE CAPABILITIES NEEDED TO IMPLEMENT THE OPERATIONAL CONCEPTS
Define scenarios for each system capability
Connect these scenarios to the Value Stream map
Assess value flow through the map for each needed capability
Identify capability mismatches and make corrections to improve overall value flow
ASSESS NEEDS, COST, AND RISK SIMULTANEOUSLY
Assign costs to each system element using a value process model
Assure risk, probabilistic cost and benefit performance attributes are defined
Use cost, schedule, and technical performance probabilistic models to forecast potential risks to program performance
DEFINE EXPLICIT, BALANCED, AND FEASIBLE ALTERNATIVES
Make tradeoffs that connect cost, schedule, and technical performance in a single “trade space” model
Measures of Effectiveness and Measures of Performance are the raw materials for these tradeoffs
2. Establish Requirements Baseline – DEFINE MEASURES OF PERFORMANCE (MOP)
PERFORM FACT FINDING
Produce an overall statement of the problem in the operational context
Develop the overall operational and technical; objectives of the target system through Measures of Performance (MoP) for the requirements
Define the boundaries and interfaces of the target system
GATHER AND CLASSIFY THE REQUIREMENTS
Gather required operational capabilities, functional, nonfunctional, and environment requirements and design constraints
Build a Top Down Capabilities and Functional decomposition of the requirements in a flow down tree using a requirements tool
EVALUATE AND RATIONALIZE THE REQUIREMENTS
Answer the question “why do we need this?” in terms of operational benefits
Build a cost / benefit model using probabilistic assessments of all variables and dependencies
For technical requirements, perform a risk assessment to the cost and schedule
PRIORITIZE THE REQUIREMENTS
Determine the criticality for the functions for the system’s mission
Determine tradeoff relations for all requirements to be used when option decision are made
For technical items, prioritize the cost and dependencies
INTEGRATE AND VALIDATE THE REQUIREMENTS
Address completeness of requirements by removing all TBD items
Validate the requirements agree and are traceable to capabilities, goals, and the mission
Resolve any requirement inconsistencies and conflicts
Chapter IChapter I54
3. ESTABLISH PERFORMANCE MEASUREMENT BASELINE – DEFINE TECHNICAL PERFORMANCE MEASURES (TPM) DELIVERABLES BASED PLANNING®
DECOMPOSE REQUIREMENTS INTO WORK PACKAGES AND PLANNING PACKAGES
Decompose the program scope into a product based Work Breakdown Structure (WBS)
Decompose the WBS into Work Packages describing the production of all deliverables and processes traceable to the requirements
ASSIGN ACCOUNTABILITY FOR THE DELIVERABLES FROM EACH WORK PACKAGE
Assign accountability for Work Packages to a named owner for the management of resource allocation, cost baseline, and technical delivery
ARRANGE WORK PACKAGES IN A LOGICAL ORDER
Arrange Work Packages in a network with defined deliverables, milestones, internal and external dependencies, appropriate schedule and cost margin
DEVELOP THE BUDGETED COST FOR WORK SCHEDULED (BCWS) FOR EACH WORK PACKAGE AND PLANNING PACKAGE
Develop a time‒phased Budgeted Cost for Work Scheduled (BCWS) for labor and material costs in each Work Package
Develop a time‒phased Budgeted Cost for Work Scheduled (BCWS) for the program as a whole
Assure proper resource allocations can be met and budget profiles match expectations of the program sponsor
ASSIGN WORK PACKAGE MEASURES OF PERFORMANCE (MOP), KEY PERFORMANCE PARAMETERS (KPP), AND TECHNICAL PERFORMANCE MEASURES (TPM)
Assign an objective Measure of Performance (MoP) for each critical Work Package deliverable
Trace critical deliverables to the Measure of Effectiveness (MoE) defined in the Capabilities baseline
Summarize these Measures of Performance (MoP) and Measures of Effectiveness (MoE) for the program as a whole
Assign measures of Physical Percent Complete for each Work Package
Assign measures of Physical Percent Complete for the program as a whole
SET THE PERFORMANCE MEASUREMENT BASELINE (PMB)
Establish a Performance Measurement Baseline (PMB) used to forecast Work Package and Project ongoing and completion cost and schedule metrics
4. Execute the Performance Measurement Baseline (PMB) – Maintain Cost, Schedule, and Technical Performance
PERFORM AUTHORIZED WORK IN THE PLANNED SEQUENCE
Using the Work Package sequencing, release work to be performed as planned
With the RACI based RAM, the Accountable delivery manager guides the development of the products or service for each Work Package
ACCUMULATE AND REPORT WORK PACKAGE PHYSICAL PERFORMANCE
Using Physical Percent complete or Apportioned Milestones, capture the measures of “progress to plan” for each Work Package
Report the Physical Percent Complete in a centralized system for each Work Package and he program as a whole
ANALYZE WORK PACKAGE PERFORMANCE
Compare the Actual Percent Complete against the Planned Percent Complete for each period of performance
Construct cost and schedule performance indices from this information and the Physical Percent Complete measures
TAKE CORRECTIVE MANAGEMENT ACTION FOR ANY VARIANCE IN WORK PACKAGE PERFORMANCE
With the cost and schedule performance indices, construct a forecast of future performance of cost, schedule, and technical performance compliance
Take management actions for any Work Packages not performing as planned
MAINTAIN PERFORMANCE MEASUREMENT BASELINE’S INTEGRITY
Record past performance based on Work Package completion criteria
Record previous future performance estimates in a historical database
Forecast future performance against the Performance Measurement Baseline
Report the future performance estimate to the program stakeholders
Chapter IChapter I55
Program Events
Define the availability
of a Capability at a point in
time.
Accomplishments
Represent requirements
that enable Capabilities.
Criteria
Represent Work Packages
that deliver the Requirements.
Work
Package
Work
Package
Work
Package
Work
Package
Work
Package
Work
Package
Work
Package
Work
package
§ Deliverables Based Planning®
describes of the increasing maturing of a product or service through
Events or Milestones, Accomplishments, Criteria, and Work Packages.
§ Each Event or Milestone represents the availability of one or more capabilities.
§ The presence of these capabilities is measured by the Accomplishments and their Criteria.
§ Accomplishments are the pre–conditions for the maturity assessment of the product or service at
each Event or Milestone.
§ This hierarchy decomposes the System Capabilities into Requirements, Work Packages, and the
activities the produce the deliverables. This hierarchy also describes increasing program maturity
resulting from the activities contained in the Work Packages.
§ Performance of the work activities, Work Packages, Criteria, Accomplishments, and Events or
Milestones is measured in units of “physical percent complete” by connecting Earned Value with
Technical Performance Measures.
The structure of a
Deliverables Based Plan
Chapter IChapter I56
10 organizing principles guide
the deployment of Deliverables
Based Planning® and the
application of the 5 Process
Areas.
These 10 principles form the
basis of the “theory” of
Deliverables Based Planning®,
while the Process Areas are the
practice of the principles.
57
II10 Organizing Principles
Chapter
The 10 Organizing Principles of
Deliverables Based Planning®
Assess the capabilities being provided through the deliverables
Fulfill the requirements through effort held in the Work Packages
Produce deliverables
from Work Packages
Planned BCWS
Physical % Complete
WP’s produce
deliverables that fulfill
requirements
Capabilities
topology defines
requirements flow
down
WP flow must describe
the increasing maturity of
the product or service
Producing the deliverables in the
planned sequence maintains the
value stream to the customer
ChapterII
58
Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
The 10 Organizing Principles of
Deliverables Based Planning®
Organizing Principles in Order of Increasing Maturity
1 Capabilities drive system requirements. All requirements must be traceable to a capability.
Requirements identify technical and process deliverables. All deliverables must be traceable to a
requirement.
Work Packages describe the production of deliverables.
Integrated Master Schedule (IMS) arrange the Deliverables, Accomplishments, Criteria, and Work
Packages into a logical – risk adjusted – activity network.
Work Package progress is measured as Physical Percent Complete against the planned progress at time
of the performance assessment.
Work Authorization assures the sequence of Work Packages produce progress at the planned rate for
the planned cost, with the planned product maturity at each assessment point in the IMS.
Earned Value describes the current performance and provides information about future performance.
Conformance with Technical Performance Measures adjusts Earned Value for rework, quality, or delayed
features, using Units of Measure meaningful to the decision makers.
Performance feedback from each WP and program level Earned Value adjusts the WP sequence and
resource allocation to reestablish an on–time, on–budget schedule.
Future performance is based on the To Complete Performance Index (TCPI), Independent Estimate At
Complete (IEAC), and the adjusted work sequence.
ChapterII
59
Capabilities Drive System Requirements
The principles for defining a capability address the
flexibility needed to ensure system responsiveness and
sustainability in a context of constant change, while
delivering tangible benefits to the buyer
These include: Agility, Tailorability, and measures of System
Element coupling and cohesion.
Governance principles provide guidance to institutionalize a
process, including its continued assessment and evolution over
time in support of the tangible system benefits.
These include: Enforced Rules & Responsibilities, Workflow
Guidance, Continuous Improvement, Transformation enablers.
The core concept in Capabilities Based development is the
focus on the delivery of value. The concept of “Value
Focused Thinking” starts with two methods of decision
making: the 1st
focuses on competitive analysis between the
various alternatives, and the 2nd focuses on attaining
organization values as the fundamental objective of any
decision making process. [Pagatto07]
During the development of the Concept of Operations for
each capability, assumptions must be made in the absence of
specific technical and operational information. To avoid
unwelcome surprises, some form of assumptions based
planning is needed. 1) Make operational plans, 2) Describe
plausible events, 3) Identify the “signposts” for potential
problems, 4) Discover shaping actions that shore up uncertain
assumptions, and 5) take hedging actions to better prepare
for the possibility that an assumption will fail [Dewer02]
Capabilities planning consists of several core processes to
describe the system capabilities in the absence of the
specific technical or operational requirements.
Discover what is not known by reaching a sufficient basic
knowledge level setting the problem space.
Identify problems by understanding the current process,
along with people and technology involved.
Establish boundaries and solution elements. These are
grouped into five categories:
1. Orientation principles align the process on a sound
theoretical basis issued from generally accepted practices
in the areas of engineering, modeling, and acquisition.
These principles include: Capability Thinking, Architecture
Models, Evolutionary Development, and Deliverables
Centric planning.
2. Communication principles enforce the standardization of
vocabulary and structure of information to be exchanged
within or outside the process.
These include: Standardized Formats and Common
Terminology to describes the system capabilities.
3. Collaboration principles enable active and timely
participation of all stakeholders involved in the
engineering of a capability.
These include: Collaborative Engineering and Information
Sharing between the contributors of the system capability
elements.
ChapterII
60
Capabilities Drive System Requirements
¨ Establish the system capabilities by describing the fundamental ideas about the
system through the operational behavior.
¨ Do this before the technical and process requirements are elicited.
¨ Use these Operational Concepts (OC) to describe how the system achieves the
beneficial outcomes before any commitments are made to the implementation.
¨ Use a Capabilities Based Assessment (CBA) to define gaps in the current system and
the approaches to providing capabilities within a specified functional or operational
concept.
¨ Construct three capability assessments: Functional Area Analysis, Functional
Needs Analysis, and Functional Solutions Analysis.
¤ Functional Area Analysis (FAA) is a capabilities based task analysis that provides the
framework for assessing required capabilities for the success of the system.
¤ Functional Needs Analysis (FNA)assesses the ability of the current system to accomplish
the needed tasks identified in the FAA, in the manner prescribed by the concept under the
operating conditions and to prescribed standards.
¤ Functional Solutions Analysis (FSA) is an operationally based assessment of the
potential strategies, organizations, training, leadership and education, personnel, facilities,
and materials (technologies) for solving open of more of the capability needs.
ChapterII
61
Requirements Identify Technical And
Process Deliverables
Inadequate requirements engineering is a common problem
in the development of any complex system.
There are many issues associated with requirements
engineering, including failure to define the system scope,
failure to foster understanding among the different
communities affected by the development of a given system,
and failure to deal with the volatile nature of requirements.
These problems lead to poor requirements and the
cancellation of development, or else the development of a
system that is later judged unsatisfactory or unacceptable,
has high maintenance costs, or undergoes frequent changes.
[Young04], [Grady06]
By improving requirements elicitation, the requirements
engineering process can be improved, resulting in enhanced
system requirements and potentially a much better system.
Requirements engineering is decomposed into the activities
of requirements elicitation, specification, and validation. Most
of the requirements techniques and tools today focus on
specification, i.e., the representation of the requirements.
The Deliverables Based Planning approach concentrates on
elicitation concerns, those problems with requirements
engineering that are not adequately addressed by
specification techniques.
The elicitation methodology to handle these concerns. Is
provided by [Cristel92].
Whatever the actual process used, the following activities
are fundamental to all Requirement Engineering
processes:[Sommerville05]
§ Elicitation – Identify sources of information about the
system and discover the requirements from these.
§ Analysis – Understand the requirements, their overlaps,
and their conflicts.
§ Validation – Go back to the system stakeholders and
check if the requirements are what they really need.
§ Negotiation – Inevitably, stakeholders’ views will differ,
and proposed requirements might conflict. Try to reconcile
conflicting views and generate a consistent set of
requirements.
§ Documentation – Write down the requirements in a way
that stakeholders and software developers can understand.
§ Management – Control the requirements changes that will
inevitably arise.
ChapterII
62
Requirements Identify Technical And
Process Deliverables
¨ Derive the system requirements for each system capability.
¨ Assure a requirement exists for each system capability needed to fulfill the
mission of the system.
¨ Develop the traceability from capabilities to requirements to produce a
“minimalist” system, with each requirement being present only because of a
needed system or mission capability.
¨ Test requirements by answering the question “why do we need this feature,
function, service, or capability?”
¨ Create Technical Performance Measures: [IEEE 1220]
¤ High priority requirements that have an impact on: mission accomplishment,
customer satisfaction, cost, system usefulness.
¤ High risk requirements or those where the desired performance is not currently
being met: the system uses new technology, new constraints have been added,
the performance goal has been increased, but the performance is expected to
improve with time.
¤ Requirements where performance can be controlled.
¤ Requirements where the program manager is able to rebalance cost, schedule
and performance.
ChapterII
63
Work Packages Describe Production Of
Deliverables
Staying focused on decomposing the system capabilities into
clearly defined streams of functionality is a critical success
factor. This effort decouples the technical functionality from
the system capabilities – increasing cohesion and reducing
coupling between each stream.
This decomposition is almost never optimal the first time
around. The false sense of urgency to decompose the system
requirements into a Work Breakdown Structure will cause
extra work later on. Investing in a carefully developed WBS
will pay back later in the program by isolating the work
processes into supporting value streams.
There is no set of instructions on how to do this. But starting
the WBS in a graphical form, putting that diagram on the
wall and asking coupling and cohesion questions about the
terminal nodes in the WBS is one way to “test” to goodness
of the WBS.
The construction of the Work Breakdown Structure (WBS)
starts with the decomposition of the requirements into
collections of deliverables. Focusing on the deliverables is
critical.
The Work Packages that result from this decomposition are
the vehicles for producing the deliverables.
When these deliverables exist they provide the capabilities
requested by the system to perform it function.
All resources – internal and external, their dependencies,
and any other items needed to produce the deliverables –
are defined in Work Packages. The Work Package Manager
is accountable for managing all these resources.
If resources are not under the control of the Work Package
Manager, the risk to the success of the deliverables is greatly
increased, because …
Accountability is no longer traceable to a single person –
violating the principles of the Responsibility Assignment
Matrix.
Performance reporting for Physical Percent Complete is no
longer represented by tangible items within Wok Package.
Each Work Package produces one deliverable. This
deliverable may have a Technical Performance Measure
attached – a Measure of Performance (MoP) or Measure of
Effectiveness (MoE). These Technical Performance Measures
connect the dots between Cost, Schedule, and Technical
maturity of the deliverable.
In the absence of Technical Performance Measures, the
Performance Measurement Baseline lacks the ability to
connect physical percent complete with the increasing
maturity of the product or service.
ChapterII
64
Work Packages Describe Production Of
Deliverables
¨ Use the Work Packages (WP) executable tasks to produce deliverables at the
conclusion of each WP duration.
¨ Avoid connections between WPs that are not Finish‒to‒Start at the WP
boundaries, this “hides” dependencies.
¨ Work contained in the WP produces a single or small number of deliverables.
¨ Use performance measures at the Work Package level to assess the progress
of the increasing maturity of the deliverables produced by each WP.
¨ Do not measure effort, the passage of time, or consumption of resources as
assessments of progress.
¨ Use apportioned milestones, 0%/100%, 50%/50%, and other forms of
incremental physical progress as a credible measures of percent complete at
the WP level.
¨ When performance measures of actual delivered value are used, the physical
progress of the program becomes a credible measure success.
¨ Measuring Earned Value for each task within the WP may be of little value for
the program without a measure of Technical Performance (Measures of
Effectiveness and Measures of Performance).
ChapterII
65
Master Schedule Sequences Deliverables,
and Work Packages in a Network
Arranging the Work Packages in a logical network is an iterative
process. It should be obvious which major deliverables come first,
second and later.
Building an initial network, plotting that network in the Big Visible
Chart, hanging that chart on the wall and standing in front of it
with all the Work Package Managers is part of developing a
credible PLAN for the program.
The PLAN is the strategy for delivering the business capabilities
the customer asked for. With the Big Visible Chart, this strategy is
made visible – or at least more visible than a list of Work
Packages.
The strategy for delivering the program should be mapped out in
some wall walk manner to make the connections obvious.
This hands on approach is much better than burying the
relationships in a program plan or spread sheet.
Making the first cut is a hands on process. The arrangement of
Work Packages should start with some simple rules:
1. All relationships are Finish to Start. This initial arrangement
provides visibility into the dependencies that will drive
schedule compression. Non FS relationships create
opportunities to use partially complete work in future efforts,
resulting in “rework,” the predecessor efforts are complete.
2. There should be no “lead” or “lag” arrangements. These
create hidden dependencies and hidden schedule
compression.
3. The only constraints on the network should be a “Must Start
On” (MSO) for the start date and “As Soon As Possible”
(ASAP) for all other activities. Any other constraints create
hidden dependencies. This appears harsh at first, but is the
basis of an “ideal” schedule. Other constraints may be added
later, but only for necessary reasons, that are described in the
IMS Narrative.
4. The flow of Work Packages should create a description of the
increasing maturity of the products or services of the project –
not just the consumption of resources and production of
deliverables. This Maturity description should be meaningful to
the customer in terms of business capabilities.
At this point in time we will be able to perform the following
business capabilities.
5. Speaking in these terms, the customer gains insight into the
actual progress of the program. Speaking in consumption of
resources, production of code, passage of milestones is not
that meaningful to the customer
6. Point estimates of cost and schedule are meaningless without
the range of possibilities, the level of certainty in achieving
each value, and how these estimates impact the credibility
that the program will complete on time, on schedule, and with
the planned technical performance.
ChapterII
66
Master Schedule Sequences Deliverables,
and Work Packages in a Network
¨ Arrange Work Packages in an un–constrained Activity Network.
¨ This network is a description of the flow of increasing maturity of the product or service
resulting from the completion of each Work Package.
¨ This network answers the 6 critical questions needed for success:
¤ Who is responsible for performing this the work?
¤ What are the constituent components of the work and what is the evidence that they are complete?
¤ When is this the work required to be completed?
¤ Where will this work be performed?
¤ Why does this work need to be done?
¤ How does this support the acceptance of the product or service by the customer?
¨ Postpone the detailed scheduling until there is a credible WP process flow increases the
visibility into dependencies as well as programmatic and technical risk and its mitigation.
¨ Define the Exit criteria for each WP the describes what “done” looks like and what technical
maturity is needed to proceed to the next WP.
¨ The schedule of work within the WP can then be developed by the “owners” of the work effort
– the Work Package Manager (Control Account Manager).
¨ Cost, Schedule, and Technical Performance values must be described in statistical terms, within
a range of possible values and the probability of their occurrence.
ChapterII
67
Work Package Progress is Measured as
Physical % Complete Against Plan
Measuring progress to plan can ONLY be done with Physical
Percent Complete (PPC).
Any other measure of progress can not be connected to the
delivery of business value to the customer. This is the basis of
Earned Value and it is also the basis of Agile Software
Development methodologies. Deliver working code at all
times.
Using the 0% /100% assignment or the Apportioned
Milestone assignment, the Physical Percent Complete is
multiplied by the Budgeted Cost of Work Scheduled
(Planned Value, PV) for the entire Work Package to produce
the Budgeted Cost of Work Performed (Earned Value, EV).
PMI has used BCWP(EV) = PPC X Budget at Completion,
where BAC = Sum(all Work Packages BCWS)
This is the ONLY way BCWP(EV) can be produced. Any other
way creates an invalid baseline measure of progress to plan.
With the Work Packages defined, the BCWS(PV) spreads
for each Work Packages established and the Work
Packages assembled into a credible network, a Performance
Measurement Baseline can be established.
Step by Step check list for setting the baseline:
1. All BCWS spreads have been balanced against
available resources for that Work Package and the
program as a whole. This is a long, difficult and very
unpleasant process. But letting a scheduling tool do this
work has several undesirable outcomes:
§ The longest date usually results, since the tool spreads
the resources according to their availability.
§ The planners of the program will not actually
understand the resource spreads assigned by the
machine
§ The day to day decisions of assigning work will now
be removed from those who can make the decisions
§ The visibility into the logical process of assigning work
is lost and the planners are simple observers
2. All Work Packages have apportioned milestones, 0/100,
50/50, or 25/75 assignments of Earned Value
(BCWP)(EV)
3. All data fields in the schedule have been assigned and
checked
ChapterII
68
Work Package Progress is Measured as
Physical % Complete Against Plan
¨ Measure progress as Physical Percent Complete to provide a credible assessment of
the increasing maturity of the delivered product or service.
¨ Use each work activity in the Work Package to provide some form of progress
toward producing the deliverable.
¨ Use this progress as an incremental measure of the overall progress of the Work
Package.
¨ Predefine how each work effort contributes to the overall progress of the Work
Package.
¨ Have the Work Package owner describe the incremental Physical Percent Complete
is terms of tangible evidence of progress to plan.
¨ Assure what “done” looks like is defined in terms of the Physical Percent Complete
of the Work Package, Measures of Effectiveness, and Measures of Performance.
¨ Capture this definition in the Work Package documentation.
¨ Ask the question:
¤ How Long Are You Willing to Wait Before You Find Out You Are Late?
¨ Measure physical progress to plan soon enough before that period of performance
arrives, so management corrections can be made to stay on cost, schedule and
technical performance.
ChapterII
69
Work Authorization Assures Work
Packages Produce Planned Progress
The work authorization system is used by the program
manager and his or her designees in order to approve all
work throughout the course of the current program
management venture.
The work authorization system will typically be in the form of
a list of formally adopted and well‒ documented
procedures. Work authorization procedures specifically
detail who may authorize work to be completed and how
those authorizations may be obtained.
These procedures will include which documents must be
completed prior to work being initialized, and whether there
are any other prerequisites to work being performed at any
particular level during the program. To better assist the
efficiency of program management in larger programs, work
authorization systems sometimes detail the timeline of the
program.
For instance, the work authorization system might include at
which points in time certain portions of the program should
be completed, in which order those tasks are to be
completed, and by whom.
It is important for program management to be aware of how
they convey the work authorization to their staff. To ensure
that spoken words are not misinterpreted, written directions
for the Work Packages provide explicit guidance.
The Work Package can be anything which might need to be
accomplished to produce a deliverable.
By providing a written work authorization, those in program
management can be assured that their wish to have the job
done by the right people, at the correct time, and in the right
order.
The Project Manager needs to be cautious to write out the
exact steps on the work authorization. This prevents
misunderstandings and mistakes along the line. To have the
work done correctly the first time, the manager must have
good communication skills with his workers, both in the writing
of the authorization and in answering any questions which
might arise. Proper direction given to employees in the work
permitting directive will ensure that the task is completed in
the expected manner.
ChapterII
70
Work Authorization Assures Work
Packages Produce Planned Progress
¨ Executing the Work Packages (WP) in the agreed sequence assures
the program proceeds as planned.
¨ This approach starts with a Work Authorization and control
processes and continually monitors, Late Starts, Late Finishes,
Schedule Margin erosion, and Technical Performance Measure
compliance.
¨ Work Authorization does not inhibit the performance of work, but
assures that work is performed in the planned sequence with the
planned programmatic risk reduction, to continuously increase the
maturity of the product or service.
¨ “Out of sequence work” creates programmatic and technical risks:
¤ It disrupts the Earned Value calculations – work without a budget in the
planned period is an overrun. Planned budget without actual work being
performed is recorded as an under run. In both cases EV is reported
improperly.
¤ The strategy developed for sequencing work to increase the maturity of
the product or service is disrupted.
ChapterII
71
Earned Value Describes Current
Performance
From the ANSI‒748 Guideline:
§ The Earned Value Management System (EVMS)
incorporates business best practices to provide strong
benefits for program or enterprise planning and control.
§ The processes include integration of the program scope,
schedule, and cost objectives, establishment of a baseline
plan for accomplishment of program objectives and the use
of earned value techniques for performance measurement
during the execution of the program.
§ The EVMS provides a sound basis for problem
identification, corrective actions, and management
replanning as may be required.
§ Any Earned Value Management System must:
§ Plan all work scope for the program through completion.
§ Integrate program work scope, schedule, and cost
objectives into a baseline plan against which
accomplishments can be measured.
§ Objectively assess accomplishments at the work
performance level.
§ Analyze significant variances from the plan and forecast
impacts.
§ Provide data to higher levels for management decision
making and implementation of management actions.
For the benefits of Earned Value to be fully realized,
thorough planning, combined with the establishment and
maintenance of a baseline for performance measurement is
needed.
The combination of advanced planning, baseline
maintenance, and earned value yields earlier and better
visibility into program performance than is provided by
non‒integrated methods of planning and control.
The key to success is to establish the performance baseline at
the Work Package level. The Work Package is the point at
which work is planned, progress is measured, and earned
value computed.
ChapterII
72
Earned Value Describes Current
Performance
¨ Recognize Earned Value is cost based. Cost Variance and Schedule
Variance have the same units of measure – Dollars.
¨ Use the To Complete Performance Index (TCPI) and the Independent
Estimate At Completion (IEAC) as measures of progress derived from
Earned Value. But they are also measured in dollars.
¨ Using the TCPI and IEAC, the program manager has visibility into the
work performance needed to stay on schedule and the forecast cost
of this effort.
¨ Recognize the credibility of these indices depends on the credibility
of the underlying earned value numbers. This is the primary
motivation for maintaining good data on the program. Otherwise
the Earned Value numbers are not only wrong, they provide no real
value for guiding management in decisions that impact the future
performance of the program.
¨ Consider using Earned Schedule [ES] to complement Earned Value
[PMI EV]. Earned Schedule is a method of deriving schedule
performance from Earned Value data [Lipke], [Henderson04],
[Vanhoucke]
ChapterII
73
Conformance With Technical Performance
Measures Adjusts EV Performance Values
Technical Performance Measures (TPMs) are traditionally
defined and evaluated to assess how well a system is
achieving its performance requirements.
Typically, dozens of TPMs are defined for a system. Although
they generate useful information and data about a system’s
performance, little is available in the program management
community on how to integrate these measures into a
meaningful measure of the system’s overall performance risk.
TPMs may be combined to measure and monitor the overall
performance risk of a system. The approach consists of
integrating individual technical performance measures in a
way that produces an overall risk index.
The Program Manager must be cognizant of three basic
program elements (baselines):
§ Cost
§ Schedule
§ Technical Performance
The first two are tracked through cost and schedule control
systems (earned value).
The last is tracked through the technical performance
measurement (TPM) system. TPM is the program manager’s
early warning system, when correlated to cost and schedule
reports, to provide the complete status of the program.
The TPM method includes selecting Technical Performance
Parameters; assigning weights; linking to CWBS; planning
progress over time; getting data; evaluating variances; and
taking corrective action as needed.
Variances indicate level of risk and detect new risks before
their effects on cost/schedule are irrevocable. The TPM
approach involves:
§ Assessing technical characteristics of the system and
identify problems through tests/analyses.
§ Surfacing inadequacies in time and dollars.
§ Complements cost/schedule performance measurement
§ Providing a basis for cost/schedule revisions.
§ Facilitating the verification of results achieved against
technical requirements and what remaining technical work
can be accomplished within established budgets.
ChapterII
74
Conformance With Technical Performance
Measures Adjusts EV Performance Values
¨ Adjust the “Earned Value” forecast of future performance by the
compliance with Technical Performance Measures (TPM).
¨ Correlate Technical Performance Measures with cost and schedule to
provide the complete status of the program.
¨ Use Technical Performance Measures to add “technical achievement”
to Earned Value’s cost and schedule metrics.
¨ Assess the program’s progress in terms of technical compliance,
potential rework, postponed functionality (to later Work Packages
or rolling waves) and other dilutions of the physical progress of the
program.
¨ Use Technical Performance Parameters (TPPs) to indicate key areas
for risk reduction and program success.
¨ Technical Performance Measures (TPMs) are a time–phased progress
plan for achievement of critical TPPs.
ChapterII
75
Performance Feedback Used To Adjust WP
Sequence and Resource Allocation
Earned Value Management (EVM) is a program management
tool integrates Cost and Schedule parameters as an early
warning system for future performance of the program.
But the EVMS standard states that EV is a measurement of
quantity (BCWP), not quality, of the work accomplished.
As far back as 1997, the discussion was integrating Cost,
Schedule, and Technical Performance. Robust systems
engineering and software engineering processes should
provide technical performance measures (TPM) and exit
criteria for assessing technical maturity that are
quantitatively linked to Earned Value.
Adjusting the To Complete Performance Index (TCPI) and the
Independent Estimate At Complete (IEAC) for less than
planned technical performance measurements – quality,
missing scope, delayed scope, or combinations of these and
other less than planned outcomes.
These TPMs are defined and evaluated to assess how well a
system is achieving its performance requirements. Technical
performance measurement uses actual or predicted values
from engineering measurements, tests, experiments or
prototypes.
The introduction the Earned Value Management Intent Guide
speaks to this but better guidance is needed [Solomon].
To provide the needed feedback for adjusting the TCPI and
IEAC values , the following activities need to be performed:
§ Include systems engineering activities in the schedule and
the Performance Measurement Baseline (PMB).
§ Establish thresholds or parameters for TPM in the program
plan.
§ Specify objective measures of progress as base measures
for EVM for: Development maturity to date, product’s
ability to satisfy requirements, Product metrics, including
TPM achievement‒to‒date.
§ Review program’s plans, activities, work products and
performance measurement baseline for consistency with
the requirements and the changes made to the
requirements baseline.
§ Incorporate risk mitigation plans in the program plan,
including changes to the PMB.
§ Include quantified risk assessments in the EAC depending
on the probability of risk occurrence and the impact on
cost objectives.
With this information, TCPI and IEAC can be adjusted to
reflect the Physical Percent Complete of the Work Packages,
not just the Cost and Schedule performance measures.
ChapterII
76
Performance Feedback Used To Adjust WP
Sequence and Resource Allocation
¨ Adjust the Work Package sequence using feedback from the performance
measures to maintain compliance with the Measures of Effectiveness (MoE),
Measures of Performance (MoP), and Technical Performance Measures
(TPM).
¨ TPM methodology includes:
¤ Selecting TPPs; assigning weights; linking to CWBS; planning progress over time;
getting data; evaluating variances; and taking corrective action as needed.
¤ Variances can indicate level of risk and detect new risks before their effects on
cost/schedule are irrevocable.
¨ Assess of the technical performance characteristics of the system to identify
problems by:
¤ Having assessments coincide with cost reporting and completion of significant
design tasks.
¤ Surfacing inadequacies in time and dollars.
¤ Complementing the standard cost/schedule performance measurement.
¤ Providing the basis for cost/schedule revisions.
¤ Facilitating the verification of results achieved against technical requirements
and that remaining technical work can be accomplished within established
budgets.
ChapterII
77
Forecast Of Future Performance Based On
TCPI, IEAC, and Work Sequence
Employing Earned Value Management can present a
program with data not available with any other
management tool. And while each metric can be useful, there
are two metrics are particularly useful in the management of
any project, or program, or a portfolio of projects.
The Cost Performance Index (CPI) is a reflection of program
cost efficiency. The CPI relates the physical work
accomplished, expressed in its budgeted value, against the
actual costs incurred to accomplish the performed work.
Budgets can be set with various monetary values, hours,
deliverables, or anything else that can be measured.
The question: Is the program staying on target, under
running, or perhaps overrunning costs?
Perfect cost performance would be defined as achieving a
CPI of 1.0: For every dollar spent, we would get an EV equal
to one dollar. Sometimes we do better, sometimes worse. This
is a particularly critical metric to track because performance
at less than 1.0 is a reflection of excessive costs spent
against budget.
Initial overruns are typically non‒recoverable. Think about it:
In order to recover an overrun, future work must be underrun.
Rarely does this happen. The same conditions which may
have caused the overrun in the first place are likely to occur
again and again.
The CPI is an indicator of past cost performance, the TCPI
has its focus on future performance.
The question: What will it take to meet the goals set by
management? The TCPI works in conjunction with the CPI.
TCPI = Work Remaining / Funds Remaining
The CPI can be thought of as sunk‒costs; whatever the
results, they cannot be altered. The TCPI is the efficiency
needed to regain the lost performance from the past.
ChapterII
78
Forecast Of Future Performance Based On
TCPI, IEAC, and Work Sequence
¨ Develop a new forecast of cost and schedule with the new
sequence of Work Packages.
¨ Base this forecast on the To Complete Performance Index (TCPI)
and the Independent Estimate At Complete (IEAC)
[Henderson08].
¨ There are five IEAC indices.
¤ IEAC1 = BAC / CPI
¤ IEAC2 = ACWP + (BAC – BCWP) / SPI
¤ IEAC3 = ACWP + (BAC – BCWP) / (SPI x CPI)
¤ IEAC4 = ACWP + (BAC – BCWP) / ((wt1 x SPI) + (wt2 x CPI))
¤ IEAC5 = ACWP + (BAC – BCWP) / CPIx
ChapterII
79
ChapterII
80
Deploying the five core
processes of Deliverables
Based Planning® is an
incremental and iterative
activity.
Each incremental step increases
the maturity of the project or
program deliverables.
81
IIIDeploying Deliverables Based
Planning®
Chapter
82
Putting The Five Core Processes of
Deliverables Based Planning® to Work
Define the set of capabilities needed to achieve the program objectives or the particular end state for
a specific scenario. Using the ConOps, define the details of who, where, and how it is to be
accomplished, employed and executed.
1
Define the technical and operational requirements that must be in place for the system capabilities to
be fulfilled. First, define these requirements in terms that are isolated from any implementation technical
products. Only then bind the requirements with technology.
2
Build a time–phased network of schedule activities describing the work to be performed, the budgeted
cost for this work, the organizational elements that produce the deliverables, and the performance
measures showing this work is proceeding according to plan.
3
Execute work packages, while assuring all performance assessment are 0%/100% complete
before proceeding. No rework, no forward transfer of activities to the future. Assure every
requirement is traceable to work and all work is traceable to requirements.
4
Perform the 6 process areas of Continuous Risk Management for each Deliverables Based
Planning® process area to Identify, Analyze, Plan, Track, Control, and Communicate programmatic
and technical risk
5
Chapter III
Define the set of capabilities needed to achieve the program objectives or the particular end
state for a specific scenario. Using the ConOps, define the details of who, where, and how it
is to be accomplished, employed and executed.
Process Activities Outcomes or Deliverables Benefits
Using the supplied Statement of Work (SOW),
Statement of Objectives (SOO) extract a
description of the operational behavior of the
system in a Concept of Operations (ConOps)
and an associated process flow diagram.
A Process Flow Diagram of the system with
verbs in the boxes and nouns on the lines.
This can be done in Visio using the IDEFÆ
notation, or some other systems engineering
process and element diagramming method
[IDEFÆ].
A single diagram showing the system
components, the data or actions it produces,
and how these components interact.
This diagram shows the increasing maturity of
the system as is proceeds from left to right in
the Integrated Master Plan (IMP), through each
Program Event.
With the Process Flow Diagram, identify the
Accomplishments for each Milestone or Event.
Identify the dependencies between each
Accomplishment within and between the
Integrated Product Team (IPT) stream.
For each Event or Milestone, build a single
page chart for each Accomplishment for each
Integrated Product Team (IPT) members work
stream.
These diagrams show how each Event or
Milestone will be met from the completion of
the Accomplishment s.
With the dependencies identified, a top level
precedence diagram is now available for the
development of the Integrated Master
Schedule (IMS).
With each Accomplishment defined and
arranged in a sequence of increasing maturity
within the Event or Milestone, capture the
Criteria for the assessment of the
Accomplishment.
These Criteria are the “Exit Criteria” for the
Work Packages containing the Work Tasks.
The exit criteria for the work effort will be
defined in terms meaningful to the assessment
of Physical Percent Complete and the
completion of the Accomplishment.
Connections from Milestone or Event, to
Accomplishments and to the Criteria describe
the increasing maturity of the program.
This is more than just the traditional list of items
in the Integrated Master Plan. But a description
of the program’s process flow and its
increasing value.
1
Chapter III83
Define the technical and operational requirements that must be in place for the system
capabilities to be fulfilled. First, define these requirements in terms that are isolated from any
implementation technical products. Only then bound the requirements with technology.
Process Activities Outcomes or Deliverables Benefits
Identify the end user and system functional
requirements through a requirements flow
down process in some type of database
system.
This doesn’t have to be a large scale tool, but
it must provide some sort of change control
and tracking of the requirements.
In order to make requirements trade offs,
the requirements must be organized in a
logical manner.
Starting organized, keeping organized, and
tracing changes to the requirements is part
of the requirements elicitation and
management processes.
Keeping requirements under control is a critical
success factor for controlling the scope of the
program.
Not changes to the requirements baseline can be
made without on impact assessment.
Build a Requirements Traceability Matrix
between the SOW, SOO, ConOps, CDRLs, DID’s
and any other document containing
requirements.
Place these requirements in a database so
“pivots” and “coverage” assurance can
made between all the sources.
There may be conflicting requirements on the
program. This will never be known early if all the
requirements are not in one place, under the
control of the Change Board
The requirements elicitation process has five (5)
steps:
§ Fact finding
§ Gathering and Classifying
§ Evaluation and Rationalization
§ Prioritization
§ Verification and Validation
These must be performed in an iterative,
incremental, and logical sequence, capturing
the resulting “emergence” of the requirements
baseline through each cycle.
A requirements system model that captures
facts, classifications, evaluation,
rationalizations, prioritizations, and
verifications in a Requirements Management
Database of some form.
By organizing the requirements in the form of a
database is a critical success factor for the
program.
With this database, traceability of the
requirements from the system capabilities to the
technical and operational deliverables.
Only by building these traceability relationships,
can trade offs be made in the presence of
distributions in the program due to funding,
requirements, and technical changes.
2
Chapter IIIChapter III84
Build a time–phased network of schedule activities describing the work to be performed, the
budgeted cost for this work, the organizational elements that produce the deliverables, and
the performance measures showing this work is proceeding according to plan.
Process Activities Outcomes or Deliverables Benefits
Using the Events or Milestones, Significant
Accomplishments, Accomplishment Criteria,
the Work Packages and Planning Packages
are constructed for each Accomplishment
Criteria.
These Work Packages are the starting point
for the Integrated Master Schedule
The Work Packages contain the resources
and work activities needed to produce a
deliverable represented by the
Accomplishment Criteria – the outcome of
the Work Package.
An Integrated Master Schedule (IMS) for the work
effort needed for each Accomplishment Criteria is
the starting point for optimizing the program
execution description.
The IMS describes the work activities needed to
increase the maturity of the delivered product or
service.
The Exit Criteria for these work activities are
measured by the Accomplishment Criteria – the
measureable outcome of each Work Package.
The Accomplishment Criteria are the entry
conditions for the Significant Accomplishments.
The Significant Accomplishments describe the
current maturity of the deliverables in units of
measure defined during the development of the
Integrated Master Plan (IMP).
The increasing maturity of the program can be
measured through assessments of Physical
Percent Compete. These units of measure are
derived from the Technical Performance
Measures of the delivered article at the
specific time point in the schedule.
By connecting cost, schedule, and technical
performance in a time–phased assessment
process, the Program Manager will have insight
into the progress of the program, not just as
assessment of cost and schedule performance.
With the sequenced Work Packages, the
labor and other direct costs are applied to
the Integrated Master Schedule (IMS).
This Labor and Cost Spread reveal speaks and
valleys in the labor assignments. These must be
smoothed to match the actual labor availability
before further analysis of the IMS can take place.
An “all in” IMS contains all work, all resources,
all dependencies , all risk mitigation and
retirement plans, and all assessment processes
of the increasing maturity of the program.
With the IMS in place, budget spreads are
“balanced “ across the collection of Work
Packages to meet the objective measures of
the organization and the technology
BCWS balanced spreads across the current
rolling wave and across planning packages.
Visibility into the budget demands and labor
utilization for ach rolling wave and planning
packages.
3
Chapter IIIChapter III85
Execute work packages, while assuring all performance assessment are 0%/100%
complete before proceeding. No rework, no forward transfer of activities to the future.
Assure every requirement is traceable to work and all work is traceable to requirements.
Process Activities Outcomes or Deliverables Benefits
The duration between measurements of
progress must be tuned to the business rhythms
of the program.
A simple question is how long are you willing to
wait before you find out you are too late to take
corrective action?
Periodic Business Rhythm Meetings where a
simple Status Report is reviewed and forecasts
for the performance in the next period are
committed to.
Measuring progress in physical percent
complete units provide visibility in ways not
possible with simple measures of cost and
schedule.
Coupling cost, schedule, and technical
performance is the basis of Performance Based
Earned Value
Define the Business Rhythm to provide timely
insight into the progress of the program. This
should be a minimum of a monthly
performance report.
A published Business Rhythm Process Flow with
deliverables, data sources, work processes,
accountabilities, and an archive for this
information.
Bi–weekly and monthly measures of
performance are used to guide management
decisions.
Capturing the physical percent complete starts
with defining the agree on units of measure of
performance for each Work Package (WP)
allocated to the Control Account. These
measures must match the technical assessment
of the products or services provided from the
WP.
Apportioned milestones, 0/100% complete
descriptions and other measures of Physical
Percent Complete are defined in the WBS
Dictionary.
Measurements of progress are done through
evidentiary materials – artifacts from the
program that can be “seen” by the program
stakeholders, rather than just “reported” on.
By connecting cost, schedule and technical
performance in the assessment of progress can
the program determine how is it progressing,
how efficient the resources are working and
what the risk adjust Estimate to Complete is.
Project status report that measures the Physical
Percent Complete for Apportioned Milestones,
0/394 deliverables or other evidentiary
materials of progress.
Defining these measures “before” the execution
of the WPs provides a baseline for
measurement of Physical Percent Complete.
4
Chapter IIIChapter III86
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook
Deliverables based planning handbook

More Related Content

What's hot

Deliverables Based Planning
Deliverables Based PlanningDeliverables Based Planning
Deliverables Based Planning
Glen Alleman
 
5 Immutable Principles of Capital Project SUccess
5 Immutable Principles of Capital Project SUccess5 Immutable Principles of Capital Project SUccess
5 Immutable Principles of Capital Project SUccess
Glen Alleman
 
Improving Project Performance in the DOE
Improving Project Performance in the DOEImproving Project Performance in the DOE
Improving Project Performance in the DOE
Glen Alleman
 
CMMI and Agile
CMMI and AgileCMMI and Agile
CMMI and Agile
Glen Alleman
 
Performance based planning in a nut shell (V5)
Performance based planning in a nut shell (V5)Performance based planning in a nut shell (V5)
Performance based planning in a nut shell (V5)
Glen Alleman
 
Performance Based Management Handbook
Performance Based Management HandbookPerformance Based Management Handbook
Performance Based Management Handbook
Glen Alleman
 
EDM/PDM Implementation
EDM/PDM ImplementationEDM/PDM Implementation
EDM/PDM Implementation
Glen Alleman
 
EVM+Agile the darkside
EVM+Agile the darksideEVM+Agile the darkside
EVM+Agile the darkside
Glen Alleman
 
PGCS 2019 Master Class Integrating SE with PPM
PGCS 2019 Master Class Integrating SE with PPMPGCS 2019 Master Class Integrating SE with PPM
PGCS 2019 Master Class Integrating SE with PPM
Glen Alleman
 
A Guide for Capital Project Mamnagers
A Guide for Capital Project MamnagersA Guide for Capital Project Mamnagers
A Guide for Capital Project Mamnagers
Glen Alleman
 
Six ½ Day Sessions on the Road To Becoming a CAM
Six ½ Day Sessions on the Road To Becoming a CAMSix ½ Day Sessions on the Road To Becoming a CAM
Six ½ Day Sessions on the Road To Becoming a CAM
Glen Alleman
 
Scrum lifecycle for Enterprise IT
Scrum lifecycle for Enterprise ITScrum lifecycle for Enterprise IT
Scrum lifecycle for Enterprise IT
Glen Alleman
 
Building the perfect schedule (v6)
Building the perfect schedule (v6)Building the perfect schedule (v6)
Building the perfect schedule (v6)
Glen Alleman
 
IMP IMS overview
IMP IMS overviewIMP IMS overview
IMP IMS overview
Glen Alleman
 
A Workshop for Product Owners, Scrum Masters, and Team Members for Improving ...
A Workshop for Product Owners, Scrum Masters, and Team Members for Improving ...A Workshop for Product Owners, Scrum Masters, and Team Members for Improving ...
A Workshop for Product Owners, Scrum Masters, and Team Members for Improving ...
Glen Alleman
 
Process Flow and Narrative for Agile+PPM
Process Flow and Narrative for Agile+PPMProcess Flow and Narrative for Agile+PPM
Process Flow and Narrative for Agile+PPM
Glen Alleman
 
Process Flow and Narrative for Agile
Process Flow and Narrative for AgileProcess Flow and Narrative for Agile
Process Flow and Narrative for Agile
Glen Alleman
 
Integrated Master Plan Development
Integrated Master Plan DevelopmentIntegrated Master Plan Development
Integrated Master Plan Development
Glen Alleman
 
Project Success: The Basis of the Five Immutable Principles
Project Success: The Basis of the Five Immutable PrinciplesProject Success: The Basis of the Five Immutable Principles
Project Success: The Basis of the Five Immutable Principles
Glen Alleman
 
SOLVING PROJECT ALLOCATION RESOURCE PROBLEMS WITH AEROSPACE ERP
SOLVING PROJECT ALLOCATION RESOURCE PROBLEMS WITH AEROSPACE ERPSOLVING PROJECT ALLOCATION RESOURCE PROBLEMS WITH AEROSPACE ERP
SOLVING PROJECT ALLOCATION RESOURCE PROBLEMS WITH AEROSPACE ERP
Kevin West
 

What's hot (20)

Deliverables Based Planning
Deliverables Based PlanningDeliverables Based Planning
Deliverables Based Planning
 
5 Immutable Principles of Capital Project SUccess
5 Immutable Principles of Capital Project SUccess5 Immutable Principles of Capital Project SUccess
5 Immutable Principles of Capital Project SUccess
 
Improving Project Performance in the DOE
Improving Project Performance in the DOEImproving Project Performance in the DOE
Improving Project Performance in the DOE
 
CMMI and Agile
CMMI and AgileCMMI and Agile
CMMI and Agile
 
Performance based planning in a nut shell (V5)
Performance based planning in a nut shell (V5)Performance based planning in a nut shell (V5)
Performance based planning in a nut shell (V5)
 
Performance Based Management Handbook
Performance Based Management HandbookPerformance Based Management Handbook
Performance Based Management Handbook
 
EDM/PDM Implementation
EDM/PDM ImplementationEDM/PDM Implementation
EDM/PDM Implementation
 
EVM+Agile the darkside
EVM+Agile the darksideEVM+Agile the darkside
EVM+Agile the darkside
 
PGCS 2019 Master Class Integrating SE with PPM
PGCS 2019 Master Class Integrating SE with PPMPGCS 2019 Master Class Integrating SE with PPM
PGCS 2019 Master Class Integrating SE with PPM
 
A Guide for Capital Project Mamnagers
A Guide for Capital Project MamnagersA Guide for Capital Project Mamnagers
A Guide for Capital Project Mamnagers
 
Six ½ Day Sessions on the Road To Becoming a CAM
Six ½ Day Sessions on the Road To Becoming a CAMSix ½ Day Sessions on the Road To Becoming a CAM
Six ½ Day Sessions on the Road To Becoming a CAM
 
Scrum lifecycle for Enterprise IT
Scrum lifecycle for Enterprise ITScrum lifecycle for Enterprise IT
Scrum lifecycle for Enterprise IT
 
Building the perfect schedule (v6)
Building the perfect schedule (v6)Building the perfect schedule (v6)
Building the perfect schedule (v6)
 
IMP IMS overview
IMP IMS overviewIMP IMS overview
IMP IMS overview
 
A Workshop for Product Owners, Scrum Masters, and Team Members for Improving ...
A Workshop for Product Owners, Scrum Masters, and Team Members for Improving ...A Workshop for Product Owners, Scrum Masters, and Team Members for Improving ...
A Workshop for Product Owners, Scrum Masters, and Team Members for Improving ...
 
Process Flow and Narrative for Agile+PPM
Process Flow and Narrative for Agile+PPMProcess Flow and Narrative for Agile+PPM
Process Flow and Narrative for Agile+PPM
 
Process Flow and Narrative for Agile
Process Flow and Narrative for AgileProcess Flow and Narrative for Agile
Process Flow and Narrative for Agile
 
Integrated Master Plan Development
Integrated Master Plan DevelopmentIntegrated Master Plan Development
Integrated Master Plan Development
 
Project Success: The Basis of the Five Immutable Principles
Project Success: The Basis of the Five Immutable PrinciplesProject Success: The Basis of the Five Immutable Principles
Project Success: The Basis of the Five Immutable Principles
 
SOLVING PROJECT ALLOCATION RESOURCE PROBLEMS WITH AEROSPACE ERP
SOLVING PROJECT ALLOCATION RESOURCE PROBLEMS WITH AEROSPACE ERPSOLVING PROJECT ALLOCATION RESOURCE PROBLEMS WITH AEROSPACE ERP
SOLVING PROJECT ALLOCATION RESOURCE PROBLEMS WITH AEROSPACE ERP
 

Similar to Deliverables based planning handbook

Heliotropic Abundance
Heliotropic AbundanceHeliotropic Abundance
Heliotropic Abundance
Glen Alleman
 
Performance based management in a nut shell (v5)
Performance based management in a nut shell (v5)Performance based management in a nut shell (v5)
Performance based management in a nut shell (v5)
Glen Alleman
 
Connecting PMB® with PMBOK®
Connecting PMB® with PMBOK®Connecting PMB® with PMBOK®
Connecting PMB® with PMBOK®
Glen Alleman
 
Increasing the probability of project success using Earned Value Management
Increasing the probability of project success using Earned Value ManagementIncreasing the probability of project success using Earned Value Management
Increasing the probability of project success using Earned Value Management
Glen Alleman
 
5 immutable principles and 5 processes in 60 seconds
5 immutable principles and 5 processes in 60 seconds5 immutable principles and 5 processes in 60 seconds
5 immutable principles and 5 processes in 60 seconds
Glen Alleman
 
Integrating Agile and Earned Value Management
Integrating Agile and Earned Value ManagementIntegrating Agile and Earned Value Management
Integrating Agile and Earned Value Management
Glen Alleman
 
Earned Value Management and Agile
Earned Value Management and AgileEarned Value Management and Agile
Earned Value Management and Agile
Glen Alleman
 
Building a Credible Performance Measurement Baseline (v3)
Building a Credible Performance Measurement Baseline (v3)Building a Credible Performance Measurement Baseline (v3)
Building a Credible Performance Measurement Baseline (v3)
Glen Alleman
 
Agile in an ANSI-748-C environment
Agile in an ANSI-748-C environmentAgile in an ANSI-748-C environment
Agile in an ANSI-748-C environment
Glen Alleman
 
Breaking the Project Failure Cycle
Breaking the Project Failure CycleBreaking the Project Failure Cycle
Breaking the Project Failure Cycle
Glen Alleman
 
Five Immutable Principles of Project of Digital Transformation Success
Five Immutable Principles of Project of Digital Transformation SuccessFive Immutable Principles of Project of Digital Transformation Success
Five Immutable Principles of Project of Digital Transformation Success
Glen Alleman
 
Building a Credible Performance Measurement Baseline in Two Days
Building a Credible Performance Measurement Baseline in Two DaysBuilding a Credible Performance Measurement Baseline in Two Days
Building a Credible Performance Measurement Baseline in Two Days
Glen Alleman
 
How To Build A Credible Performance Measurement Baseline
How To Build A Credible Performance Measurement BaselineHow To Build A Credible Performance Measurement Baseline
How To Build A Credible Performance Measurement Baseline
Glen Alleman
 
How To Build A Credible Performance Measurement Baseline
How To Build A Credible Performance Measurement BaselineHow To Build A Credible Performance Measurement Baseline
How To Build A Credible Performance Measurement Baseline
guest9da059
 
Chapter 0 of Performance Based Project Management (sm)
Chapter 0 of Performance Based Project Management (sm)Chapter 0 of Performance Based Project Management (sm)
Chapter 0 of Performance Based Project Management (sm)
Glen Alleman
 
Ev+agile=success
Ev+agile=successEv+agile=success
Ev+agile=success
Glen Alleman
 
Jason uyderv pmi 2 16 12
Jason uyderv pmi 2 16 12Jason uyderv pmi 2 16 12
Jason uyderv pmi 2 16 12
Jason Uyder
 
Install pms in moccis - a proposal
Install pms in moccis - a proposalInstall pms in moccis - a proposal
Install pms in moccis - a proposal
Hj Arriffin Mansor
 
My Single Point project portfolio and demand
My Single Point project portfolio and demandMy Single Point project portfolio and demand
My Single Point project portfolio and demand
PHILIPPE CORNETTE
 
Del
DelDel

Similar to Deliverables based planning handbook (20)

Heliotropic Abundance
Heliotropic AbundanceHeliotropic Abundance
Heliotropic Abundance
 
Performance based management in a nut shell (v5)
Performance based management in a nut shell (v5)Performance based management in a nut shell (v5)
Performance based management in a nut shell (v5)
 
Connecting PMB® with PMBOK®
Connecting PMB® with PMBOK®Connecting PMB® with PMBOK®
Connecting PMB® with PMBOK®
 
Increasing the probability of project success using Earned Value Management
Increasing the probability of project success using Earned Value ManagementIncreasing the probability of project success using Earned Value Management
Increasing the probability of project success using Earned Value Management
 
5 immutable principles and 5 processes in 60 seconds
5 immutable principles and 5 processes in 60 seconds5 immutable principles and 5 processes in 60 seconds
5 immutable principles and 5 processes in 60 seconds
 
Integrating Agile and Earned Value Management
Integrating Agile and Earned Value ManagementIntegrating Agile and Earned Value Management
Integrating Agile and Earned Value Management
 
Earned Value Management and Agile
Earned Value Management and AgileEarned Value Management and Agile
Earned Value Management and Agile
 
Building a Credible Performance Measurement Baseline (v3)
Building a Credible Performance Measurement Baseline (v3)Building a Credible Performance Measurement Baseline (v3)
Building a Credible Performance Measurement Baseline (v3)
 
Agile in an ANSI-748-C environment
Agile in an ANSI-748-C environmentAgile in an ANSI-748-C environment
Agile in an ANSI-748-C environment
 
Breaking the Project Failure Cycle
Breaking the Project Failure CycleBreaking the Project Failure Cycle
Breaking the Project Failure Cycle
 
Five Immutable Principles of Project of Digital Transformation Success
Five Immutable Principles of Project of Digital Transformation SuccessFive Immutable Principles of Project of Digital Transformation Success
Five Immutable Principles of Project of Digital Transformation Success
 
Building a Credible Performance Measurement Baseline in Two Days
Building a Credible Performance Measurement Baseline in Two DaysBuilding a Credible Performance Measurement Baseline in Two Days
Building a Credible Performance Measurement Baseline in Two Days
 
How To Build A Credible Performance Measurement Baseline
How To Build A Credible Performance Measurement BaselineHow To Build A Credible Performance Measurement Baseline
How To Build A Credible Performance Measurement Baseline
 
How To Build A Credible Performance Measurement Baseline
How To Build A Credible Performance Measurement BaselineHow To Build A Credible Performance Measurement Baseline
How To Build A Credible Performance Measurement Baseline
 
Chapter 0 of Performance Based Project Management (sm)
Chapter 0 of Performance Based Project Management (sm)Chapter 0 of Performance Based Project Management (sm)
Chapter 0 of Performance Based Project Management (sm)
 
Ev+agile=success
Ev+agile=successEv+agile=success
Ev+agile=success
 
Jason uyderv pmi 2 16 12
Jason uyderv pmi 2 16 12Jason uyderv pmi 2 16 12
Jason uyderv pmi 2 16 12
 
Install pms in moccis - a proposal
Install pms in moccis - a proposalInstall pms in moccis - a proposal
Install pms in moccis - a proposal
 
My Single Point project portfolio and demand
My Single Point project portfolio and demandMy Single Point project portfolio and demand
My Single Point project portfolio and demand
 
Del
DelDel
Del
 

More from Glen Alleman

Managing risk with deliverables planning
Managing risk with deliverables planningManaging risk with deliverables planning
Managing risk with deliverables planning
Glen Alleman
 
A Gentle Introduction to the IMP/IMS
A Gentle Introduction to the IMP/IMSA Gentle Introduction to the IMP/IMS
A Gentle Introduction to the IMP/IMS
Glen Alleman
 
Increasing the Probability of Project Success
Increasing the Probability of Project SuccessIncreasing the Probability of Project Success
Increasing the Probability of Project Success
Glen Alleman
 
Practices of risk management
Practices of risk managementPractices of risk management
Practices of risk management
Glen Alleman
 
Principles of Risk Management
Principles of Risk ManagementPrinciples of Risk Management
Principles of Risk Management
Glen Alleman
 
Deliverables Based Planning, PMBOK® and 5 Immutable Principles of Project Suc...
Deliverables Based Planning, PMBOK® and 5 Immutable Principles of Project Suc...Deliverables Based Planning, PMBOK® and 5 Immutable Principles of Project Suc...
Deliverables Based Planning, PMBOK® and 5 Immutable Principles of Project Suc...
Glen Alleman
 
From Principles to Strategies for Systems Engineering
From Principles to Strategies for Systems EngineeringFrom Principles to Strategies for Systems Engineering
From Principles to Strategies for Systems Engineering
Glen Alleman
 
NAVAIR Integrated Master Schedule Guide guide
NAVAIR Integrated Master Schedule Guide guideNAVAIR Integrated Master Schedule Guide guide
NAVAIR Integrated Master Schedule Guide guide
Glen Alleman
 
Building a Credible Performance Measurement Baseline
Building a Credible Performance Measurement BaselineBuilding a Credible Performance Measurement Baseline
Building a Credible Performance Measurement Baseline
Glen Alleman
 
Integrated master plan methodology (v2)
Integrated master plan methodology (v2)Integrated master plan methodology (v2)
Integrated master plan methodology (v2)
Glen Alleman
 
IMP / IMS Step by Step
IMP / IMS Step by StepIMP / IMS Step by Step
IMP / IMS Step by Step
Glen Alleman
 
DHS - Using functions points to estimate agile development programs (v2)
DHS - Using functions points to estimate agile development programs (v2)DHS - Using functions points to estimate agile development programs (v2)
DHS - Using functions points to estimate agile development programs (v2)
Glen Alleman
 
Making the impossible possible
Making the impossible possibleMaking the impossible possible
Making the impossible possible
Glen Alleman
 
Capabilities based planning
Capabilities based planningCapabilities based planning
Capabilities based planning
Glen Alleman
 
Building the Performance Measurement Baseline
Building the Performance Measurement BaselineBuilding the Performance Measurement Baseline
Building the Performance Measurement Baseline
Glen Alleman
 
Program Management Office Lean Software Development and Six Sigma
Program Management Office Lean Software Development and Six SigmaProgram Management Office Lean Software Development and Six Sigma
Program Management Office Lean Software Development and Six Sigma
Glen Alleman
 
Project Management Theory
Project Management TheoryProject Management Theory
Project Management Theory
Glen Alleman
 
Seven Habits of a Highly Effective agile project manager
Seven Habits of a Highly Effective agile project managerSeven Habits of a Highly Effective agile project manager
Seven Habits of a Highly Effective agile project manager
Glen Alleman
 
Paradigm of agile project management (update)
Paradigm of agile project management (update)Paradigm of agile project management (update)
Paradigm of agile project management (update)
Glen Alleman
 
Integrating cost, schedule, and technical performance
Integrating cost, schedule, and technical performanceIntegrating cost, schedule, and technical performance
Integrating cost, schedule, and technical performance
Glen Alleman
 

More from Glen Alleman (20)

Managing risk with deliverables planning
Managing risk with deliverables planningManaging risk with deliverables planning
Managing risk with deliverables planning
 
A Gentle Introduction to the IMP/IMS
A Gentle Introduction to the IMP/IMSA Gentle Introduction to the IMP/IMS
A Gentle Introduction to the IMP/IMS
 
Increasing the Probability of Project Success
Increasing the Probability of Project SuccessIncreasing the Probability of Project Success
Increasing the Probability of Project Success
 
Practices of risk management
Practices of risk managementPractices of risk management
Practices of risk management
 
Principles of Risk Management
Principles of Risk ManagementPrinciples of Risk Management
Principles of Risk Management
 
Deliverables Based Planning, PMBOK® and 5 Immutable Principles of Project Suc...
Deliverables Based Planning, PMBOK® and 5 Immutable Principles of Project Suc...Deliverables Based Planning, PMBOK® and 5 Immutable Principles of Project Suc...
Deliverables Based Planning, PMBOK® and 5 Immutable Principles of Project Suc...
 
From Principles to Strategies for Systems Engineering
From Principles to Strategies for Systems EngineeringFrom Principles to Strategies for Systems Engineering
From Principles to Strategies for Systems Engineering
 
NAVAIR Integrated Master Schedule Guide guide
NAVAIR Integrated Master Schedule Guide guideNAVAIR Integrated Master Schedule Guide guide
NAVAIR Integrated Master Schedule Guide guide
 
Building a Credible Performance Measurement Baseline
Building a Credible Performance Measurement BaselineBuilding a Credible Performance Measurement Baseline
Building a Credible Performance Measurement Baseline
 
Integrated master plan methodology (v2)
Integrated master plan methodology (v2)Integrated master plan methodology (v2)
Integrated master plan methodology (v2)
 
IMP / IMS Step by Step
IMP / IMS Step by StepIMP / IMS Step by Step
IMP / IMS Step by Step
 
DHS - Using functions points to estimate agile development programs (v2)
DHS - Using functions points to estimate agile development programs (v2)DHS - Using functions points to estimate agile development programs (v2)
DHS - Using functions points to estimate agile development programs (v2)
 
Making the impossible possible
Making the impossible possibleMaking the impossible possible
Making the impossible possible
 
Capabilities based planning
Capabilities based planningCapabilities based planning
Capabilities based planning
 
Building the Performance Measurement Baseline
Building the Performance Measurement BaselineBuilding the Performance Measurement Baseline
Building the Performance Measurement Baseline
 
Program Management Office Lean Software Development and Six Sigma
Program Management Office Lean Software Development and Six SigmaProgram Management Office Lean Software Development and Six Sigma
Program Management Office Lean Software Development and Six Sigma
 
Project Management Theory
Project Management TheoryProject Management Theory
Project Management Theory
 
Seven Habits of a Highly Effective agile project manager
Seven Habits of a Highly Effective agile project managerSeven Habits of a Highly Effective agile project manager
Seven Habits of a Highly Effective agile project manager
 
Paradigm of agile project management (update)
Paradigm of agile project management (update)Paradigm of agile project management (update)
Paradigm of agile project management (update)
 
Integrating cost, schedule, and technical performance
Integrating cost, schedule, and technical performanceIntegrating cost, schedule, and technical performance
Integrating cost, schedule, and technical performance
 

Recently uploaded

Taking AI to the Next Level in Manufacturing.pdf
Taking AI to the Next Level in Manufacturing.pdfTaking AI to the Next Level in Manufacturing.pdf
Taking AI to the Next Level in Manufacturing.pdf
ssuserfac0301
 
"$10 thousand per minute of downtime: architecture, queues, streaming and fin...
"$10 thousand per minute of downtime: architecture, queues, streaming and fin..."$10 thousand per minute of downtime: architecture, queues, streaming and fin...
"$10 thousand per minute of downtime: architecture, queues, streaming and fin...
Fwdays
 
Your One-Stop Shop for Python Success: Top 10 US Python Development Providers
Your One-Stop Shop for Python Success: Top 10 US Python Development ProvidersYour One-Stop Shop for Python Success: Top 10 US Python Development Providers
Your One-Stop Shop for Python Success: Top 10 US Python Development Providers
akankshawande
 
Essentials of Automations: Exploring Attributes & Automation Parameters
Essentials of Automations: Exploring Attributes & Automation ParametersEssentials of Automations: Exploring Attributes & Automation Parameters
Essentials of Automations: Exploring Attributes & Automation Parameters
Safe Software
 
Biomedical Knowledge Graphs for Data Scientists and Bioinformaticians
Biomedical Knowledge Graphs for Data Scientists and BioinformaticiansBiomedical Knowledge Graphs for Data Scientists and Bioinformaticians
Biomedical Knowledge Graphs for Data Scientists and Bioinformaticians
Neo4j
 
Christine's Supplier Sourcing Presentaion.pptx
Christine's Supplier Sourcing Presentaion.pptxChristine's Supplier Sourcing Presentaion.pptx
Christine's Supplier Sourcing Presentaion.pptx
christinelarrosa
 
Fueling AI with Great Data with Airbyte Webinar
Fueling AI with Great Data with Airbyte WebinarFueling AI with Great Data with Airbyte Webinar
Fueling AI with Great Data with Airbyte Webinar
Zilliz
 
Freshworks Rethinks NoSQL for Rapid Scaling & Cost-Efficiency
Freshworks Rethinks NoSQL for Rapid Scaling & Cost-EfficiencyFreshworks Rethinks NoSQL for Rapid Scaling & Cost-Efficiency
Freshworks Rethinks NoSQL for Rapid Scaling & Cost-Efficiency
ScyllaDB
 
Skybuffer SAM4U tool for SAP license adoption
Skybuffer SAM4U tool for SAP license adoptionSkybuffer SAM4U tool for SAP license adoption
Skybuffer SAM4U tool for SAP license adoption
Tatiana Kojar
 
JavaLand 2024: Application Development Green Masterplan
JavaLand 2024: Application Development Green MasterplanJavaLand 2024: Application Development Green Masterplan
JavaLand 2024: Application Development Green Masterplan
Miro Wengner
 
Northern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
Northern Engraving | Modern Metal Trim, Nameplates and Appliance PanelsNorthern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
Northern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
Northern Engraving
 
Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...
Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...
Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...
saastr
 
Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving | Nameplate Manufacturing Process - 2024Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving
 
Monitoring and Managing Anomaly Detection on OpenShift.pdf
Monitoring and Managing Anomaly Detection on OpenShift.pdfMonitoring and Managing Anomaly Detection on OpenShift.pdf
Monitoring and Managing Anomaly Detection on OpenShift.pdf
Tosin Akinosho
 
Mutation Testing for Task-Oriented Chatbots
Mutation Testing for Task-Oriented ChatbotsMutation Testing for Task-Oriented Chatbots
Mutation Testing for Task-Oriented Chatbots
Pablo Gómez Abajo
 
Session 1 - Intro to Robotic Process Automation.pdf
Session 1 - Intro to Robotic Process Automation.pdfSession 1 - Intro to Robotic Process Automation.pdf
Session 1 - Intro to Robotic Process Automation.pdf
UiPathCommunity
 
Main news related to the CCS TSI 2023 (2023/1695)
Main news related to the CCS TSI 2023 (2023/1695)Main news related to the CCS TSI 2023 (2023/1695)
Main news related to the CCS TSI 2023 (2023/1695)
Jakub Marek
 
Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024
Jason Packer
 
"Scaling RAG Applications to serve millions of users", Kevin Goedecke
"Scaling RAG Applications to serve millions of users",  Kevin Goedecke"Scaling RAG Applications to serve millions of users",  Kevin Goedecke
"Scaling RAG Applications to serve millions of users", Kevin Goedecke
Fwdays
 
"Frontline Battles with DDoS: Best practices and Lessons Learned", Igor Ivaniuk
"Frontline Battles with DDoS: Best practices and Lessons Learned",  Igor Ivaniuk"Frontline Battles with DDoS: Best practices and Lessons Learned",  Igor Ivaniuk
"Frontline Battles with DDoS: Best practices and Lessons Learned", Igor Ivaniuk
Fwdays
 

Recently uploaded (20)

Taking AI to the Next Level in Manufacturing.pdf
Taking AI to the Next Level in Manufacturing.pdfTaking AI to the Next Level in Manufacturing.pdf
Taking AI to the Next Level in Manufacturing.pdf
 
"$10 thousand per minute of downtime: architecture, queues, streaming and fin...
"$10 thousand per minute of downtime: architecture, queues, streaming and fin..."$10 thousand per minute of downtime: architecture, queues, streaming and fin...
"$10 thousand per minute of downtime: architecture, queues, streaming and fin...
 
Your One-Stop Shop for Python Success: Top 10 US Python Development Providers
Your One-Stop Shop for Python Success: Top 10 US Python Development ProvidersYour One-Stop Shop for Python Success: Top 10 US Python Development Providers
Your One-Stop Shop for Python Success: Top 10 US Python Development Providers
 
Essentials of Automations: Exploring Attributes & Automation Parameters
Essentials of Automations: Exploring Attributes & Automation ParametersEssentials of Automations: Exploring Attributes & Automation Parameters
Essentials of Automations: Exploring Attributes & Automation Parameters
 
Biomedical Knowledge Graphs for Data Scientists and Bioinformaticians
Biomedical Knowledge Graphs for Data Scientists and BioinformaticiansBiomedical Knowledge Graphs for Data Scientists and Bioinformaticians
Biomedical Knowledge Graphs for Data Scientists and Bioinformaticians
 
Christine's Supplier Sourcing Presentaion.pptx
Christine's Supplier Sourcing Presentaion.pptxChristine's Supplier Sourcing Presentaion.pptx
Christine's Supplier Sourcing Presentaion.pptx
 
Fueling AI with Great Data with Airbyte Webinar
Fueling AI with Great Data with Airbyte WebinarFueling AI with Great Data with Airbyte Webinar
Fueling AI with Great Data with Airbyte Webinar
 
Freshworks Rethinks NoSQL for Rapid Scaling & Cost-Efficiency
Freshworks Rethinks NoSQL for Rapid Scaling & Cost-EfficiencyFreshworks Rethinks NoSQL for Rapid Scaling & Cost-Efficiency
Freshworks Rethinks NoSQL for Rapid Scaling & Cost-Efficiency
 
Skybuffer SAM4U tool for SAP license adoption
Skybuffer SAM4U tool for SAP license adoptionSkybuffer SAM4U tool for SAP license adoption
Skybuffer SAM4U tool for SAP license adoption
 
JavaLand 2024: Application Development Green Masterplan
JavaLand 2024: Application Development Green MasterplanJavaLand 2024: Application Development Green Masterplan
JavaLand 2024: Application Development Green Masterplan
 
Northern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
Northern Engraving | Modern Metal Trim, Nameplates and Appliance PanelsNorthern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
Northern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
 
Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...
Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...
Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...
 
Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving | Nameplate Manufacturing Process - 2024Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving | Nameplate Manufacturing Process - 2024
 
Monitoring and Managing Anomaly Detection on OpenShift.pdf
Monitoring and Managing Anomaly Detection on OpenShift.pdfMonitoring and Managing Anomaly Detection on OpenShift.pdf
Monitoring and Managing Anomaly Detection on OpenShift.pdf
 
Mutation Testing for Task-Oriented Chatbots
Mutation Testing for Task-Oriented ChatbotsMutation Testing for Task-Oriented Chatbots
Mutation Testing for Task-Oriented Chatbots
 
Session 1 - Intro to Robotic Process Automation.pdf
Session 1 - Intro to Robotic Process Automation.pdfSession 1 - Intro to Robotic Process Automation.pdf
Session 1 - Intro to Robotic Process Automation.pdf
 
Main news related to the CCS TSI 2023 (2023/1695)
Main news related to the CCS TSI 2023 (2023/1695)Main news related to the CCS TSI 2023 (2023/1695)
Main news related to the CCS TSI 2023 (2023/1695)
 
Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024
 
"Scaling RAG Applications to serve millions of users", Kevin Goedecke
"Scaling RAG Applications to serve millions of users",  Kevin Goedecke"Scaling RAG Applications to serve millions of users",  Kevin Goedecke
"Scaling RAG Applications to serve millions of users", Kevin Goedecke
 
"Frontline Battles with DDoS: Best practices and Lessons Learned", Igor Ivaniuk
"Frontline Battles with DDoS: Best practices and Lessons Learned",  Igor Ivaniuk"Frontline Battles with DDoS: Best practices and Lessons Learned",  Igor Ivaniuk
"Frontline Battles with DDoS: Best practices and Lessons Learned", Igor Ivaniuk
 

Deliverables based planning handbook

  • 1. Niwot Ridge, LLC DELIVERABLES BASED PLANNING® Principles and Practices that increase the Probability of Program Success (PoPS). V8.3.a 12/23/20
  • 3. Chapter Title Page Chapter 0 Deliverables Based Planning in a Nutshell 5 Chapter I Principles and Practices of Deliverables Based Planning® 45 Chapter II The 10 Principles of Deliverables Based Planning® 55 Chapter III Deploying Deliverables Based Planning® 79 Chapter IV Process 1.0 – Identify Needed Systems Capabilities 87 Chapter V Process 2.0 – Establish the Requirements Baseline 97 Chapter VI Process 3.0 – Establish the Performance Measurement Baseline 107 Chapter VII Process 4.0 – Execute the Performance Measurement Baseline 117 Chapter VIII Process 5.0 – Continuous Risk Management 127 Chapter IX Graded Application of Deliverables Based Planning® 147 Chapter X Tools and Artifacts used in Deliverables Based Planning® 159 Append A References for each Chapter 207 Table of Contents 3 Deliverables Based Planning ® is a registered trademark of Niwot Ridge LLC,
  • 5. Deliverables Based Planning® integrates five critical program management principles with: § Cost, § Schedule, and § Technical Performance Measures, … assuring actionable information is provided to the decision makers to increase the probability of program success. 5 0Deliverables Based Planning® in a Nutshell Chapter
  • 6. Deliverables Based Planning® In A Nutshell Increasing Your Probability of Success(sm) Chapter 06
  • 7. Why Deliverables Based Planning®? ¨ The customer bought capabilities to fulfill the mission:† ¤ Not the work effort, ¤ Not the cost expenditures, and, ¤ Not, the documentation, test results, or the work processes. ¨ All successful programs deliver tangible beneficial outcomes, defined in units of measure meaningful to the decision makers. Deliverables Based Planning® † Mission defines the fundamental purpose of an organization or an enterprise, and states why it exists and what it does to achieve its Vision. 7 Chapter0
  • 8. 1. What Does DONE Look Like? 2. How Do We Get There? 3. Is There Enough Time, Resources, And Money To Get There? 4. What Impediments Will Be Encountered Along The Way? 5. What Are The Units Of Measures For Progress To Plan? All Successful Projects Must Know The Answer To 5 Questions 8Lewis & Fowler, Copyright © 2011
  • 9. 11 Critical Practices Needed to Answer the 5 Questions of Project Success 9 ¨ Define the Work Breakdown Structure(WBS). ¨ Indentify the Organizational Breakdown Structure (OBS). ¨ Integrate the WBS and OBS. ¨Organization ¨ Schedule the work. ¨ Identify the Products and Milestones. ¨ Set the time phased budget. Planning and Budgeting ¨ Record direct costs. Accounting ¨ Determine variances. ¨ Sum Data and variances. ¨ Manage action plans. Performance Analysis ¨ Incorporate Changes. Revision Management Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011 Chapter0
  • 10. Credible Data Is Need to Increase The Probability Of Program Success ¨ Concept of Operations (ConOps) ¨ Operational Scenarios and Use Cases ¨ Integrated Master Plan (IMP) ¨ Value Stream Maps (VSM) ¨ Key Performance Parameters (KPP) ¨ Measures of Effectiveness (MoE) ¨ Program Planning and Controls (PP&C) ¨ Integrated Master Schedule (IMS) ¨ Work Packages (WP) and Planning Packages (PP) ¨ Earned Value Management (EVM) ¨ Technical and Programmatic Risk Management (RM) ¨ Measures of Performance (MoP) ¨ Estimate At Completion (EAC) ¨ Estimate To Complete (ETC) ¨ To Complete Performance Index (TCPI) ¨ Independent Estimate At Completion (IEAC) ¨ Technical Performance Measures (TPM) 10 Chapter0
  • 11. Systems Management Guides the Conversion of this Data to Actionable Information ¨ Systems Management is the set of organizational structures and processes that rapidly deliver dependable technological outcomes within a predictable time and budget. ¨ Complexity in large scale systems is not driven by the scale, but rather by the heterogeneity of the components and their individual underlying complexity. ¨ Managing the complex individual components, their interactions, their cost, schedule, and technical performance elements is the role of Systems Management. ¨ DBP® connects the data to provide actionable information to the decision makers. 11 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011 Chapter0
  • 12. 16 Program Management Processes 12 Program Enablers Program Process Capabilities Business Enablers Chapter0
  • 13. Origins of Deliverables Based Planning® 13 ¨ This planning in the large. ¨ This is planning in the presence of change. ¨ The focus is on transformational outcomes. ¨ Capabilities start with a mission level analysis. www.rand.org Chapter0
  • 14. Deliverables Based Planning® Answers 4+1 Questions Needed for Success Lewis & Fowler’s Deliverables Based Planning® integrates five critical program management process areas with – Cost, Schedule, and Technical Performance Measures. The inclusion of Technical Performance Measures (TPM) separates our approach from conventional methods based solely on managing cost and schedule. In conventional approaches, the cost and schedule baseline and their variances generate the data for Earned Value variables that are used to make programmatic decisions. In Deliverables Based Planning®, Earned Value measures are integrated with measures of Physical Percent Complete (PPC) derived from Technical Performance Measures (TPM) at planned assessment points in the Integrated Master Schedule (IMS). The Events and Milestones define in the Integrated Master Plan (IMP) describe the planned technical or operational maturity of the products or services measured against their actual technical performance. The Earned Value measurements are used with Technical Performance measures for each deliverable to produce a credible measure of progress and a credible forecast of future performance using the To Complete Performance Index (TCPI). The result is increased visibility and credibility of the Independent Estimate at Completion (IEAC). As the program progresses, technical and programmatic risks are identified, their mitigation or retirement planned and executed, and adjustments to the program made to assure planned progress is maintained. Successfully executing a program requires a Program Planning and Controls discipline that identifies what “Done” looks like, measures progress toward “Done,” identifies the risks and impediments to reaching “Done,” and assures timely corrective action to maintain progress toward “Done.” “Done” is always defined in units of measure meaningful to the customer. The best tangible evidence are the Deliverables needed to meet the requirements that fulfill the system’s requested capabilities that are recognized as success for the program. Using this approach, Deliverables fulfill the requirements that meet the system or business performance criteria, produced at the planned time, using the planned budget. This performance is measured as Physical Percent Complete and is the only Credible measurement of progress. With the planned requirements fulfilled, the system or operational capabilities become available to the customer at the planned time. 14 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011 Chapter0
  • 15. The 4+1 Questions Every Project Must Answer to be Successful Capabilities Requirements Plans Execution 2. What technical and operational requirements are needed to deliver these capabilities? 1. What capabilities are needed to fulfill the Concept of Operations†, the Mission and Vision, or the Business System Requirements? 3. What schedule delivers the product or services on time to meet the requirements? 4. What periodic measures of physical percent complete assure progress to plan? What impediments to success, their mitigations, retirement plans, or “buy downs are in place to increase the probability of success?” + Continuous Risk Management † A Concept of Operations (ConOps) describes the characteristics of a system from the point of view of an individual who will use that system. It is used to communicate the quantitative and qualitative system characteristics to all stakeholders. Œ  Ž   Chapter 015
  • 16. Deliverables Based Planning® Addresses … Project Management Case Study, Pierre Bonnal, CNAM IIM MBA Program, June 2004 16 Chapter0
  • 17. Identify Needed Capabilities Establish a Performance Measurement Baseline Execute the Performance Measurement Baseline Capabilities Based Plan Operational Needs Earned Value Performance 0% /100% Technical Performance Measures System Value Stream Technical Requirements Identify Requirements Baseline Technical Performance Measures PMB Changes to Needed Capabilities Changes to Requirements Baseline Changes to Performance Baseline Œ  Ž   Chapter 017 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
  • 18. Increasing the Maturity of Project Deliverables 1. Identify Needed Capabilities to achieve program objectives or the particular end state. Define these capabilities through scenarios from the customer point of view in units of Measure of Effectiveness (MoE) meaningful to the customer. 2. Define The Technical And Operational Requirements that must be fulfilled for the system capabilities to be available to the customer at the planned time. Define these requirements in terms that are isolated from any implementation technical products or processes. Only then bind the requirements with technology. 3. Establish The Performance Measurement Baseline describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables from this work, and the Measures of Performance (MoP) showing this work is proceeding according to cost, schedule, and technical performance. 4. Execute the PMB’s Work Packages in the planned order, assuring all performance assessment are 0%/100% complete before proceeding. No rework, no forward transfer of activities to the future. Assure every requirement is traceable to work and all work is traceable to requirements. 5. Perform Continuous Risk Management for each Deliverables Based Planning® process area to Identify, Analyze, Plan, Track, Control, and Communicate programmatic and technical risk. The integration of these five process areas is the foundation of Deliverables Based Planning® . Each process area stands alone and at the same time is coupled with the other process areas. Each process area contains specific process steps for producing beneficial outcomes to the project, while establishing the basis for overall project success. Each process can be developed to the level needed for specific projects. All five process areas are critical to the success of any project. If a process area is missing or poorly developed, the capability to manage the project will be jeopardized, possibly in way not know until the project is too far along to be recovered. Each process provides information needed to make decisions about the flow of the project. This actionable information is the feedback mechanism needed to keep a project under control. These control processes are not impediments of progress of the tools needed to increase the probability of success. Chapter0 18 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
  • 19. Increasing the Maturity of Project Deliverables Identify Needed Capabilities Indentify Baseline Requirements Establish Performance Measurement Baseline Execute Performance Measurement Baseline §Define Capabilities §Define ConOps §Assess Needs, Cost, and Risk §Defined Balanced and Feasible Alternatives §Fact Finding §Gather And Classify §Evaluate And Rationalize §Prioritize §Integrate And Validate §Decompose Scope §Assign Accountability §Arrange Work §Develop BCWS §Assign Performance §Perform Work §Accumulate Performance §Analyze Performance §Take Corrective Action Continuous Risk Management (CRM) Define the Measurable Capability Outcomes Assure All Requirements Are Met In Support of Capabilities Define Measures of Performance and Effectiveness Ensure Cost, Schedule, and Technical Performance Chapter0 19
  • 20. What is a Deliverable? Project Management Case Study, Pierre Bonnal, CNAM IIM MBA Program, June 2004. Chapter0 20
  • 21. Define the set of capabilities needed to achieve the project objectives or the particular end state for a specific scenario. Using the Concept of Operations (ConOps), define the details of who, where, and how this capability is to be accomplished, employed, and executed. Œ Define the technical and operational requirements for the system capabilities to be fulfilled. First, define these requirements in terms isolated from any implementation details. Only then bind the requirements with technology.  Build a time–phased network of work activities describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables, and the performance measures showing this work is proceeding according to plan. Ž Execute work activities, while assuring all performance assessment represent 100% completion before proceeding. This means – No rework, no forward transfer of activities to the future. Assure all requirements are traceable to work & all work is traceable to requirements.  Apply the processes of Continuous Risk Management for each Deliverables Based Planning® process area to: Identify, Analyze, Plan, Track, Control, and Communicate programmatic and technical risk.  Chapter 021 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
  • 22. §Partition system capabilities into classes of service within operational scenarios. §Connect the capabilities to system requirements using some visual modeling notation. §Define Measures of Effectiveness (MoE) and Measures of Performance (MoP). §Define the delivery schedule for each measure of performance and effectiveness. §Define scenarios for each system capability. §Connect these scenarios to a Value Stream Map of the increasing maturity of the program. §Assess value flow through the map for each needed capability. §Identify capability mismatches and make corrections to improve overall value flow. §Assign costs to each system element using a value flow model. §Assure risk, probabilistic cost and benefit performance attributes are defined. §Use cost, schedule and technical performance probabilistic models to forecast potential risks to program performance. §Make tradeoffs that connect cost, schedule, and technical performance in a single location that compares the tradeoffs and their impacts. §Use Measures of Effectiveness (MoE) and Measures of Performance (MoP) for these alternative tradeoffs. Define the capabilities needed to achieve the desired objectives or a particular end state for a specific scenario. Define the details of who, where, and how these capabilities are to be accomplished, employed, and executed. 1.1 1.2 1.3 1.4 Œ Chapter 022
  • 23. What Does A Capability “Sound” Like? Chapter0 23
  • 24. Identifying Needed System Capabilities Identifying System Capabilities is the starting point for any successful program. Systems Capabilities are not direct requirements, but a statements of what the system should provide in terms of “abilities.” For example there are three capabilities needed for the Hubble Robotic Servicing Mission: 1. Do no harm to the telescope. 2. Change the Wide Field Camera. 3. Connect the battery umbilical cable. How is this to be done and what are the technical, operational, safety and mission assurance requirements? Don’t really know yet, but the Capabilities guide their development. The critical reason for starting with capabilities is to establish a home for all the requirements. To answer the question “why is this requirement present?” “Why is this requirement needed?” “What business or mission value does fulfilling this requirement provide?” Capabilities statement can then be used to define the units of measure for program progress. Measuring progress with physical percent complete at each level is mandatory. But measuring how the Capabilities are being fulfilled is most meaningful to the customer. The “meaningful to the customer” unit of measures are critical to the success of any program. Without these measures the program may be cost, schedule, and technically successful but fail to fulfill the mission. The process flow to the right is the starting point for Identifying the Needed Capabilities and determining their priorities. Starting with the Capabilities prevents the “Bottom Up” requirements gathering process from producing a “list” of requirements – all needed – that is missing a well formed topology. This Requirements Architecture is no different than the Technical or Programmatic architecture of the system. Capabilities Based Planning (CBP) focuses on “outputs” rather than “inputs.” These “outputs” are the mission capabilities that fulfilled by the program. In order to fulfill these capabilities, requirements need to be met. But we need the capabilities first. Without the capabilities, it is never clear the mission will be a success, because there is no clear and concise description of what success means. The concept of CBP recognizes the interdependence of systems, strategy organization, and support in delivering the capability, and the need to examine options and trade‒offs in terms of performance, cost and risk to identify optimum development investments. CBP relies on scenarios to provide the context to measure the level of capability. 24 Chapter0
  • 25. What Should We Do? Where Are We Now? Identifying Needed System Capabilities Abstracted from: “Capabilities‒Based Planning – How It Is Intended To Work And Challenges To Its Successful Implementation,” Col. Stephen K. Walker, United States Army, U. S. Army War College, March 2005 Identifying Needed System Capabilities 25 Chapter0
  • 26. §Produce an overall statement of the problem in the operational context. §Develop the overall operational and technical objectives of the target system. §Defined the boundaries and interfaces of the target system. §Gather required system capabilities, functional, nonfunctional and environmental requirements, and design constraints. §Build the Top Down capabilities and functional decomposition of the requirements in a Requirements Management System. §Answer the question “why do I need this?” in terms of operational capabilities. §Build a cost / benefit model using probabilistic assessment of all variables, their dependencies, and impacts. §For all requirements, perform a risk assessment to cost and schedule. §Determine criticality for the functions of the system. §Determine trade off relationships for all requirements to be used when option decisions must be made. §For all technical items, prioritize their cost and dependency. §Address the completeness of requirements by removing all “TBD” items. §Validate that the requirements are traceable to system capabilities, goals, and mission. §Resolve any requirements inconsistencies and conflicts. Define the technical and operational requirements that must be present for the system capabilities to be delivered. Define these requirements in terms isolated from any technology or implementation. Assure each requirement is connected to a need system capability. 2.1 2.2 2.3 2.4 2.5  Chapter 026
  • 27. What Is a Requirement? 27 Chapter0
  • 28. Identifying Requirements Requirements are the necessary attributes defined for an item prior to the efforts to develop a design for the item. System requirements analysis is a structured, or organized, methodology for identifying an appropriate set of resources to satisfy a system need (the needed capabilities) and the requirements for those resources that provide a sound basis for the design or selection of those resources. It acts as the transformation between the customer’s system needs and the design concept implemented by the organization’s engineering resources. The requirements process decomposes a statement of the customer need through a systematic exposition of what that system must do to satisfy that need. This need is the ultimate system requirement which all other requirements and designs flow. There are two fundamental classes of requirements. § Process Performance Requirements § Product Performance Requirements The Process Performance Requirements define how the work processes are used to produce a beneficial outcome to the customer. The Product Performance Requirements define the product specifications and how they are related to the process requirements. As well as the product and process requirements, there are functional and non‒functional requirements. These non‒functional requirements play a significant role in the development of the system. Non‒functional requirements are spread across the entire system or within individual services and cannot be allocated to one specific software artifact (e.g., class, package, component). This makes them more difficult to handle than functional requirements. The specifics of the system’s architecture, such as highly distributed services bring up additional difficulties. The distinction between process and product requirements lays the foundation for the Work Breakdown Structure. The WBS, the Related Integrated Master Plan (IMP) and Integrated Master Schedule (IMS), also focus on this separation. The success of the project or program depends on defining both the product and the processes that support or implement the product. When properly connected, the Requirements Taxonomy, the Work Breakdown Structure, the IMP and the IMS “foot and tied” to the Performance Measurement Baseline (PMB) provides the traceability of the increasing maturity of the deliverables (vertical) and the physical percent complete of the work efforts (horizontal). 28 Chapter0
  • 29. Identifying Requirements† †Systems Requirements Practices, Jeffery O. Grady, McGraw Hill, 1993 29 Chapter0
  • 30. Build a time–phased network of activities describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables from this work, and the performance measures showing this work is proceeding according to plan. Decompose the program Scope into a product based Work Breakdown Structure (WBS), then further into Work Packages describing the production of the deliverables traceable to the requirements, and to the needed capabilities. 3.1 Assign responsibility to Work Packages (the groupings of deliverables) to a named owner accountable for the management of the resource allocations, cost and schedule baseline, and technical delivery. 3.2 Arrange the Work Packages in a logical network with defined deliverables, milestones, internal and external dependencies, with credible schedule, cost, and technical performance margins. 3.3 Develop the Time–Phased Budgeted Cost for Work Scheduled (BCWS) for the labor and material costs in each Work Package and the Project as a whole. Assure proper resource allocations can be met and budget profiles match expectations of the program sponsor 3.4 Assign objective Measures of Performance (MoP) and Measures of Effectiveness (MoE) for each Work Package and summarize these for the Project as a whole. 3.5 Establish a Performance Measurement Baseline (PMB) used to forecast the Work Package and Project ongoing and completion cost and schedule performance metrics. 3.6 Ž Chapter 030
  • 31. What Does a Credible Plan and Schedule Look Like? 31 Chapter0
  • 32. Establishing the Three Elements of the Performance Measurement Baseline The Performance Measurement Baseline (PMB) is the primary assessment document for assuring the credibility of a program plan. The PMB is the baseline of the cost, schedule and deliverables for each Work Package in the plan. Constructing the PMB requires knowledge of the business requirements, skill in developing the Work Packages that produce the deliverables for these requirements, and discipline in assembling the cost, schedule and relationships between the Work Packages. It is the discipline that requires the most focus for the planners and program controls staff. Without this discipline, the development of a credible baseline is simply not possible. In the end the planners and program controls staff must “know” in intimate detail each Work Package, its deliverables and resource requirements, the performance measurement criteria and the dependencies that form the critical path through the program schedule. The concept of a Deliverables Based Plan (DBP) is at the core of the Performance Measurement Baseline (PMB). § Deliverables are the units of measure of progress to plan. § Deliverables are what the customer has paid money for. § Deliverables contain the business capabilities, the associated value that fulfill the requirements of the business plan. The Technical Performance Baseline is the requirements flow down and traceability map for each deliverables in the program. § A critical performance measure of the Technical Performance Baseline is the stability of requirements. The expected technical achievement for the actual progress is compared using periodic measurements or tests starts with the Technical Performance Baseline. § An important aspect of the Technical Performance Baseline is to define the units of measures for each deliverable that defines what “done” looks like at each incremental assessment of maturity. The Schedule Performance Baseline is the sequence of Work Packages and Planning Packages that produce the products or services from the program. This baseline contains the schedule margin derived from the Monte Carlo simulation described in DID 81650. The Cost Performance Baseline is the “authorized time‒phased budget‒at‒completion (BAC) used to measure, monitor, and control overall cost performance on the program.” This budget (BCWS) is held in the Control Accounts, the Work Packages and Planning Packages owned by the Control Account Manager. 32 Chapter0
  • 33. Establishing the Three Elements of the Performance Measurement Baseline Cost Baseline Schedule Baseline Technical Baseline Perform Functional Analysis Determine Scope and Approach Develop Technical Logic Develop Technical Baseline Develop WBS Define Activities Estimate Time Durations Sequence Activities Finalize Schedule Identify Apportioned Milestones Determine Resource Requirements Prepare Cost Estimate Resource Load Schedule Finalize Apportioned Milestones Determine Funding Constraints Approve PMB 33 Chapter0
  • 34. Execute the planned work, assuring all work is 100% complete before proceeding to the next planned work package. No rework, no forward transfer of activities or features. Assure every requirement is traceable to work and all work is traceable to requirements. § Using the Work Package sequencing, release work to be performed as planned. § With the responsibility assignments, identify the accountable delivery manager to guide the development of the products or services for each Work Package. 4.1 § Using Physical Percent Complete or Apportioned Milestones, capture measures of progress to plan for each Work Package. § Report this Physical Percent Complete in a centralized database for each Work Package and the program as a whole. 4.2 § Compare the Physical Percent Complete against the Planned Percent Complete for each period of performance. § Construct cost and schedule performance indices from this information and the Physical Percent complete measures. 4.3 § With Cost and Schedule performance indices, construct a forecast of future performance of cost, schedule, and technical performance compliance. § Take management actions for any Work Packages not performing as planned. 4.4 § Record past performance based on Work Package completion criteria. § Record past future forecast performance estimates in a historical database. § Forecast next future performance estimate against the Performance Measurement Baseline. § Report this next future performance estimate to the program stakeholders. 4.5  Chapter 034
  • 35. How Do We Know We Are Making Progress to Plan? 35 Chapter0
  • 36. Executing the Performance Measurement Baseline With the Performance Measurement Baseline established, its execution becomes critically important. The execution process is called the “program rhythm.” this means the processes are performed in a repeated manner – at least on a monthly basis and many times on a weekly basis. This business rhythm must create actionable information for the program manager on a time scale that actually allows actions to be taken. For Government programs this time scale is at a minimum once a month – the Contract Performance Report – in the form of DI‒MGMT‒81466A. A larger question must be answered though. How long is the Program Manager willing to wait before she discovers she is late? Waiting one month seems risky. Many programs have weekly status reviews which answer the question “where are we in terms of progress to plan?” In the Deliverables Based Planning method, the measure of this “progress to plan” is provided by the tangible physical deliverables from the work efforts. These tangible, physical deliverables must be defined in the work packaged created during the Planning process of Deliverables Based Planning. The measures of physical percent complete can be applied on weekly boundaries in a variety if ways: 1. To actually have weekly deliverables. 2. Have apportioned milestones for each week. 3. Have tasks that are one week long and record 0%/100% complete at the end of each week. In all cases, a measure of physical percent complete is mandatory if the program manager is to receive actionable information. The important process here is to have an agreed on measure of performance that is defined before the work starts. Keep these measures and the work efforts that produce to “fine grained” durations. Focus on answering the question How long are we willing to wait before we find out we’re late? The answer to this question must be short enough to take corrective action so you are in fact not late. 36 Chapter0
  • 37. Executing the Performance Measurement Baseline (PMB) 37 Chapter0
  • 38. § Identify and classify risks in a Risk Register. § Manage this Risk Register through a Risk Management Board. § Connect these risks and their handling in the Master Schedule. § Convert risk data into risk decision‒making information. § Use this analysis information as the decision basis for the program manager to work on the “right” risks. § Turn risk information into decisions and actions (both present and future). § Develop actions to address individual risks, prioritize risk actions, and create an integrated risk management plan. § Monitor the status of risks and actions taken to ameliorate risks. § Identify and monitor risks to enable the evaluation of the status of risks themselves and of risk mitigation plans. § Risk communication lies at the center of the model to emphasize both its pervasiveness and its criticality. § Without effective communication, no risk management approach can be viable. Continuous Risk Management starts the underlying principles, concepts, and functions of risk management and provides guidance on how to implement risk management as a continuous practice in programs and the organizations that management programs. 5.1 5.2 5.3 5.4 5.5  Chapter 038
  • 39. Analyze Plan Track Control Identify Risks, Issues, and Concerns Evaluate, classify, and prioritize risks Decide what should be done about each risk Monitor risk metrics and verify/validate mitigations Make risk decisions Subproject and partner data/constraints, hazard analysis, FMEA, FTA, etc. Risk data: test data, expert opinion, hazard analysis, FMEA, FTA, lessons learned, technical analysis Resources Replan Mitigation Program/project data (metrics information) Statement of Risk Risk classification, Likelihood Consequence, Timeframe Risk prioritization Research, Watch (tracking requirements) Acceptance Rationale, Mitigation Plans Risk status reports on: Risks Risk Mitigation Plans Close or Accept Risks Invoke contingency plans Continue to track Perform Continuous Risk Management 39 Chapter0
  • 40. Chapter 040 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
  • 41. Chapter 041 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
  • 42. 4+1Critical Success Processes Capabilities, Requirements & Deliverables Program Architecture & Dependencies Work Planning and Sequencing Performance Measurement Baseline Programmatic & Technical Risk Management §Balanced Scorecard §Aligned Organization Strategy §Integrated Master Plan (IMP) §Gaps §Overlaps §Interfaces §Integrated Master Schedule (IMS) §Cost And Schedule Baseline §WBS, RAM, Resource Loaded IMS §Risk Registry §Risk Handling Plans §Contingency And Management Reserve §Requirements Traceability §Value Stream Mapping §Work Packages §Planning Packages §Technical Performance Measures (TPM) §Risk Integrated With IMS §Risk Trending §Measures Of Effectiveness (MoE) §Design Structure Matrix (DSM) §Earned Value Management §Measures Of Performance (MoP) §Monte Carlo Simulation 42 Chapter0
  • 43. Program Support Services Business Process Reengineering Balanced Scorecard Organizational Change Management DCMA Compliance DCAA Compliance § Michael Hammer trained reengineering processes § Program governance scorecard § Integrated Project Team development § Earned Value Management System Deployment § Cost Accounting Standard (CAS) system deployment § Project Management process improvement § Program performance dashboards § Performance management training § EVM System Description development and application § Integration of the EV Engine with a CAS compliant accounting system § Value stream mapping § Strategic management connected with execution § Measurable Process improvement § EVMS Validation preparation § DCAA and DCMA compliance of EVMS 43 Chapter0
  • 44. Benefits of Deliverables Based Planning® DBP® Capability Benefits to the Customer Program, Planning, and Controls Rapid creation of the risk adjusted Performance Measurement Baseline. Earned Value Management ANSI‒748B compliant processes, tools, and training. Programmatic and Technical Risk Management Credible integrated risk management process guided by DoD, DOE, AACE, and PMI standards. Management Process Improvement Value focused organizational change management. Program Performance Assessment Unbiased External Independent Reviews (EIR). Proposal support – Management Volume IMP/IMS, Basis of Estimate (BoE), and Risk sections. 44 Chapter0
  • 45. Deliverables Based Planning® Puts You On the Road to Success … Where are we going? How do we get there? Are there enough resources? What are impediments to progress? How do we measure progress? Chapter 045 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
  • 46. Chapter 046 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
  • 47. The10 Organizing Principles of Deliverables Based Planning® guide the application of the 5 Practice Areas in this handbook. These principles define the reasons for each practice, connect each practice to a beneficial outcome, and integrate the processes into a seamless delivery system. 47 IConnecting Principles With Practice Chapter
  • 48. The 10 Organizing Principles of Deliverables Based Planning® Principles are the source of guidance for the Deliverables Based Planning® Practices. A principle is a “general truth, a law on which other are founded or from which others are derived.” [Webster] For the principles of program and project management to be effective they must : § Express a basic concept § Be universally applicable § Be capable of straightforward expression § Be self evident The 10 Principles of Deliverables Based Planning® guide the application of the four process areas. These principles encompass the entire life cycle of a project or program, from inception and the discovery of the business or system capabilities, through requirements elicitation, to the creation of the Performance Measurement Baseline (PMB), to the execution of this baseline. The principles of Deliverables Based Planning® provide several feedback loops to assure that subsequent activities provide measurable information to correct gaps that exist in the previous activities. This iterative and incremental approach to program management assures the periods of assessment for corrective actions are appropriately spaced to minimize risk while maximizing the delivered value to the program. Deliverables Based Planning® can be the basis of conventional as well as Lean program management methods. The illustration the next page are the 10 Principles of Deliverables Based Planning®. Each principle is developed in detail later in this handbook. For now understanding the dependencies between the principles is important. Information produced by the practices derived from the principles must be done in a sequential manner. This is not a “waterfall” approach, but rather an incremental elicitation of the information needed to successfully manage the program. Skipping forward in the sequence of principle, creates systemic risk for both the programmatic and technical elements of the program. 48 ChapterI
  • 49. The 10 Organizing Principles of Deliverables Based Planning® Assess the capabilities being provided through the deliverables Fulfill the requirements through effort held in the Work Packages Produce deliverables from Work Packages Planned BCWS Physical % Complete WP’s contain deliverables that fulfill requirements Capabilities topology defines requirements flow down WP flow must describe the increasing maturity of the product or service Producing the deliverables in the planned sequence maintains the value stream to the customer ChapterI 49
  • 50. The 5 Process Areas of Deliverables Based Planning® Five core process form the basis of Deliverables Based Planning® . These processes represent a sequence of activities that increase the maturity of the programmatic aspects of a project or program. The plans that result from these efforts describe the increasing maturity of the product or services that are the deliverables from the program. In order to develop and execute a Plan, a set of requirements is needed. Before these requirements can be developed, an understanding of the system capabilities should be developed. 1. Identify Needed System Capabilities ‒ Define the set of capabilities (business, operational, or technical) needed to achieve the program objectives or a particular end state for a specific scenario using the Concept of Operations (ConOps). CONOPs is a verbal or graphic statement, in broad outline, of an assumption or intent in regard to an operation or series of operations, mission, or system. 2. Establish Requirements Baseline – defines the technical, organizational, and operational requirements that must be in place for the system capabilities to be fulfilled. Define these requirements in terms isolated from the implementation details. Only then, bind these requirements with the technical alternatives. 3. Establish Performance Measurement Baseline – build a time‒phased network of scheduled activities describing the work to be performed, the budgeted cost for this work, and the organizational elements that produce the deliverables from this work. Define the technical performance measures showing how this work proceeds according to the technical and programmatic plan. 4. Execute the Performance Measurement Baseline – execute the Performance Measurement Baseline Work Packages, while assuring all performance assessments represent measures of Physical Percent Complete. 5. Continuous Risk Management – identify, plan, and budget risk mitigation or retirement activities at assure impediments to progress are handled. These five process areas must all be present in some form, for program success. To skip any process area, or performance the process area out of order Capabilities, Requirements, Baseline, and Execution, with Continuous Risk Management lays the foundation for a Troubled Project. Each process area builds on the previous area to increase the fidelity of the actionable information needed by the decision makers. This method is independent of any specific development of engineering process – iterative, incremental, and linear processes are all equally effective ChapterI 50 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
  • 51. The 5 Process Areas of Deliverables Based Planning®10OrganizingPrinciplesofDeliverablesBasedPlanning® Chapter I 5 Identify Needed Capabilities Establish a Performance Measurement Baseline Execute the Performance Measurement Baseline Capabilities Based Plan Operational Needs Earned Value Performance 0% /100% Technical Performance Measures Business or Mission Value Stream Technical Requirements Identify Requirements Baseline Technical Performance Measures PMB Changes to Needed Capabilities Changes to Requirements Baseline Changes to Performance Baseline Œ  Ž   Chapter I51
  • 52. Deliverables Based Planning® Processes Deliverables Based Planning® is a comprehensive approach to managing cost, schedule, and technical performance of programs and projects by assessing the interaction between programmatic and technical processes. The method starts by capturing the technical and operational needs of the proposed system. These are stated in a Concept of Operations describing how the system operates, how it fulfills the stated mission, what major components comprise the system, and how they interact with each other. From the capabilities description of the Concept of Operation, technical and operational requirements are elicited. These requirements define the development progress of the deliverables captured in the Performance Measurement Baseline (PMB). This PMB is constructed from a collection of Work Packages, arranged in a logical network describing the increasing maturity of the products or services needed to deliver the stated capabilities. Measures of physical percent complete are used for each Work Package and the deliverables they produce. Deliverables Based Planning® is a Systems Engineering approach to program and project management [INCOSE], [Stevens]. This method incorporates all three aspects of a program performance measurement process – Cost, Schedule, and Technical Performance Measures (TPM). The inclusion of the TPMs distinguishes the Lewis & Fowler Deliverables Based Planning® from more conventional approaches to Program, Planning, and Controls. In conventional approaches, the cost and schedule baseline and the variances generate the values for Earned Value. In the Deliverables Based Planning® method, measures of Physical Percent Complete are derived from pre–defined targets of Technical Performance. The Earned Value variables are augmented with adjustments from the Technical Performance compliance for each deliverable to produce a true assessment of progress. Technical Performance Measures integrate technical achievement with earned value using risk assessments that provides a robust program management tool to identify early technical and programmatic disruptions to a program. [Pisano] TPMs: Provide an integrated view across all programmatic and technical elements. Support distributed empowerment implicit in the IPT approach, through interface definitions. Logically organizes data resulting from systems engineering, risk management, and earned value processes. Provide a "real time" indication of contract performance and future cost and schedule risk. Support the development of systems thinking within an integrated program model focused on the interface definitions. ChapterI 52 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
  • 53. Deliverables Based Planning® Processes ChapterI 53 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
  • 54. 1. Identify Needed Systems Capabilities – Define the Measures of Effectiveness (MoE) Deliverables Based Planning® DEFINE OPERATIONAL CONCEPTS THROUGH SCENARIOS OR USE CASES Partition system capabilities into classes of service within operational scenarios Connect capabilities to system requirements using sysML Define Measures of Effectiveness (MoE) for these capabilities in units meaningful to the customer Define in the master schedule the achievement of measure of Technical Performance DEFINE CAPABILITIES NEEDED TO IMPLEMENT THE OPERATIONAL CONCEPTS Define scenarios for each system capability Connect these scenarios to the Value Stream map Assess value flow through the map for each needed capability Identify capability mismatches and make corrections to improve overall value flow ASSESS NEEDS, COST, AND RISK SIMULTANEOUSLY Assign costs to each system element using a value process model Assure risk, probabilistic cost and benefit performance attributes are defined Use cost, schedule, and technical performance probabilistic models to forecast potential risks to program performance DEFINE EXPLICIT, BALANCED, AND FEASIBLE ALTERNATIVES Make tradeoffs that connect cost, schedule, and technical performance in a single “trade space” model Measures of Effectiveness and Measures of Performance are the raw materials for these tradeoffs 2. Establish Requirements Baseline – DEFINE MEASURES OF PERFORMANCE (MOP) PERFORM FACT FINDING Produce an overall statement of the problem in the operational context Develop the overall operational and technical; objectives of the target system through Measures of Performance (MoP) for the requirements Define the boundaries and interfaces of the target system GATHER AND CLASSIFY THE REQUIREMENTS Gather required operational capabilities, functional, nonfunctional, and environment requirements and design constraints Build a Top Down Capabilities and Functional decomposition of the requirements in a flow down tree using a requirements tool EVALUATE AND RATIONALIZE THE REQUIREMENTS Answer the question “why do we need this?” in terms of operational benefits Build a cost / benefit model using probabilistic assessments of all variables and dependencies For technical requirements, perform a risk assessment to the cost and schedule PRIORITIZE THE REQUIREMENTS Determine the criticality for the functions for the system’s mission Determine tradeoff relations for all requirements to be used when option decision are made For technical items, prioritize the cost and dependencies INTEGRATE AND VALIDATE THE REQUIREMENTS Address completeness of requirements by removing all TBD items Validate the requirements agree and are traceable to capabilities, goals, and the mission Resolve any requirement inconsistencies and conflicts Chapter IChapter I54
  • 55. 3. ESTABLISH PERFORMANCE MEASUREMENT BASELINE – DEFINE TECHNICAL PERFORMANCE MEASURES (TPM) DELIVERABLES BASED PLANNING® DECOMPOSE REQUIREMENTS INTO WORK PACKAGES AND PLANNING PACKAGES Decompose the program scope into a product based Work Breakdown Structure (WBS) Decompose the WBS into Work Packages describing the production of all deliverables and processes traceable to the requirements ASSIGN ACCOUNTABILITY FOR THE DELIVERABLES FROM EACH WORK PACKAGE Assign accountability for Work Packages to a named owner for the management of resource allocation, cost baseline, and technical delivery ARRANGE WORK PACKAGES IN A LOGICAL ORDER Arrange Work Packages in a network with defined deliverables, milestones, internal and external dependencies, appropriate schedule and cost margin DEVELOP THE BUDGETED COST FOR WORK SCHEDULED (BCWS) FOR EACH WORK PACKAGE AND PLANNING PACKAGE Develop a time‒phased Budgeted Cost for Work Scheduled (BCWS) for labor and material costs in each Work Package Develop a time‒phased Budgeted Cost for Work Scheduled (BCWS) for the program as a whole Assure proper resource allocations can be met and budget profiles match expectations of the program sponsor ASSIGN WORK PACKAGE MEASURES OF PERFORMANCE (MOP), KEY PERFORMANCE PARAMETERS (KPP), AND TECHNICAL PERFORMANCE MEASURES (TPM) Assign an objective Measure of Performance (MoP) for each critical Work Package deliverable Trace critical deliverables to the Measure of Effectiveness (MoE) defined in the Capabilities baseline Summarize these Measures of Performance (MoP) and Measures of Effectiveness (MoE) for the program as a whole Assign measures of Physical Percent Complete for each Work Package Assign measures of Physical Percent Complete for the program as a whole SET THE PERFORMANCE MEASUREMENT BASELINE (PMB) Establish a Performance Measurement Baseline (PMB) used to forecast Work Package and Project ongoing and completion cost and schedule metrics 4. Execute the Performance Measurement Baseline (PMB) – Maintain Cost, Schedule, and Technical Performance PERFORM AUTHORIZED WORK IN THE PLANNED SEQUENCE Using the Work Package sequencing, release work to be performed as planned With the RACI based RAM, the Accountable delivery manager guides the development of the products or service for each Work Package ACCUMULATE AND REPORT WORK PACKAGE PHYSICAL PERFORMANCE Using Physical Percent complete or Apportioned Milestones, capture the measures of “progress to plan” for each Work Package Report the Physical Percent Complete in a centralized system for each Work Package and he program as a whole ANALYZE WORK PACKAGE PERFORMANCE Compare the Actual Percent Complete against the Planned Percent Complete for each period of performance Construct cost and schedule performance indices from this information and the Physical Percent Complete measures TAKE CORRECTIVE MANAGEMENT ACTION FOR ANY VARIANCE IN WORK PACKAGE PERFORMANCE With the cost and schedule performance indices, construct a forecast of future performance of cost, schedule, and technical performance compliance Take management actions for any Work Packages not performing as planned MAINTAIN PERFORMANCE MEASUREMENT BASELINE’S INTEGRITY Record past performance based on Work Package completion criteria Record previous future performance estimates in a historical database Forecast future performance against the Performance Measurement Baseline Report the future performance estimate to the program stakeholders Chapter IChapter I55
  • 56. Program Events Define the availability of a Capability at a point in time. Accomplishments Represent requirements that enable Capabilities. Criteria Represent Work Packages that deliver the Requirements. Work Package Work Package Work Package Work Package Work Package Work Package Work Package Work package § Deliverables Based Planning® describes of the increasing maturing of a product or service through Events or Milestones, Accomplishments, Criteria, and Work Packages. § Each Event or Milestone represents the availability of one or more capabilities. § The presence of these capabilities is measured by the Accomplishments and their Criteria. § Accomplishments are the pre–conditions for the maturity assessment of the product or service at each Event or Milestone. § This hierarchy decomposes the System Capabilities into Requirements, Work Packages, and the activities the produce the deliverables. This hierarchy also describes increasing program maturity resulting from the activities contained in the Work Packages. § Performance of the work activities, Work Packages, Criteria, Accomplishments, and Events or Milestones is measured in units of “physical percent complete” by connecting Earned Value with Technical Performance Measures. The structure of a Deliverables Based Plan Chapter IChapter I56
  • 57. 10 organizing principles guide the deployment of Deliverables Based Planning® and the application of the 5 Process Areas. These 10 principles form the basis of the “theory” of Deliverables Based Planning®, while the Process Areas are the practice of the principles. 57 II10 Organizing Principles Chapter
  • 58. The 10 Organizing Principles of Deliverables Based Planning® Assess the capabilities being provided through the deliverables Fulfill the requirements through effort held in the Work Packages Produce deliverables from Work Packages Planned BCWS Physical % Complete WP’s produce deliverables that fulfill requirements Capabilities topology defines requirements flow down WP flow must describe the increasing maturity of the product or service Producing the deliverables in the planned sequence maintains the value stream to the customer ChapterII 58 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
  • 59. The 10 Organizing Principles of Deliverables Based Planning® Organizing Principles in Order of Increasing Maturity 1 Capabilities drive system requirements. All requirements must be traceable to a capability. Requirements identify technical and process deliverables. All deliverables must be traceable to a requirement. Work Packages describe the production of deliverables. Integrated Master Schedule (IMS) arrange the Deliverables, Accomplishments, Criteria, and Work Packages into a logical – risk adjusted – activity network. Work Package progress is measured as Physical Percent Complete against the planned progress at time of the performance assessment. Work Authorization assures the sequence of Work Packages produce progress at the planned rate for the planned cost, with the planned product maturity at each assessment point in the IMS. Earned Value describes the current performance and provides information about future performance. Conformance with Technical Performance Measures adjusts Earned Value for rework, quality, or delayed features, using Units of Measure meaningful to the decision makers. Performance feedback from each WP and program level Earned Value adjusts the WP sequence and resource allocation to reestablish an on–time, on–budget schedule. Future performance is based on the To Complete Performance Index (TCPI), Independent Estimate At Complete (IEAC), and the adjusted work sequence. ChapterII 59
  • 60. Capabilities Drive System Requirements The principles for defining a capability address the flexibility needed to ensure system responsiveness and sustainability in a context of constant change, while delivering tangible benefits to the buyer These include: Agility, Tailorability, and measures of System Element coupling and cohesion. Governance principles provide guidance to institutionalize a process, including its continued assessment and evolution over time in support of the tangible system benefits. These include: Enforced Rules & Responsibilities, Workflow Guidance, Continuous Improvement, Transformation enablers. The core concept in Capabilities Based development is the focus on the delivery of value. The concept of “Value Focused Thinking” starts with two methods of decision making: the 1st focuses on competitive analysis between the various alternatives, and the 2nd focuses on attaining organization values as the fundamental objective of any decision making process. [Pagatto07] During the development of the Concept of Operations for each capability, assumptions must be made in the absence of specific technical and operational information. To avoid unwelcome surprises, some form of assumptions based planning is needed. 1) Make operational plans, 2) Describe plausible events, 3) Identify the “signposts” for potential problems, 4) Discover shaping actions that shore up uncertain assumptions, and 5) take hedging actions to better prepare for the possibility that an assumption will fail [Dewer02] Capabilities planning consists of several core processes to describe the system capabilities in the absence of the specific technical or operational requirements. Discover what is not known by reaching a sufficient basic knowledge level setting the problem space. Identify problems by understanding the current process, along with people and technology involved. Establish boundaries and solution elements. These are grouped into five categories: 1. Orientation principles align the process on a sound theoretical basis issued from generally accepted practices in the areas of engineering, modeling, and acquisition. These principles include: Capability Thinking, Architecture Models, Evolutionary Development, and Deliverables Centric planning. 2. Communication principles enforce the standardization of vocabulary and structure of information to be exchanged within or outside the process. These include: Standardized Formats and Common Terminology to describes the system capabilities. 3. Collaboration principles enable active and timely participation of all stakeholders involved in the engineering of a capability. These include: Collaborative Engineering and Information Sharing between the contributors of the system capability elements. ChapterII 60
  • 61. Capabilities Drive System Requirements ¨ Establish the system capabilities by describing the fundamental ideas about the system through the operational behavior. ¨ Do this before the technical and process requirements are elicited. ¨ Use these Operational Concepts (OC) to describe how the system achieves the beneficial outcomes before any commitments are made to the implementation. ¨ Use a Capabilities Based Assessment (CBA) to define gaps in the current system and the approaches to providing capabilities within a specified functional or operational concept. ¨ Construct three capability assessments: Functional Area Analysis, Functional Needs Analysis, and Functional Solutions Analysis. ¤ Functional Area Analysis (FAA) is a capabilities based task analysis that provides the framework for assessing required capabilities for the success of the system. ¤ Functional Needs Analysis (FNA)assesses the ability of the current system to accomplish the needed tasks identified in the FAA, in the manner prescribed by the concept under the operating conditions and to prescribed standards. ¤ Functional Solutions Analysis (FSA) is an operationally based assessment of the potential strategies, organizations, training, leadership and education, personnel, facilities, and materials (technologies) for solving open of more of the capability needs. ChapterII 61
  • 62. Requirements Identify Technical And Process Deliverables Inadequate requirements engineering is a common problem in the development of any complex system. There are many issues associated with requirements engineering, including failure to define the system scope, failure to foster understanding among the different communities affected by the development of a given system, and failure to deal with the volatile nature of requirements. These problems lead to poor requirements and the cancellation of development, or else the development of a system that is later judged unsatisfactory or unacceptable, has high maintenance costs, or undergoes frequent changes. [Young04], [Grady06] By improving requirements elicitation, the requirements engineering process can be improved, resulting in enhanced system requirements and potentially a much better system. Requirements engineering is decomposed into the activities of requirements elicitation, specification, and validation. Most of the requirements techniques and tools today focus on specification, i.e., the representation of the requirements. The Deliverables Based Planning approach concentrates on elicitation concerns, those problems with requirements engineering that are not adequately addressed by specification techniques. The elicitation methodology to handle these concerns. Is provided by [Cristel92]. Whatever the actual process used, the following activities are fundamental to all Requirement Engineering processes:[Sommerville05] § Elicitation – Identify sources of information about the system and discover the requirements from these. § Analysis – Understand the requirements, their overlaps, and their conflicts. § Validation – Go back to the system stakeholders and check if the requirements are what they really need. § Negotiation – Inevitably, stakeholders’ views will differ, and proposed requirements might conflict. Try to reconcile conflicting views and generate a consistent set of requirements. § Documentation – Write down the requirements in a way that stakeholders and software developers can understand. § Management – Control the requirements changes that will inevitably arise. ChapterII 62
  • 63. Requirements Identify Technical And Process Deliverables ¨ Derive the system requirements for each system capability. ¨ Assure a requirement exists for each system capability needed to fulfill the mission of the system. ¨ Develop the traceability from capabilities to requirements to produce a “minimalist” system, with each requirement being present only because of a needed system or mission capability. ¨ Test requirements by answering the question “why do we need this feature, function, service, or capability?” ¨ Create Technical Performance Measures: [IEEE 1220] ¤ High priority requirements that have an impact on: mission accomplishment, customer satisfaction, cost, system usefulness. ¤ High risk requirements or those where the desired performance is not currently being met: the system uses new technology, new constraints have been added, the performance goal has been increased, but the performance is expected to improve with time. ¤ Requirements where performance can be controlled. ¤ Requirements where the program manager is able to rebalance cost, schedule and performance. ChapterII 63
  • 64. Work Packages Describe Production Of Deliverables Staying focused on decomposing the system capabilities into clearly defined streams of functionality is a critical success factor. This effort decouples the technical functionality from the system capabilities – increasing cohesion and reducing coupling between each stream. This decomposition is almost never optimal the first time around. The false sense of urgency to decompose the system requirements into a Work Breakdown Structure will cause extra work later on. Investing in a carefully developed WBS will pay back later in the program by isolating the work processes into supporting value streams. There is no set of instructions on how to do this. But starting the WBS in a graphical form, putting that diagram on the wall and asking coupling and cohesion questions about the terminal nodes in the WBS is one way to “test” to goodness of the WBS. The construction of the Work Breakdown Structure (WBS) starts with the decomposition of the requirements into collections of deliverables. Focusing on the deliverables is critical. The Work Packages that result from this decomposition are the vehicles for producing the deliverables. When these deliverables exist they provide the capabilities requested by the system to perform it function. All resources – internal and external, their dependencies, and any other items needed to produce the deliverables – are defined in Work Packages. The Work Package Manager is accountable for managing all these resources. If resources are not under the control of the Work Package Manager, the risk to the success of the deliverables is greatly increased, because … Accountability is no longer traceable to a single person – violating the principles of the Responsibility Assignment Matrix. Performance reporting for Physical Percent Complete is no longer represented by tangible items within Wok Package. Each Work Package produces one deliverable. This deliverable may have a Technical Performance Measure attached – a Measure of Performance (MoP) or Measure of Effectiveness (MoE). These Technical Performance Measures connect the dots between Cost, Schedule, and Technical maturity of the deliverable. In the absence of Technical Performance Measures, the Performance Measurement Baseline lacks the ability to connect physical percent complete with the increasing maturity of the product or service. ChapterII 64
  • 65. Work Packages Describe Production Of Deliverables ¨ Use the Work Packages (WP) executable tasks to produce deliverables at the conclusion of each WP duration. ¨ Avoid connections between WPs that are not Finish‒to‒Start at the WP boundaries, this “hides” dependencies. ¨ Work contained in the WP produces a single or small number of deliverables. ¨ Use performance measures at the Work Package level to assess the progress of the increasing maturity of the deliverables produced by each WP. ¨ Do not measure effort, the passage of time, or consumption of resources as assessments of progress. ¨ Use apportioned milestones, 0%/100%, 50%/50%, and other forms of incremental physical progress as a credible measures of percent complete at the WP level. ¨ When performance measures of actual delivered value are used, the physical progress of the program becomes a credible measure success. ¨ Measuring Earned Value for each task within the WP may be of little value for the program without a measure of Technical Performance (Measures of Effectiveness and Measures of Performance). ChapterII 65
  • 66. Master Schedule Sequences Deliverables, and Work Packages in a Network Arranging the Work Packages in a logical network is an iterative process. It should be obvious which major deliverables come first, second and later. Building an initial network, plotting that network in the Big Visible Chart, hanging that chart on the wall and standing in front of it with all the Work Package Managers is part of developing a credible PLAN for the program. The PLAN is the strategy for delivering the business capabilities the customer asked for. With the Big Visible Chart, this strategy is made visible – or at least more visible than a list of Work Packages. The strategy for delivering the program should be mapped out in some wall walk manner to make the connections obvious. This hands on approach is much better than burying the relationships in a program plan or spread sheet. Making the first cut is a hands on process. The arrangement of Work Packages should start with some simple rules: 1. All relationships are Finish to Start. This initial arrangement provides visibility into the dependencies that will drive schedule compression. Non FS relationships create opportunities to use partially complete work in future efforts, resulting in “rework,” the predecessor efforts are complete. 2. There should be no “lead” or “lag” arrangements. These create hidden dependencies and hidden schedule compression. 3. The only constraints on the network should be a “Must Start On” (MSO) for the start date and “As Soon As Possible” (ASAP) for all other activities. Any other constraints create hidden dependencies. This appears harsh at first, but is the basis of an “ideal” schedule. Other constraints may be added later, but only for necessary reasons, that are described in the IMS Narrative. 4. The flow of Work Packages should create a description of the increasing maturity of the products or services of the project – not just the consumption of resources and production of deliverables. This Maturity description should be meaningful to the customer in terms of business capabilities. At this point in time we will be able to perform the following business capabilities. 5. Speaking in these terms, the customer gains insight into the actual progress of the program. Speaking in consumption of resources, production of code, passage of milestones is not that meaningful to the customer 6. Point estimates of cost and schedule are meaningless without the range of possibilities, the level of certainty in achieving each value, and how these estimates impact the credibility that the program will complete on time, on schedule, and with the planned technical performance. ChapterII 66
  • 67. Master Schedule Sequences Deliverables, and Work Packages in a Network ¨ Arrange Work Packages in an un–constrained Activity Network. ¨ This network is a description of the flow of increasing maturity of the product or service resulting from the completion of each Work Package. ¨ This network answers the 6 critical questions needed for success: ¤ Who is responsible for performing this the work? ¤ What are the constituent components of the work and what is the evidence that they are complete? ¤ When is this the work required to be completed? ¤ Where will this work be performed? ¤ Why does this work need to be done? ¤ How does this support the acceptance of the product or service by the customer? ¨ Postpone the detailed scheduling until there is a credible WP process flow increases the visibility into dependencies as well as programmatic and technical risk and its mitigation. ¨ Define the Exit criteria for each WP the describes what “done” looks like and what technical maturity is needed to proceed to the next WP. ¨ The schedule of work within the WP can then be developed by the “owners” of the work effort – the Work Package Manager (Control Account Manager). ¨ Cost, Schedule, and Technical Performance values must be described in statistical terms, within a range of possible values and the probability of their occurrence. ChapterII 67
  • 68. Work Package Progress is Measured as Physical % Complete Against Plan Measuring progress to plan can ONLY be done with Physical Percent Complete (PPC). Any other measure of progress can not be connected to the delivery of business value to the customer. This is the basis of Earned Value and it is also the basis of Agile Software Development methodologies. Deliver working code at all times. Using the 0% /100% assignment or the Apportioned Milestone assignment, the Physical Percent Complete is multiplied by the Budgeted Cost of Work Scheduled (Planned Value, PV) for the entire Work Package to produce the Budgeted Cost of Work Performed (Earned Value, EV). PMI has used BCWP(EV) = PPC X Budget at Completion, where BAC = Sum(all Work Packages BCWS) This is the ONLY way BCWP(EV) can be produced. Any other way creates an invalid baseline measure of progress to plan. With the Work Packages defined, the BCWS(PV) spreads for each Work Packages established and the Work Packages assembled into a credible network, a Performance Measurement Baseline can be established. Step by Step check list for setting the baseline: 1. All BCWS spreads have been balanced against available resources for that Work Package and the program as a whole. This is a long, difficult and very unpleasant process. But letting a scheduling tool do this work has several undesirable outcomes: § The longest date usually results, since the tool spreads the resources according to their availability. § The planners of the program will not actually understand the resource spreads assigned by the machine § The day to day decisions of assigning work will now be removed from those who can make the decisions § The visibility into the logical process of assigning work is lost and the planners are simple observers 2. All Work Packages have apportioned milestones, 0/100, 50/50, or 25/75 assignments of Earned Value (BCWP)(EV) 3. All data fields in the schedule have been assigned and checked ChapterII 68
  • 69. Work Package Progress is Measured as Physical % Complete Against Plan ¨ Measure progress as Physical Percent Complete to provide a credible assessment of the increasing maturity of the delivered product or service. ¨ Use each work activity in the Work Package to provide some form of progress toward producing the deliverable. ¨ Use this progress as an incremental measure of the overall progress of the Work Package. ¨ Predefine how each work effort contributes to the overall progress of the Work Package. ¨ Have the Work Package owner describe the incremental Physical Percent Complete is terms of tangible evidence of progress to plan. ¨ Assure what “done” looks like is defined in terms of the Physical Percent Complete of the Work Package, Measures of Effectiveness, and Measures of Performance. ¨ Capture this definition in the Work Package documentation. ¨ Ask the question: ¤ How Long Are You Willing to Wait Before You Find Out You Are Late? ¨ Measure physical progress to plan soon enough before that period of performance arrives, so management corrections can be made to stay on cost, schedule and technical performance. ChapterII 69
  • 70. Work Authorization Assures Work Packages Produce Planned Progress The work authorization system is used by the program manager and his or her designees in order to approve all work throughout the course of the current program management venture. The work authorization system will typically be in the form of a list of formally adopted and well‒ documented procedures. Work authorization procedures specifically detail who may authorize work to be completed and how those authorizations may be obtained. These procedures will include which documents must be completed prior to work being initialized, and whether there are any other prerequisites to work being performed at any particular level during the program. To better assist the efficiency of program management in larger programs, work authorization systems sometimes detail the timeline of the program. For instance, the work authorization system might include at which points in time certain portions of the program should be completed, in which order those tasks are to be completed, and by whom. It is important for program management to be aware of how they convey the work authorization to their staff. To ensure that spoken words are not misinterpreted, written directions for the Work Packages provide explicit guidance. The Work Package can be anything which might need to be accomplished to produce a deliverable. By providing a written work authorization, those in program management can be assured that their wish to have the job done by the right people, at the correct time, and in the right order. The Project Manager needs to be cautious to write out the exact steps on the work authorization. This prevents misunderstandings and mistakes along the line. To have the work done correctly the first time, the manager must have good communication skills with his workers, both in the writing of the authorization and in answering any questions which might arise. Proper direction given to employees in the work permitting directive will ensure that the task is completed in the expected manner. ChapterII 70
  • 71. Work Authorization Assures Work Packages Produce Planned Progress ¨ Executing the Work Packages (WP) in the agreed sequence assures the program proceeds as planned. ¨ This approach starts with a Work Authorization and control processes and continually monitors, Late Starts, Late Finishes, Schedule Margin erosion, and Technical Performance Measure compliance. ¨ Work Authorization does not inhibit the performance of work, but assures that work is performed in the planned sequence with the planned programmatic risk reduction, to continuously increase the maturity of the product or service. ¨ “Out of sequence work” creates programmatic and technical risks: ¤ It disrupts the Earned Value calculations – work without a budget in the planned period is an overrun. Planned budget without actual work being performed is recorded as an under run. In both cases EV is reported improperly. ¤ The strategy developed for sequencing work to increase the maturity of the product or service is disrupted. ChapterII 71
  • 72. Earned Value Describes Current Performance From the ANSI‒748 Guideline: § The Earned Value Management System (EVMS) incorporates business best practices to provide strong benefits for program or enterprise planning and control. § The processes include integration of the program scope, schedule, and cost objectives, establishment of a baseline plan for accomplishment of program objectives and the use of earned value techniques for performance measurement during the execution of the program. § The EVMS provides a sound basis for problem identification, corrective actions, and management replanning as may be required. § Any Earned Value Management System must: § Plan all work scope for the program through completion. § Integrate program work scope, schedule, and cost objectives into a baseline plan against which accomplishments can be measured. § Objectively assess accomplishments at the work performance level. § Analyze significant variances from the plan and forecast impacts. § Provide data to higher levels for management decision making and implementation of management actions. For the benefits of Earned Value to be fully realized, thorough planning, combined with the establishment and maintenance of a baseline for performance measurement is needed. The combination of advanced planning, baseline maintenance, and earned value yields earlier and better visibility into program performance than is provided by non‒integrated methods of planning and control. The key to success is to establish the performance baseline at the Work Package level. The Work Package is the point at which work is planned, progress is measured, and earned value computed. ChapterII 72
  • 73. Earned Value Describes Current Performance ¨ Recognize Earned Value is cost based. Cost Variance and Schedule Variance have the same units of measure – Dollars. ¨ Use the To Complete Performance Index (TCPI) and the Independent Estimate At Completion (IEAC) as measures of progress derived from Earned Value. But they are also measured in dollars. ¨ Using the TCPI and IEAC, the program manager has visibility into the work performance needed to stay on schedule and the forecast cost of this effort. ¨ Recognize the credibility of these indices depends on the credibility of the underlying earned value numbers. This is the primary motivation for maintaining good data on the program. Otherwise the Earned Value numbers are not only wrong, they provide no real value for guiding management in decisions that impact the future performance of the program. ¨ Consider using Earned Schedule [ES] to complement Earned Value [PMI EV]. Earned Schedule is a method of deriving schedule performance from Earned Value data [Lipke], [Henderson04], [Vanhoucke] ChapterII 73
  • 74. Conformance With Technical Performance Measures Adjusts EV Performance Values Technical Performance Measures (TPMs) are traditionally defined and evaluated to assess how well a system is achieving its performance requirements. Typically, dozens of TPMs are defined for a system. Although they generate useful information and data about a system’s performance, little is available in the program management community on how to integrate these measures into a meaningful measure of the system’s overall performance risk. TPMs may be combined to measure and monitor the overall performance risk of a system. The approach consists of integrating individual technical performance measures in a way that produces an overall risk index. The Program Manager must be cognizant of three basic program elements (baselines): § Cost § Schedule § Technical Performance The first two are tracked through cost and schedule control systems (earned value). The last is tracked through the technical performance measurement (TPM) system. TPM is the program manager’s early warning system, when correlated to cost and schedule reports, to provide the complete status of the program. The TPM method includes selecting Technical Performance Parameters; assigning weights; linking to CWBS; planning progress over time; getting data; evaluating variances; and taking corrective action as needed. Variances indicate level of risk and detect new risks before their effects on cost/schedule are irrevocable. The TPM approach involves: § Assessing technical characteristics of the system and identify problems through tests/analyses. § Surfacing inadequacies in time and dollars. § Complements cost/schedule performance measurement § Providing a basis for cost/schedule revisions. § Facilitating the verification of results achieved against technical requirements and what remaining technical work can be accomplished within established budgets. ChapterII 74
  • 75. Conformance With Technical Performance Measures Adjusts EV Performance Values ¨ Adjust the “Earned Value” forecast of future performance by the compliance with Technical Performance Measures (TPM). ¨ Correlate Technical Performance Measures with cost and schedule to provide the complete status of the program. ¨ Use Technical Performance Measures to add “technical achievement” to Earned Value’s cost and schedule metrics. ¨ Assess the program’s progress in terms of technical compliance, potential rework, postponed functionality (to later Work Packages or rolling waves) and other dilutions of the physical progress of the program. ¨ Use Technical Performance Parameters (TPPs) to indicate key areas for risk reduction and program success. ¨ Technical Performance Measures (TPMs) are a time–phased progress plan for achievement of critical TPPs. ChapterII 75
  • 76. Performance Feedback Used To Adjust WP Sequence and Resource Allocation Earned Value Management (EVM) is a program management tool integrates Cost and Schedule parameters as an early warning system for future performance of the program. But the EVMS standard states that EV is a measurement of quantity (BCWP), not quality, of the work accomplished. As far back as 1997, the discussion was integrating Cost, Schedule, and Technical Performance. Robust systems engineering and software engineering processes should provide technical performance measures (TPM) and exit criteria for assessing technical maturity that are quantitatively linked to Earned Value. Adjusting the To Complete Performance Index (TCPI) and the Independent Estimate At Complete (IEAC) for less than planned technical performance measurements – quality, missing scope, delayed scope, or combinations of these and other less than planned outcomes. These TPMs are defined and evaluated to assess how well a system is achieving its performance requirements. Technical performance measurement uses actual or predicted values from engineering measurements, tests, experiments or prototypes. The introduction the Earned Value Management Intent Guide speaks to this but better guidance is needed [Solomon]. To provide the needed feedback for adjusting the TCPI and IEAC values , the following activities need to be performed: § Include systems engineering activities in the schedule and the Performance Measurement Baseline (PMB). § Establish thresholds or parameters for TPM in the program plan. § Specify objective measures of progress as base measures for EVM for: Development maturity to date, product’s ability to satisfy requirements, Product metrics, including TPM achievement‒to‒date. § Review program’s plans, activities, work products and performance measurement baseline for consistency with the requirements and the changes made to the requirements baseline. § Incorporate risk mitigation plans in the program plan, including changes to the PMB. § Include quantified risk assessments in the EAC depending on the probability of risk occurrence and the impact on cost objectives. With this information, TCPI and IEAC can be adjusted to reflect the Physical Percent Complete of the Work Packages, not just the Cost and Schedule performance measures. ChapterII 76
  • 77. Performance Feedback Used To Adjust WP Sequence and Resource Allocation ¨ Adjust the Work Package sequence using feedback from the performance measures to maintain compliance with the Measures of Effectiveness (MoE), Measures of Performance (MoP), and Technical Performance Measures (TPM). ¨ TPM methodology includes: ¤ Selecting TPPs; assigning weights; linking to CWBS; planning progress over time; getting data; evaluating variances; and taking corrective action as needed. ¤ Variances can indicate level of risk and detect new risks before their effects on cost/schedule are irrevocable. ¨ Assess of the technical performance characteristics of the system to identify problems by: ¤ Having assessments coincide with cost reporting and completion of significant design tasks. ¤ Surfacing inadequacies in time and dollars. ¤ Complementing the standard cost/schedule performance measurement. ¤ Providing the basis for cost/schedule revisions. ¤ Facilitating the verification of results achieved against technical requirements and that remaining technical work can be accomplished within established budgets. ChapterII 77
  • 78. Forecast Of Future Performance Based On TCPI, IEAC, and Work Sequence Employing Earned Value Management can present a program with data not available with any other management tool. And while each metric can be useful, there are two metrics are particularly useful in the management of any project, or program, or a portfolio of projects. The Cost Performance Index (CPI) is a reflection of program cost efficiency. The CPI relates the physical work accomplished, expressed in its budgeted value, against the actual costs incurred to accomplish the performed work. Budgets can be set with various monetary values, hours, deliverables, or anything else that can be measured. The question: Is the program staying on target, under running, or perhaps overrunning costs? Perfect cost performance would be defined as achieving a CPI of 1.0: For every dollar spent, we would get an EV equal to one dollar. Sometimes we do better, sometimes worse. This is a particularly critical metric to track because performance at less than 1.0 is a reflection of excessive costs spent against budget. Initial overruns are typically non‒recoverable. Think about it: In order to recover an overrun, future work must be underrun. Rarely does this happen. The same conditions which may have caused the overrun in the first place are likely to occur again and again. The CPI is an indicator of past cost performance, the TCPI has its focus on future performance. The question: What will it take to meet the goals set by management? The TCPI works in conjunction with the CPI. TCPI = Work Remaining / Funds Remaining The CPI can be thought of as sunk‒costs; whatever the results, they cannot be altered. The TCPI is the efficiency needed to regain the lost performance from the past. ChapterII 78
  • 79. Forecast Of Future Performance Based On TCPI, IEAC, and Work Sequence ¨ Develop a new forecast of cost and schedule with the new sequence of Work Packages. ¨ Base this forecast on the To Complete Performance Index (TCPI) and the Independent Estimate At Complete (IEAC) [Henderson08]. ¨ There are five IEAC indices. ¤ IEAC1 = BAC / CPI ¤ IEAC2 = ACWP + (BAC – BCWP) / SPI ¤ IEAC3 = ACWP + (BAC – BCWP) / (SPI x CPI) ¤ IEAC4 = ACWP + (BAC – BCWP) / ((wt1 x SPI) + (wt2 x CPI)) ¤ IEAC5 = ACWP + (BAC – BCWP) / CPIx ChapterII 79
  • 81. Deploying the five core processes of Deliverables Based Planning® is an incremental and iterative activity. Each incremental step increases the maturity of the project or program deliverables. 81 IIIDeploying Deliverables Based Planning® Chapter
  • 82. 82 Putting The Five Core Processes of Deliverables Based Planning® to Work Define the set of capabilities needed to achieve the program objectives or the particular end state for a specific scenario. Using the ConOps, define the details of who, where, and how it is to be accomplished, employed and executed. 1 Define the technical and operational requirements that must be in place for the system capabilities to be fulfilled. First, define these requirements in terms that are isolated from any implementation technical products. Only then bind the requirements with technology. 2 Build a time–phased network of schedule activities describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables, and the performance measures showing this work is proceeding according to plan. 3 Execute work packages, while assuring all performance assessment are 0%/100% complete before proceeding. No rework, no forward transfer of activities to the future. Assure every requirement is traceable to work and all work is traceable to requirements. 4 Perform the 6 process areas of Continuous Risk Management for each Deliverables Based Planning® process area to Identify, Analyze, Plan, Track, Control, and Communicate programmatic and technical risk 5 Chapter III
  • 83. Define the set of capabilities needed to achieve the program objectives or the particular end state for a specific scenario. Using the ConOps, define the details of who, where, and how it is to be accomplished, employed and executed. Process Activities Outcomes or Deliverables Benefits Using the supplied Statement of Work (SOW), Statement of Objectives (SOO) extract a description of the operational behavior of the system in a Concept of Operations (ConOps) and an associated process flow diagram. A Process Flow Diagram of the system with verbs in the boxes and nouns on the lines. This can be done in Visio using the IDEFÆ notation, or some other systems engineering process and element diagramming method [IDEFÆ]. A single diagram showing the system components, the data or actions it produces, and how these components interact. This diagram shows the increasing maturity of the system as is proceeds from left to right in the Integrated Master Plan (IMP), through each Program Event. With the Process Flow Diagram, identify the Accomplishments for each Milestone or Event. Identify the dependencies between each Accomplishment within and between the Integrated Product Team (IPT) stream. For each Event or Milestone, build a single page chart for each Accomplishment for each Integrated Product Team (IPT) members work stream. These diagrams show how each Event or Milestone will be met from the completion of the Accomplishment s. With the dependencies identified, a top level precedence diagram is now available for the development of the Integrated Master Schedule (IMS). With each Accomplishment defined and arranged in a sequence of increasing maturity within the Event or Milestone, capture the Criteria for the assessment of the Accomplishment. These Criteria are the “Exit Criteria” for the Work Packages containing the Work Tasks. The exit criteria for the work effort will be defined in terms meaningful to the assessment of Physical Percent Complete and the completion of the Accomplishment. Connections from Milestone or Event, to Accomplishments and to the Criteria describe the increasing maturity of the program. This is more than just the traditional list of items in the Integrated Master Plan. But a description of the program’s process flow and its increasing value. 1 Chapter III83
  • 84. Define the technical and operational requirements that must be in place for the system capabilities to be fulfilled. First, define these requirements in terms that are isolated from any implementation technical products. Only then bound the requirements with technology. Process Activities Outcomes or Deliverables Benefits Identify the end user and system functional requirements through a requirements flow down process in some type of database system. This doesn’t have to be a large scale tool, but it must provide some sort of change control and tracking of the requirements. In order to make requirements trade offs, the requirements must be organized in a logical manner. Starting organized, keeping organized, and tracing changes to the requirements is part of the requirements elicitation and management processes. Keeping requirements under control is a critical success factor for controlling the scope of the program. Not changes to the requirements baseline can be made without on impact assessment. Build a Requirements Traceability Matrix between the SOW, SOO, ConOps, CDRLs, DID’s and any other document containing requirements. Place these requirements in a database so “pivots” and “coverage” assurance can made between all the sources. There may be conflicting requirements on the program. This will never be known early if all the requirements are not in one place, under the control of the Change Board The requirements elicitation process has five (5) steps: § Fact finding § Gathering and Classifying § Evaluation and Rationalization § Prioritization § Verification and Validation These must be performed in an iterative, incremental, and logical sequence, capturing the resulting “emergence” of the requirements baseline through each cycle. A requirements system model that captures facts, classifications, evaluation, rationalizations, prioritizations, and verifications in a Requirements Management Database of some form. By organizing the requirements in the form of a database is a critical success factor for the program. With this database, traceability of the requirements from the system capabilities to the technical and operational deliverables. Only by building these traceability relationships, can trade offs be made in the presence of distributions in the program due to funding, requirements, and technical changes. 2 Chapter IIIChapter III84
  • 85. Build a time–phased network of schedule activities describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables, and the performance measures showing this work is proceeding according to plan. Process Activities Outcomes or Deliverables Benefits Using the Events or Milestones, Significant Accomplishments, Accomplishment Criteria, the Work Packages and Planning Packages are constructed for each Accomplishment Criteria. These Work Packages are the starting point for the Integrated Master Schedule The Work Packages contain the resources and work activities needed to produce a deliverable represented by the Accomplishment Criteria – the outcome of the Work Package. An Integrated Master Schedule (IMS) for the work effort needed for each Accomplishment Criteria is the starting point for optimizing the program execution description. The IMS describes the work activities needed to increase the maturity of the delivered product or service. The Exit Criteria for these work activities are measured by the Accomplishment Criteria – the measureable outcome of each Work Package. The Accomplishment Criteria are the entry conditions for the Significant Accomplishments. The Significant Accomplishments describe the current maturity of the deliverables in units of measure defined during the development of the Integrated Master Plan (IMP). The increasing maturity of the program can be measured through assessments of Physical Percent Compete. These units of measure are derived from the Technical Performance Measures of the delivered article at the specific time point in the schedule. By connecting cost, schedule, and technical performance in a time–phased assessment process, the Program Manager will have insight into the progress of the program, not just as assessment of cost and schedule performance. With the sequenced Work Packages, the labor and other direct costs are applied to the Integrated Master Schedule (IMS). This Labor and Cost Spread reveal speaks and valleys in the labor assignments. These must be smoothed to match the actual labor availability before further analysis of the IMS can take place. An “all in” IMS contains all work, all resources, all dependencies , all risk mitigation and retirement plans, and all assessment processes of the increasing maturity of the program. With the IMS in place, budget spreads are “balanced “ across the collection of Work Packages to meet the objective measures of the organization and the technology BCWS balanced spreads across the current rolling wave and across planning packages. Visibility into the budget demands and labor utilization for ach rolling wave and planning packages. 3 Chapter IIIChapter III85
  • 86. Execute work packages, while assuring all performance assessment are 0%/100% complete before proceeding. No rework, no forward transfer of activities to the future. Assure every requirement is traceable to work and all work is traceable to requirements. Process Activities Outcomes or Deliverables Benefits The duration between measurements of progress must be tuned to the business rhythms of the program. A simple question is how long are you willing to wait before you find out you are too late to take corrective action? Periodic Business Rhythm Meetings where a simple Status Report is reviewed and forecasts for the performance in the next period are committed to. Measuring progress in physical percent complete units provide visibility in ways not possible with simple measures of cost and schedule. Coupling cost, schedule, and technical performance is the basis of Performance Based Earned Value Define the Business Rhythm to provide timely insight into the progress of the program. This should be a minimum of a monthly performance report. A published Business Rhythm Process Flow with deliverables, data sources, work processes, accountabilities, and an archive for this information. Bi–weekly and monthly measures of performance are used to guide management decisions. Capturing the physical percent complete starts with defining the agree on units of measure of performance for each Work Package (WP) allocated to the Control Account. These measures must match the technical assessment of the products or services provided from the WP. Apportioned milestones, 0/100% complete descriptions and other measures of Physical Percent Complete are defined in the WBS Dictionary. Measurements of progress are done through evidentiary materials – artifacts from the program that can be “seen” by the program stakeholders, rather than just “reported” on. By connecting cost, schedule and technical performance in the assessment of progress can the program determine how is it progressing, how efficient the resources are working and what the risk adjust Estimate to Complete is. Project status report that measures the Physical Percent Complete for Apportioned Milestones, 0/394 deliverables or other evidentiary materials of progress. Defining these measures “before” the execution of the WPs provides a baseline for measurement of Physical Percent Complete. 4 Chapter IIIChapter III86