All projects ‒ Traditional and Agile ‒ operate in the presence of uncertainty that creates risk. Five Immutable Principles and their supporting Processes and Practices can be used to increase the probability of success in the presence of these uncertainties.

1. +
Showing how to Increase the Probability of Project Success
by applying the
Five Immutable Principles of Project Management
in Under Four Hours
All projects ‒ Traditional and Agile ‒ operate in the presence of uncertainty that creates risk.
Five Immutable Principles and their supporting Processes and Practices can be used to increase the
probability of success in the presence of these uncertainties.
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019
1
Glen B. Alleman
12 July 2019

2. 2
Four Hours is All We Have
To Address Universal Issues of Project Poor
Performance for the Reasons Given in the Next
Chart
So It’s Going to Be…

3. Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019 3
“Why do so many projects overspend
and overrun?
Because they’re managed as if they
were merely Complicated when in fact,
they are Complex.
They’re planned as if everything is
known at the start when in fact, they
involve high levels of uncertainty that
create cost, schedule, and technical
risk.”
In, Architecting Systems: Concepts, Principles and Practice,
Hillary Sillitto, College Publications, 2014.

4. + Why Agility Matters in the Presence
of Uncertainty? †
 Agility Reflects Reality ‒ accepting uncertainty, driving it
out, and reprioritizing efforts based on new information is
how the world works
 Agility Enables Flexibility ‒ the freedom to make the right
decisions at the right time, based on the right amount of
information.
 Agility is Path to the Present ‒ the expectation of
customers, users, and buyers, is that things will be on a
path of constant improvement and zero issues, or they’ll
jump to the next most available platform.
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019
4
† Agility is an attribute of the process, a system, or a procedure used to manage project.
Agile is a software development paradigm. All Projects need to managed with Agility
Let’s focus on Agility in all project management processes, then we’ll get to Agile and Scrum later in this presentation.

5. + Four Immutable Truths of Product
Development and Project Management
 You can’t gather all the requirements upfront
 The requirements you do gather, will change after you’ve
gathered them
 There will always be more work than there is time and
money available to perform that work
 Estimates of cost, schedule, and technical performance
will always be off by some factor, and this factor is likely
to be unknown early in the project
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019
5
These Immutable Truths are independent of the product
development or project management method
‒ Agile or Traditional

6. + Performance–Based Project
Management® Addresses …
Project Management Case Study, Pierre Bonnal, CNAM IIM MBA Program, June 2004
 Project management is about
avoiding surprises.
The Need
 Organizations execute
projects through people,
processes, and tools.
The
Context
 Defines deliverables measured with increasing probability of
project success based on cost, schedule, and technical
performance measures.
 Uses risk adjusted Earned Value Management to remove
surprises.
The
Solution
 Management requires
processes that create
measurement data need for
decision making.
The
Problem
… identifies tangible outcomes
rather than just data outputs.
 Projects, by their very nature,
are risky endeavors, with
uncertain outcomes.
The
Situation
… buys down risks through
continuous risk management
connected with project controls.
… measures of physical percent
complete to forecast the future.
… adapts an organizational
culture to the risk tolerance
levels of the project’s
environment.
The Traditional Approach New Approach …
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2019
6
6
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019

7. Why Performance–Based Project Management®?
 Successful projects
deliver Capabilities to
accomplish a mission or
fulfill a business strategy:
 Not work efforts,
 Not cost expenditures,
 Not documentation, test
results, or the processes.
 These are all needed, but
they’re not Deliverables.
 For success, projects
must deliver tangible
beneficial outcomes,
assessed in units of
measure meaningful to
the decision makers.
 Effectiveness
 Performance
Performance–Based Project
Management®
Principles, Processes, and Practices
for Increasing the Probability of
Project Success†
† Program Success Probability, John Higbee,
Defense Acquisition University, 9 May 2005
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2019 7

