Chapter 0 of Performance Based Project Management (sm)

Chapter

Performance-Based Project
Management(sm) integrates
Principles, Practices, and
Processes to assure actionable
information is provided to the
decision makers that can
increase the probability of
program success.

0

Performance-Based Project Management(sm)
in a Nutshell

1

Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013

Chapter 0

Performance-Based Project Management Management(sm)

In A Nutshell
5 Principles, 5 Practices, and 5 Processes to
Increase The Probability of Project Success

2


Chapter 0

Why Performance-Based Project Management(sm)?
§  For projects to be
successful they must
deliver capabilities:
§  Not the work efforts,
§  Not the cost expenditures,
§  Not the documentation, test
results, or the processes.

Principles, Practices, and Processes for
Increasing the Probability of Project
Success†
† Program Success Probability, John Higbee, Defense Acquisition
University, 9 May 2005

§  Projects must deliver
tangible beneficial
outcomes, measured in
units meaningful to the
decision makers.
3/230

Five Immutable Principles of Project Success
in the form of questions …
1.  What Does DONE Look
Like?
2.  How Do We Get to DONE?
3.  Is There Enough Time,
Resources, And Money To
Get to DONE?
4.  What Impediments Will Be
Encountered Along The
Way to DONE?
5.  What Are The Units Of
Measures For Progress To
Plan for each Deliverable?

4

5

1. Organization
Define the Work Breakdown
Structure(WBS).
Indentify the Organizational
Breakdown Structure (OBS).
Integrate the WBS and OBS.
¨ 

¨ 
¨ 
¨ 

2. Planning and Budgeting
¨  Schedule the work.
¨  Identify the Products and
Milestones.
¨  Set the time phased budget.

¨ 

¨ 
¨ 
¨ 

3. Accounting
Record direct costs.
4. Performance Analysis
Determine variances.
Sum Data and variances.
Manage action plans.

5. Revision Management
¨  Incorporate Changes.

Chapter 0

5 Critical Process Areas that Answer the 5
Principle Questions of Project Success

6

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)
¨ 

Chapter 0

Credible Data Is Need to Increase
The Probability Of Program Success

7

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.
¨  PBPM connects the data to provide actionable
information to the decision makers.
¨ 


Chapter 0

Systems Management Guides the Conversion of
this Data to Produce Actionable Information

8

Program Process Capabilities

Program Enablers

Business Enablers


Chapter 0

16 Program Management Processes

9

¨ 

Capabilities start with a mission
level analysis.

This is planning
in the large.
¨  This is planning
in the presence
of change.
¨  The focus is on
transformational
outcomes.
¨ 


www.rand.org

Chapter 0

Origins of Performance-Based Project
Management(sm)

10
Performance-Based Project Management(sm) integrates five
critical program management process areas with – Cost,
Schedule, and Technical Performance Measures.
The inclusion of Technical Performance Measures (TPM)
separates is 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 Performance-Based Project Management(sm), 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.

Chapter 0

4+1 questions every project must answer

The 4+1 Questions
Every Project Must
Answer to be Successful
Capabilities Requirements

Plans

Execution + Continuous Risk Management

1.  What capabilities are needed to fulfill the Concept of Operations†,
Œ the Mission and Vision, or the Business System Requirements?
2.  What technical and operational requirements are
 needed to deliver these capabilities?
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?


†

11

What impediments to success, their mitigations, retirement plans,
or “buy downs are in place to increase the probability of success?”

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 0

12

Project Management Case Study, Pierre Bonnal, CNAM IIM MBA Program, June 2004

Chapter 0

Addresses …

Identify Needed
Capabilities

System Value
Stream

Operational
Needs
Capabilities
Based Plan

Identify
Requirements
Baseline

Technical
Performance
Measures

Technical
Requirements

Establish a
Ž Performance

PMB

Measurement
Baseline
Technical
Performance
Measures

Changes to
Needed Capabilities

Changes to
Requirements Baseline

Earned Value
Performance
0% /100%

Execute the
 Performance

Changes to
Performance Baseline

Measurement
Baseline


13


Chapter 0