8. 1. What Does DONE Look
Like?
2. How Do We Get to DONE?
3. Is There Enough Time,
Money, and Resources, To
Get to DONE?
4. What Impediments Will Be
Encountered Along The
Way to DONE?
5. What Units of Measure are
used to confirm Progress
To Plan Toward Done?
All Successful Projects Require Credible Answers
To These 5 Immutable Principles …
8 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2019

9. + What Does Done Look Like in Units of
Measure Meaningful to the Decision Makers?
 Start with Capabilities Based Planning
 Defining Measures of Effectiveness (MOE) for Capabilities
 Defining Measures of Performance (MOP) for Capabilities
 Connecting MoE and MoP to Business Value
 Establish the Business Rhythm to Deliver Capabilities
 Traditional – measures of increasing maturity of the deliverables
 Agile – Cadence or Readiness release of Capabilities
 Define the Roles and Responsibilities for Executing the
Business Rhythm
❶
9
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019

10. +
How Do We Get To Done?
 Transforming Capabilities Plan to Product Roadmap
 This is applicable for Traditional and Agile
 If You Don’t Know Where You’re Going, You’ll End Up Somewhere
Else ‒ Yogi Berra
 Decomposing Capabilities to Features
 This is independent of the Project Management method, with
Traditional or Agile
 This is a Capabilities Based Planning principle
 Building Backlog of work
 For Agile this is called a Product Backlog
 For Traditional is is called a Work Breakdown Structure connected to
the Master Schedule
 Building Release Train for Delivering Value as Planned
 This is applicable to both Agile and Traditional project management
 When will we be able to use the planning Capabilities?
❷
10
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019

11. +
What Resources do We Need?
 Time
 How much time?
 What the Schedule Margin for that period of performance?
 Money
 How much money?
 What’s the Management Reserve and Contingency needed for that
planned budget?
 Staff
 Who?
 What skills?
 Cost?
 Facilities
 Anything special ‒ test cambers, full scale models?
 Enabling Tools and Processes
 Development tools
 Testing tools
 Release Management tools
❸
11
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019

12. + What Impediments Will We
Encounter Along the Way to Done?
 All Risk Comes from Uncertainty
 Reducible Uncertainty (Epistemic) creates risk
 Irreducible Uncertainty (Aleatory) creates risk
 Research shows Aleatory uncertainty dominates most project domains
 Managing in the Presence of Uncertainty
 Find the Source of these Uncertainties
 Determining Root Cause of Uncertainties
 Provide Corrective or Preventive Actions to reduce (Epistemic) or
Margin (Aleatory)
 Develop a Risk Management Plan
 Buydown activities
 Margin ‒ cost, schedule, and technical
 Integrate the Risk Management Plan into the Business
Rhythm (Agile or Traditional)
❹
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019
12

13. +
Measuring Progress to Plan, by …
 Assessing Physical Percent Complete
 Measures of Effectiveness (MOE)
 Measures of Performance (MOP)
 Technical Performance Measures (TPM)
 Key Performance Parameters (KPP)
 Key System Attributes (KSA)
 Risk Buy Down measured against needed risk reduction plan
 Cost and Schedule Margin erosion
 Delivering Capabilities to Market as Planned is
foundation of Mission and Business Success
❺
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019
13

14. Capabilities Requirements Plans Execution  Continuous Risk Management
† A Concept of Operations (ConOps) describes the characteristics of a proposed system from the viewpoint of an individual who will use
that system. It is used to communicate the quantitative and qualitative system characteristics to all stakeholders.
The 4  1 Elements
Needed To Increase
Project’s Probability of
Success
14 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019

15. 12°
Grade
We need the Capability to drive over Schofield Pass between Crested
Butte and Marble Colorado, climb a 12°grade on loose rock following
a one–way single track trail, with a 30% chance of thunder showers in
early afternoon.
15 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019

16. 16
All legislative
Powers herein
granted shall be
vested in a
Congress of the
United States,
which shall
consist of a
Senate and
House of
Representatives.
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019

17. 17
A Schedule is NOT a Plan.
A Plan is the strategy for the successful completion of the project; the
Schedule is the description of the work to produce that success.
Both Plans and Schedules are needed!
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019

18. 18
Deliverables
WBS
Tasks and Schedule
Business Need
Process Invoices for
Top Tier Suppliers
1st Level
Electronic Invoice
Submittal
1st Level
Routing to Payables
Department
2nd Level
Payables Account
Verification
2nd Level
Payment Scheduling
2nd Level
Material receipt
verification
2nd Level
“On hand” balance
Updates
Work
Package
(WP)
1 2
3
4
6
5 A
B
Deliverables defined in WP
Terminal Node in the WBS
defines the products or
services that produce the
products of the project
Terminal node of the
WBS defined by a Work
Package.
Tasks within the Work
Package produce the
Deliverables
100% Completion of the
deliverables is the measure of
performance for the Work Package
Management of the
Work Package Tasks is
the responsibility of
the WP Manager.
A decomposition of the work
needed to fulfill the business
requirements
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019

19. 19
http://www.sei.cmu.edu/risk/index.html
RISK MANAGEMENT IN FIVE
EASY STEPS
1. Hope is NOT a strategy
2. No single point estimate of
cost or schedule can be
correct
3. Cost, Schedule, and
Technical Performance are
inseparable
4. Risk management requires
adherence to a well defined
process
5. Communication is the #1
success factor
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019
Risk Management is Project Management for Adults ‒ Tim
Lister

20. 20
How
Where
When
Who
Why
What
Identify Needed
Capabilities
Establish a
Performance
Measurement
Baseline (PMB)
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
1
2
3
4
Technical
Performance
Measures
PMB
Continuous Risk Management Process
Changes to
business strategy
Changes to
requirements
Changes to
project plan
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019

21. + Increasing the Maturity of Project
Work Processes and
Deliverables
21
Identify
Capabilities
Needed for
Success
Identify
Requirements
to Deliver
Capabilities
Establish
Performance
Measurement
Baseline
Execute
Performance
Measurement
Baseline
 Define Capabilities
 Define Concept of
Operations
 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 Budget
 Assign Performance
 Perform Work
 Accumulate
Performance Measures
 Analyze Performance
 Take Corrective Action
Perform Continuous Risk Management (CRM)
Define the Measurable
Capabilities of each
Project Outcome
Assure All Requirements
Provided In Support of
Capabilities
Define Measures of
Performance and
Effectiveness
Ensure Cost, Schedule,
and Technical
Performance Compliance
21 3 4
5
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019

22. +
What is a Deliverable?
22
 The Deliverable is not the final assembled product.
 The Deliverable is the outcome of Work whose result increases the
measurable maturity (Effectiveness and Performance) of the final
assembled product.
 Performance is specified and measurable.
 Design is complete and verifiable.
 Development is complete and testable.
 Testing complete, verified, and validated.
 Installation and deployment complete and operational.
 Work Packages consume time and resources.
 Work Packages are owned by a single accountable person.
 Work Packages produce deliverables.
Project Management Case Study, Pierre Bonnal, CNAM IIM MBA Program, Jun
Deliverables Incrementally Increase A Capability’s Maturity
Deliverables Result From “Units Of Work” – The Work Package
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019

23. 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® process area to: Identify, Analyze, Plan, Track,
Control, and Communicate programmatic and technical risk.

Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201923 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2019

24. 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 a desired objective 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

Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201924 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2019

25. What Does A Capability “Sound” Like?
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2019
25

26. 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
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2019
26

27. 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 met 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

Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201927 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2019

28. What Is a Requirement?
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2019
28

29. 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

Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201929 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2019

30. Establishing the Three Elements of
the Performance Measurement
Baseline
Cost Baseline
Schedule Baseline
Technical Baseline
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
Requireme
nt
Prepare
Cost
Estimate
Resource
Load
Schedule
Finalize
Apportioned
Milestones
Determine
Funding
Constraint
s
Approve
PMB
Perform
Functional
Analysis
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2019
30