14
1.  Identify Needed Capabilities to achieve program objectives
or a 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 and
planned cost. Define these requirements in terms that are
isolated from any implementation technical products or
processes. Only then bind the requirements with
technology.
3.  Establish a 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 assessments are 0%/100%
complete before proceeding. No rework, no transfer of
activities to the future. Assure all requirement are
traceable to work and all work is traceable to
requirements.
5.  Perform Continuous Risk Management for each
Performance-Based Project Management(sm) 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 Performance-Based Project Management(sm).
Each process area stands alone and at the same time is
coupled with the other process areas. Each process area
contains specific 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 ways not know until the project is too far along to
be recovered.
Each process provides information needed to make decisions
about the maturity flow of the project. This actionable
information is the feedback mechanism needed to keep a
project under control. These control processes are not
impediments to progress, but are the tools needed to
increase the probability of success.

Chapter 0

Increasing the Maturity of Project Processes
and Deliverables with Meaningful Measures

15

Identify
Needed
Capabilities

Indentify
Baseline
Requirements

Establish
Performance
Measurement
Baseline

Execute
Performance
Measurement
Baseline

Perform Continuous Risk Management (CRM)
§ Define Capabilities
§ Define ConOps
§ Assess Needs, Cost, and
Risk Impacts
§ Define Balanced and
Feasible Alternatives

§ Fact Finding
§ Gather And Classify
§ Evaluate And
Rationalize
§ Prioritize Requirements
§ Integrate And Validate

§ Decompose Scope
§ Assign Accountability
§ Arrange Work
§ Develop BCWS
§ Assign Performance

Define the Measurable
Capabilities of each
Project Outcome

Assure All Requirements
Provided In Support of
Capabilities

Define Measures of
Performance and
Effectiveness


§ Perform Work
§ Accumulate
Performance Measures
§ Analyze Performance
§ Take Corrective Action

Ensure Cost, Schedule,
and Technical
Performance Compliance

Chapter 0

Increasing the Maturity of Project Work
Processes and Their Deliverables

16

Project Management Case Study, Pierre Bonnal, CNAM IIM MBA Program, June 2004.

Chapter 0

What is a Deliverable?

Œ
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 Performance-Based Project
Management(sm) process area to: Identify, Analyze, Plan, Track, Control, and Communicate
programmatic and technical risk.
17


Chapter 0

Œ

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

§ 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.

1.2

§ 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.

1.3

§ 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.

1.4

§ 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.

18


Chapter 0

19


Chapter 0

What Does A Capability “Sound” Like?

20
Identifying System Capabilities is the starting point for any
successful program. System Capabilities are not direct
requirements, but statements of what the system should
provide in terms of “abilities.”
For example there are three capabilities needed for the
Hubble Robotic Service 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 known 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 statements 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 are fulfilled by the program.
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. Success means providing the needed
capabilities, on or near schedule and cost.
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 Use Cases and scenarios to provide the context
to measure the level of capability.

Chapter 0

Identifying Needed System Capabilities

Chapter 0

Identifying Needed System Capabilities
21

What Should We Do?

Where Are We Now?

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



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

§ 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.

2.2

2.3

2.4

2.5

22

§ 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.

Chapter 0

23


Chapter 0

What Is a Requirement?

24
Requirements are defined attributes for an item prior to the
efforts to develop a design for that 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.
Requirements act as the transformation between the
customer’s capabilities 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
Process Performance Requirements define how the work
processes are used to produce a beneficial outcome to the
customer.
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 product
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
(WBS). 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 are “foot
and tied” to the Performance Measurement Baseline (PMB) to
provide the traceability of the increasing maturity of the
deliverables (vertical) and the physical percent complete of
the work efforts (horizontal).

Chapter 0

Identifying Requirements

25

†Systems Requirements Practices, Jeffery O. Grady, McGraw Hill, 1993


Chapter 0

Identifying Requirements†

Ž

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.

3.1

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.2

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.3

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.4

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.5

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.6

Establish a Performance Measurement Baseline (PMB) used to forecast the Work Package and
Project ongoing and completion cost and schedule performance metrics.
26


Chapter 0

27


Chapter 0