31. 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

Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201931 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2019

32. How Do We Know We Are Making
Progress to Plan?
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2019
32

33. Executing the Performance
Measurement Baseline (PMB)
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2019
33

34.  Identify and classify risks in a Risk Register. Separate reducible and Irreducible risks
 Manage this Risk Register through a Risk Management Board.
 Connect these risks and their handling and margins 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 decision making information and actions (both present and
future).
 Develop actions to address individual risks, prioritize risk actions, and create an integrated
risk management plan to retire the risk or handle it when it turned into an issue.
 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 with 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

Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201934 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2019

35. 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
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2019
35

36. +
 Know what Done looks like in units of measure meaningful
to the decision makers,
 Identify uncertainties to cost, schedule, and technical
performance that create risk, in any credible manner and
take corrective or preventive action to handle the Risk
created by these uncertainties,
 Have a credible cost, schedule, and technical risk adjusted
estimating process, and
 Measure progress to plan as physical percent complete on
the planned date measured with Technical Performance
Measures and their Quantifiable Backup Data.
We Don’t …
The KILLER Problem(s) with All
Projects – Traditional or Agile
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019
36

37. Performance–Based Project
Management® 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?
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201937 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2019

38. 5 Practices Needed the Implement the
5 Immutable Principles
Identify Capabilities with
measurement units meaningful to
the customer
Identify Technical and Operational
Requirements to deliver
capabilities
Establish risk adjusted Technical,
Cost, and Schedule Baseline(s)
Execute PMB with measurement
units meaningful to the decision
makers
Apply Continuous Risk
Management
38 Performance Based Management(sm), Copyright ® Glen B. Alleman, 2012

39. Estimating is not Soothsaying or Fortune Telling, it’s good Engineering Practice based on
Probability and Statistics aided by Past Performance data
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019 39
This Leaves the
Estimating Problem

40. + Estimates Must Be Both Top Down
and Bottom Up
A full cycle estimating process, starting at the Top, but continuously
re-assesed with past performance as new understanding emerges
from the Bottom
Reference Class
Estimates from
Past
Performance
Confirmation of
Estimates
based on Team
Input and
ConsensusPerformance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019
40

41. + Factors Affecting Credibility of the
Estimates Must Be Address
Optimism bias
Influences
estimates
Experience
Makes Better
Estimates
An Incorrect
Specification
Introduces
Errors
Pessimism
Adds Extra
Time and Cost
Rushing
Results
produces Poor
Estimates
Optimism
Pessimism
Experience
Time Scales
Spec
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019
41

42. +
Why We Needed Estimates
Creating reliable cost, schedule, and technical performance
estimates is a critical success factor for all projects.
Without these estimates, business value is at risk of
experiencing cost overruns, missed deadlines, and
performance shortfalls—all recurring problems that projects
assessments too often reveal.
Unanticipated cost increases often mean the business
cannot fund needed projects or deliver value when promised.
Unanticipated schedule delays means the needed value is
not delivered as planned, lowering the revenue of value
recognition in exchange for the sunk cost of development.
www.gao.gov/new.items/d093sp.pdf
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2019
42

43. Deploying the five core
Processes and Practices of
Performance–Based Project
Management® is an
incremental and iterative
activity.
Each incremental step
increases the maturity of the
project or program
deliverables.
Applying
Performance
Based Project
Management® in
an Agile
Development
Environment
43 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2019

44. pyright © 2017 - 2019 Niwotridge Consulting, LLC
Framework for Integrating Agile and
Project Performance Management
Performance
Reporting from
Feature level to
overall project
Project
Performance
• Budget
• Actual costs
• Performance –
from Physical %
Complete
Release 1 Release n
Feature 1,2,3
Feature 4, .. ,8
Feature 9, …,12
Release 2 PP’s
Work
Packages
Containi
ng
Features
Products
Sprints
Time Now
Performance Baseline
Agile Software Development Lifecycle
Feature n’s
Milestones
Data Items
Releases
Capabilities in a Release
Development Budgetary Accounts
…
Physical Percent Complete captured at Task and Story level, Rolled to Release Plan by Feature in
Work Packages to produce Performance Management metrics used for Estimate At Complete
Product Road Map (Capabilities)
Release Plan of Each Capability
44
…

45. pyright © 2017 - 2019 Niwotridge Consulting, LLC
Closed Loop Feedback Control
for Agile at Scale
10 Process for Increasing the Probability of
Success for Tradition and Agile Projects
❶ Engineering
Estimate
❷ Product
Roadmap
❸ Release
Plan
❺ Work Plan
❻ Master
Schedule
❹ Schedule
with
Features
❼ Work Estimates
❽ Physical Percent
Complete
❿ Update Estimate
at Completion
❾ Update Estimate to
Complete
Plan
Do
Check
Act
Continuous feedback at each step with
corrective actions for Root Cause of
Performance Variances
45

46. pyright © 2017 - 2019 Niwotridge Consulting, LLC
1. Assess past performance for
similar Features used for
estimates, captured in Agile
development tool
2. Rank Feature with Ordinal
measure if needed (Story
Points, Tee Shirts)
3. Focus of Cardinal estimates
in hours
4. Assure Features include all
exit criteria and risks
5. Assure Features have
minimal dependencies
6. Define sequence of
deliverables, in preparation
for Product Roadmap
Project Performance Management Agile
Engineering Estimate
1. Decompose needed
Capabilities into Features
2. Estimate effort in hours,
derived from past performance
to deliver the Feature
3. Determine uncertainties
around that estimate
1. Reducible uncertainty
2. Irreducible uncertainty
4. Model these uncertainties with
Crystal Ball® to 80%
confidence
 Use Triangle distribution if
actual distribution not known
5. Establish Change Control
process for updates to this
estimate as the project
progresses
❶
+
46

47. pyright © 2017 - 2019 Niwotridge Consulting, LLC
1. In the WBS Dictionary, define
Capabilities of each Feature
(DoD = definition of done)
with measures of:
 Effectiveness
 Performance
 Technical
 Key Performance
Parameters
2. Assign Budget in Hours for
FTE (staff) to each period of
performance to the Features
in the assigned Work
Package
1. Build Roadmap from ROM
and Engineering Estimate for
sequence of Features
accepted by customer
2. Put the Features in the
proper order in the Roadmap
in Agile Management System
3. Publish Roadmap for the
Scrum Team in hardcopy
Project Performance Management Agile
Product Roadmap
❷
+
47

48. pyright © 2017 - 2019 Niwotridge Consulting, LLC
1. In the Master Schedule,
layout and sequence
Features in Work Packages
for the number of Sprints to
produce each Feature
2. Establish Change Control for
modifying the Release Plan in
the Schedule as the project
progresses
1. Assign Features to Releases
2. Code this information in Agile
Management System
3. Update Roadmap with
Release Information for each
Feature from the final
accepted ROM
Project Performance Management Agile
Release Plan of Product Capabilities
❸
+
48

49. pyright © 2017 - 2019 Niwotridge Consulting, LLC
1. Obtain hours by Feature from
the Rough Order of
Magnitude (ROM) Estimate
2. Validate Budget against the
Release Plan
3. Baseline Work Packages with
Budget and period of
performance for each Feature
1. Feature Period of
Performance shown in with
Release Plan
2. Original Estimates from ROM
recorded in Backlog traceable
to the schedule
Project Performance Management Agile
Integrated Master Schedule with
Features in Work Packages
+
❹
49

50. pyright © 2017 - 2019 Niwotridge Consulting, LLC
1. The Features in the Backlog
are traceable to the
Engineering Estimate and to
the Planned Value in the PMB
2. Use the Backlog as source
material for Roadmap, along
with the Budget for each
Feature
 Story Points or Tee Shirt