What Does a Credible Plan and
Schedule Look Like?

28
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.

The Technical Performance Baseline represents the
requirements flow down and traceability map for each
deliverables in the program.

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.

§  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.

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 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 DI-MGMT-81861.

The concept of Performance-Based Project Management(sm) is.

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.

§  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.
There are three elements to the Performance Measurement
Baseline:

Chapter 0

Establishing the Three Elements of the
Performance Measurement Baseline

Chapter 0

Establishing the Three Elements of the
Performance Measurement Baseline
29
Perform
Functional
Analysis

Technical Baseline

Determine
Scope and
Approach

Develop
Technical
Logic

Develop
Technical
Baseline

Estimate
Time
Durations

Sequence
Activities

Approve
PMB

Develop
WBS

Define
Activities


Finalize
Apportioned
Milestones

Identify
Apportioned
Milestones

Schedule Baseline

Cost Baseline

Finalize
Schedule

Determine
Resource
Requirement

Prepare
Cost
Estimate

Resource
Load
Schedule

Determine
Funding
Constraints



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.

4.1

§ 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.2

§ 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.3

4.4

4.5

30

§ 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.
§ 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.
§ 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.

Chapter 0

31


Chapter 0

How Do We Know We Are Making
Progress to Plan?

32
With the Performance Measurement Baseline established, its
execution is now the next critical activity.
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?”
Management(sm)

In the Performance-Based Project
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
Performance-Based Project Management(sm).
The measures of physical percent complete can be applied
on weekly boundaries in a variety of 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.


Chapter 0

Executing the Performance Measurement
Baseline (PMB)

33


Chapter 0

Executing the Performance Measurement
Baseline (PMB)



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

§ 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.

5.2

§ 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.

5.3

§ 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.

5.4

§ 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.

5.5

§ 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.

34


Chapter 0

35

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

Statement of Risk
Identify Risks, Issues, and
Concerns

Analyze
Evaluate, classify, and prioritize
risks

Plan
Decide what should be done
about each risk

Program/project data
(metrics information)

Tr a c k
Monitor risk metrics and verify/
validate mitigations

Control
Make risk decisions

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

Chapter 0

Perform Continuous Risk Management

36
For project success to have a chance, we need all the parts of
the project’s architecture to be in place.
This starts with the Statement of Work (SOW), the Concept
of Operations (ConOps), Statement of Objectives (SOO)and
similar narrative documents and supporting graphics showing
what the system will do, who is involved, and the artifacts
and outcomes of the results from the project.
With these in hand, we can build the Work Breakdown
Structure (WBS) for the deliverables. The WBS is product
centric, along with the services that produce the products. The
WBS does not describe the organizations producing the
products. That is done in the Organizational Breakdown
Structure (OBS). At the terminal nodes of he WBS are the
Work Packages that produce the deliverables.
From the WBS, the technical and operational requirements
can be derived. These define the behaviors of the
deliverables through Key Performance Parameters. The
customer’s KPPs come first, followed by the project’s KPPs in
the CWBS.
The Integrated Master Plan (IMP) describes the Program
Events, Significant Accomplishments, and Accomplishment
Criteria needed to increase the maturity of each deliverable
through the project’s lifecycle. The IMP is the single most
important document for properly executing the project.
Without the IMP, we cannot tell what Done looks like.

From the IMP, the Integrated Master Schedule (IMS) is
developed. The IMS sequences the Work Packages that
perform the work to produce the deliverables. This sequence
defines the critical path, the resources needed to perform the
work, the order of the work, and the dependencies between
the work efforts.
Using the IMS, the Earned Value Management techniques for
each Work Package is defined. Measures of Physical Percent
Complete are the best choice.
For each Work Package, Technical Performance Measures
(TPM) are used to assure the resulting outcomes meet the
requirements of the SOW, SOO, and ConOps.
With all these components, the Performance Measurement
Baseline can be established, showing the time phased
budget, work effort, deliverables, and assessment of
increasing maturity of the outcomes.

Chapter 0

Integrating all the Parts Into a Whole

Chapter 0

Integrating all the Parts into a Whole
37

SOW

Techncial
and
Opera9onal

Requirements