relative sizes can be
assigned in the PBL for
prioritization purposes
 These sizes are not
duration, cost, complexity,
or any Cardinal measure
1. Backlog built from Roadmap
using Features from
Engineering Estimate and
any further decomposition
into Stories
2. Effort estimate in Hours, can
be derived from the relative
measures once a Reference
Class Forecasting databased
has been built
Project Performance Management Agile
Product Backlog
❺
+
50

51. pyright © 2017 - 2019 Niwotridge Consulting, LLC
1. Confirm Performance above
the line is in lock step with
the work planned below the
line.
2. Confirm FTE spread for
Period of Performance for
Work Packages in the Master
Schedule
1. Capacity for work is primary
Sprint Planning process
2. Confirm needed skill set to
complete the work and
remove blocking factors
within Sprint
Project Performance Management Agile
Sprint Backlog
❻
+
51

52. pyright © 2017 - 2019 Niwotridge Consulting, LLC
1. Confirm TASK EST is still proper value
for the Feature being executed in the
Sprint
 If not, update the Forecast in
Schedule and Performance
Reporting system
2. The role of the Planner is to update
the Forecast in the Master Schedule
and Performance Reporting system to
reflect Sprint and Feature planning
and execution
 This foot and tie the Forecast with
the Physical Percent Complete
 They are complements of each
other
1. Decompose Features into Stories and
Tasks
2. Estimate Tasks in TASK EST field in
Agile Management System
 Once Sprint starts this field is
frozen
 Initially TO DO = TASK EST
3. When Sprint starts, update TO DO
field as work progresses
 TO DO goes down as work is
completed
 TO DO goes up as new more work
is discovered
4. Update FEATURE FORECAST if
 Current estimated work > TASK
EST
 Remaining work is expected to take
longer than the initial estimate
 Note: Forecast should only include
in-scope changes
Project Performance Management Agile
Task Estimating for the Sprint †
❼
+
52
† The TASK EST is in Rally as a default, Jira can be configured to do the same

53. pyright © 2017 - 2019 Niwotridge Consulting, LLC
1. The updated TO DO from the
Daily Standup is used to
calculate Physical Percent
Complete
2. This is used to calculate
Percent Complete on a daily
basis, as well as at month
end:
 Current performance is
available daily
 This reporting path assures
accurate month end status
that relies on TO DO
updates from the Daily
Standup
1. TO DO should be updated at
the Daily Standup
2. When the estimated effort
changes to be different than
baselined in the TASK EST
field – TO DO is updated
3. TO DO value
 Goes down as the work is
completed
 Goes up when new work (in
scope) is discovered for the
Task, Story, therefore for
the Feature
Project Performance Management Agile
TO DO Updates of Sprint Work
❽
+
53

54. pyright © 2017 - 2019 Niwotridge Consulting, LLC
1. No need to ask anyone what
the status is, Agile
Management System has the
status at the lowest level of
the project ‒ live on a daily
basis
2. Feature Physical Percent
Complete values are imported
to the Master Schedule and
used to status Features in
Work Packages
3. Use the custom report to
extract performance from Agile
in the form of Physical Percent
Complete
4. Feature Physical Percent
Complete on the custom report
is a rollup from Tasks to the
Feature level
1. The Physical Percent
Complete values are
exported from Agile
Management System in a
custom report
2. Feature Physical Percent
Complete is calculated from
the rollup of the TO DO field
and the Feature Forecast
Project Performance Management Agile
Feature Physical Percent
Complete in the Master Schedule
❾
+
(∑ TASK EST – ∑ TO DO) / Feature Forecast
54

55. pyright © 2017 - 2019 Niwotridge Consulting, LLC
1. Update ETC
 Periodically update ETC by
Labor Category for Work
Packages
 Verify that the resulting ETC
hours still match the Master
Schedule and the Sprint work
to do
2. Update Performance
 Physical Percent Complete
from Agile is also used in
Performance Measurement
system
 Based on the Business
Rhythm, update Physical
Percent Complete for Work
Packages
 Calculate Performance
1. Confirm reported Physical
Percent Complete foot and
ties with Physical Percent
Complete in Agile
Management System to
acceptable degree of
accuracy and precision
 This is an eye ball
assessment, the number
may or may not be exactly
the same, so close enough
is a value judgement of
the Planners and PM
2. As part of the Performance
analysis processes, provide
performance assessment and
suggested corrective actions
Project Performance Management Agile
Performance Management
Updates of Work Packages
❿
+
55

56. Deploying the five core
Processes and Practices of
Performance–Based Project
Management® is an
incremental and iterative
activity.
Each incremental step
increases the maturity of the
project or program
deliverables.
Applying
Performance
Based Project
Management® in
any Product
Development
Environment
56 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2019

57. ⑤ImmutablePrinciples
ofProgramSuccess
① What does Done Look Like? ➉ Practices Implementing Five Processes, supporting Five Principles
② What’s the Plan to Reach Done?
CapabilitiesDrive
Requirements,
RequirementsIdentify
Deliverables,
WorkPackages
ProduceDeliverables,
MasterSchedule
Sequences
Deliverables,
ProgressMeasuredAs
PhysicalPercent
Complete,
WorkAuthorization
AssuresProper
Sequencing,
PhysicalPercent
MeasuresTangible
Performance,
UsingTechnical
PerformanceMeasures,
withQBD’s
ThatProvidesFeedback
toAdjustWork
Sequencing,for
FuturePerformance
UsingRealisticEstimate
toComplete
③ What Resources are needed to reach Done as
Needed?
④ What Risks are encountered on the way to Done?
⑤ What are the Units of Measure of progress toward
Done?
⑤ Processes Supporting Five Principles and Their Sub‒Processes
❶
Identify Needed
Capabilities,
Measures of
Effectiveness and
Performance to fulfill
Mission and Vision
1.1 Define Capabilities As Operational Concepts
1.2 Define Operational Concepts As Scenarios or Use Cases
1.3 Simultaneously Assess – Needs, Costs, and Risks to
Capabilities
1.4 Define Explicit, Balanced, and Feasible Alternatives
❷
Establish the needed
Technical, Schedule,
and Cost
Requirements for
each Capability, the
delivery date and
estimated cost
2.1 Perform Fact Finding for Technical, Cost, Schedule
Baseline
2.2 Gather and Classify Technical and Operational
Requirements
2.3 Evaluate and Rationalize Requirements
2.4 Prioritize Requirements with Risk Adjusted Measures
2.5 Integrate and Validate Requirements
❸
Establish
Performance
Measurement
Baseline (PMB)
showing how to
Deliver the Technical
and Operational
Requirements for the
needed Cost on the
needed Date
3.1 Decompose Work Packages and Planning Packages
3.2 Assign Accountability for Deliverables
3.4 Arrange Work Packages in Logical Order
3.5 Assign Work Package Technical Performance Measures
3.6 Develop Planned Budget for Work Packages
3.7 Set Performance Measurement Baseline
❹
Execute the PMB
and assess Physical
Percent Complete at
intervals needed to
make Corrective and
Preventive Actions
4.1 Perform Authorized Work in Planned Order
4.2 Accumulate and Report Work Package Performance
4.3 Take Corrective or Preventive Actions to Stay On Plan
4.4 Maintain Performance Measurement Baseline
Perform Continuous
Risk Management for
reducible and
irreducible risk with
5.1 Identify Technical and Programmatic Risks
5.2 Analyze Risks to Determine if Reducible or Irreducible
❶ ❷ ❸ ❹ ❺ ❻ ❼ ❽ ❾ ❿
Copyright ©, 2019, Performance‒Based Project Management, Glen B. Alleman

58. 58Glen B. Alleman, Copyright © 2019