Customer

Key
Performance
Parameters

(JROC
KPP)

WBS

SOO

ConOps

CWBS
&

CWBS
Dic9onary

Program
Speciﬁc

Key
Performance
Parameters

(KPP)

Measures
of

Eﬀec9veness

(MoE)

Integrated
Master
Plan

(IMP)

Measures
of

Performance

(MoP)

Integrated
Master
Schedule

(IMS)

Measures
of

Progress

Earned
Value
Management

System

Technical
Performance

Measures
(TPM)

Performance
Measurement
Baseline

Risk
Management

Objec9ve
Status
and
Essen9al
Views
to
support
the
proac9ve
management
processes
needed
to
keep
the

program
GREEN

38
Measures of Effectiveness (MoE) – are the operational
measures of success that are closely related to the
achievements of the mission or operational objectives
evaluated in the operational environment, under a specific
set of conditions.

Technical Performance Measures (TPM) – are attributes
that determine how well a system or system element is
satisfying or expected to satisfy a technical requirement or
goal.

These measures are stated in units ,meaningful to the buyer.
They focus on the capabilities independent of any technical
implementation.

TPMs assess design progress, define compliance to
performance requirements, identify technical risk, are limited
to critical thresholds, and include projected performance
goals.

Measures of Performance (MoP) – characterize physical or
functional attributes relating to the system operation,
measured or estimated under specific conditions.

Connecting the Mission Need – capabilities produced by the
project – with the MoEs, MoPs, KPPs, and TPMs must be done
for the project to have a chance of success.

These measures are attributes that assure the system has the
capability and capacity to perform. They are an assessment
of the system to assure it meets the design requirements to
satisfy the Measures of Effectiveness.
Key Performance Parameters (KPP) – Represent the
capabilities and characteristics so significant that failure to
meet them can be cause for reevaluation, reassessing, or
termination of the program. KPPs have a threshold or
objective value that characterize the major drivers of
performance that are considered Critical to Customer (CTC).


Chapter 0

From Mission Capabilities to Done

Chapter 0

From Mission Capabilities to Done
39

Acquirer
Defines
the
Needs
and
Capabili9es

in
terms
of
Opera9onal
Scenarios

Supplier
Defines
Physical
Solu9ons
that

meet
the
needs
of
the
Stakeholders

KPP

Mission
Need

“Coming
to
Grips
with
Measures
of

Effec9veness,”
N.
Sproles,
Systems

Engineering,
Volume
3,
Number
1,
pp.
50–58

MoE

MoP

Opera&onal

measures
of
success

related
to
the

achievement
of
the

mission
or

opera&onal

objec&ve
being

evaluated.

Measures
that

characterize

physical
or

func&onal
a<ributes

rela&ng
to
the

system
opera&on.

TPM

Measures
used
to

assess
design

progress,

compliance
to

performance

requirements,
and

technical
risks.

40


Chapter 0

41


Chapter 0

Chapter 0

4+1Critical Success Processes
42

Capabilities,
Requirements &
Deliverables

Program
Architecture &
Dependencies

Work
Planning and
Sequencing

Performance
Measurement
Baseline

Programmatic
& Technical Risk
Management
§ Risk Registry
§ Risk Handling
Plans
§ Contingency And
Management
Reserve
§ Risk Integrated
With IMS
§ Risk Trending

§ 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

§ Requirements
Traceability

§ Value Stream
Mapping

§ Work Packages
§ Planning Packages

§ Technical
Performance
Measures (TPM)

§ Earned Value
Management

§ Measures Of
§ Monte Carlo
Performance (MoP) Simulation

§ Measures Of
§ Design Structure
Effectiveness (MoE) Matrix (DSM)

Chapter 0

Program Support Services
43

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

44

P-B PM Capabilities

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.

Chapter 0

Tangible Benefits of

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?
45


Chapter 0

46


Chapter 0

Chapter 0 of Performance Based Project Management (sm)

More Related Content

What's hot

Viewers also liked

Similar to Chapter 0 of Performance Based Project Management (sm)

More from Glen Alleman

Recently uploaded

Chapter 0 of Performance Based Project Management (sm)