Immutable Principles of Project Management (Toronto PMI)

Improving the Probability of Project
Success
with
Five Immutable Principles
Glen B. Alleman
Niwot Ridge, LLC
glen.alleman@niwotridge.com
+1 303 241 9633
All projects ‒ no matter domain ‒ are fraught with Technical, Cost,
and Schedule uncertainties, that create risk to project success.
Five Principles of Project Success increase the Probability of Project
Success (PoPS) through the application of Risk Management to all
Practices and Procedures
11:00 ‒ 11:55, 27 October 2018
Lincoln Alexander Centre, Hamilton, Ontario, Canada
Glen B. Alleman, Copyright © 2018

1st a Warning
We’re going to cover a lot of material
in under 55 Minutes
Glen B. Alleman, Copyright © 2018 2/50
PMI Lakeshore Ontario Symposium, 27 Oct 2018

During this Time, Our Learning
Objectives are …There are many – maybe too
many – methods for
successfully managing a
project.
We need to remember, Yogi’s advice …
In theory, there is no difference between theory and practice.
In practice, there is. 3/50
LO1
LO2
LO3
But, no matter how many,
each method must possess
5 Immutable Principles to
be successful, no matter
the domain or context.
To increase the Probability
of Success, we need to
assure our work is guided
by these 5 Project
Management principles.

Do We Need
Risk Management?
and the Processes that come with it?

Why? ‒ Because Projects are collections of
Nonlinearly Coupled Probabilistic and
Statistical Processes that create Risk to the
Probability of Project Success
Risk Management is Project Management for Adults ‒ Tim Lister

Projects Can Be Characterized as ‒
Unpredictable, Uncertain, Risky, or Variable
(UURV)†
Risk comes from not knowing what you're doing ‒ Warren
Buffett
 Unpredictable ‒ randomness among unknowable possibilities
 Uncertain ‒ randomness among known possibilities with unknowable probabilities
 Risky ‒ randomness among known possibilities with knowable probabilities
 Variable ‒ randomness among knowable variables and knowable variance ranges
It’s the Unpredictable ‒ an Ontological Uncertainty ‒ that is Primary
Root Cause of Project Failure
Imprint of a bird that encountered an ontological uncertainty and struck
our west facing second story window on a bright Colorado afternoon.
The Bird Survived
† Discovering Agile SE Process Fundamentals at INCOSE, Rick Dove

Risk Management is essential for development and production programs. Information
about key project cost, (technical) performance, and schedule attributes is often uncertain
or unknown until late in the program.
Risk issues that can be identified early in the program, which will potentially impact the
program later, termed Known Unknowns and can be alleviated with good risk
Research Shows 4 Root Causes of Cost and
Schedule Overruns,
and Technical Shortfalls on Projects
Unrealistic Performance Expectations,
missing Measures of Effectiveness
(MOE) and Measures of Performance
(MOP).
Unrealistic Cost and Schedule estimates
based on inadequate risk adjusted
growth models.
Inadequate assessment of risk and
unmitigated exposure to these risks
without proper handling plans.
Unanticipated technical issues without
alternative plans and solutions to
maintain effectiveness.
Poor Cost,
Schedule,
and
Technical
Project
Performance
Principles,Processes,
andPracticesneededto
CorrectandPrevent
“Borrowed” with permission from Mr. Gary Bliss,
Director, Performance Assessment and Root
Cause Analysis (PARCA), Office of Assistant
Secretary of Defense for Acquisition,
Technology and Logistics.

The
customer
contracted
for a
“Capability”
This is why
are
Deliverables
the Best
Measure of
… We need the
Capability to fly
to LOE, with 4
PACs on board,
dock at ISS, stay
for 90 days, and
return safely
The Capability
here is …
8/50

The Framing Assumption for
This Session†
Risk Management is essential for (both)
development and production programs.
Information about key project cost, (technical)
performance, and schedule attributes is often
uncertain or unknown until late in the program.
Risk issues that can be identified early in the
program, which will potentially impact the program
later, termed Known Unknowns and can be
alleviated with good risk management.
‒ Effective Risk Management 2nd Edition
Edmund Conrow, AIAA, 2003† A Framing Assumption (FA) is any explicit or implicit assumption that is central in shaping cost, schedule,
or performance expectations of an acquisition program. FAs may change over the course of execution, or
new ones may be added.
“Identifying Acquisition Framing Assumptions Through Structure Deliberations,” Mark Arena and Lauren
Mayer, RAND TL153 9/50Glen B. Alleman, Copyright © 2018

The 5 Immutable
Principles of Project
Success
Project Success does not start with the contents of
PMBOK®.
As the name says ‒ These are just a guide
PMBOK® shows the components of a method, but
does not show how to put these components
together to increase the probability of projectGlen B. Alleman, Copyright © 2018 10/5

... for every complex problem, there is a
solution that is neat, simple, and wrong. ‒
H. L. Mencken
Before We Start on the Road to Success,
We Need to Understand …
11/50Glen B. Alleman, Copyright © 2018

1. What Does Done Look
Like in Units of
Measure Meaningful to
the Decision Makers?
2. How Do We Get to
Done as Needed?
3. Do We Have Enough
Time, Resources, And
Money To Get to Done?
4. What Impediments Will
We Encounter Along
The Way To Done?
5. How Do We Know We
Are Making Progress
Toward Done?
Immutable Principles Project
Success

Q1. What Does Done Look Like?
“Capabilities First, only then, Elicit Requirements” ‒ Is Domain
Dependent
“Design and integrate 18 major weapon systems and their
platforms simultaneously within strict size and weight
limitations, while synchronizing development,
demonstration, and production of as many as 157
complementary systems with the Future Combat System
content and schedule.” (This is an actual requirement)
“Implement 8 stories for our new
warehouse inventory tracking
system using the existing web site
platform as a starting point.”

Three steps to success
 Plan – is a strategy for
successful completion of the
project.
 Schedule – are the steps
needed to fulfill the Plan.
 Execution – is the physical
performance of the steps
needed to deliver the results
defined in the Plan to
implement the Strategy.
If we do not know which port we are steering for, no wind is
Favorable ‒ Seneca
14/50

Action Outcome
Implement Strategy
Ensure Capabilities
Prioritize Problems And
Identify Redundancies
Deliver Solutions
† “Capabilities‒Based Planning: A Methodology
for Deciphering Commander’s Intent,” Peter Kossakowski, 15/50
Stating Capabilities, Deciphers the Intent of Management†

16
Identifying Needed Capabilities Starts
with Knowing what Done Looks Like
Where Should We Be?
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

Q2. What is the Plan to Get To Done?
Some problems
respond to
lightweight
approaches, like
Scrum, DSDM, Crystal,
and XP as product
development
methods.Others require more
complex approaches,
like a System of
Systems (SoS) spiral
development
processes.
In all cases a
disciplined approach
increases the
probability of success
– no matter the
complexity of the
problem or the
This approach
works well when we
don’t know what
“done” looks like
with enough clarity
So
Does
This!

Three Elements of a Credible Plan
Required for Project Success
Cost Plan
Schedule Plan
Technical Plan
Determine
Scope and
Approach
Develop
Technical
Logic
Develop
Technical
Baseline
Develop
WBS
Define
Work
Activities
Estimate
Time
Durations
Sequence
Activities
Finalize
Schedule
Identify
Apportione
d
Milestones
Determine
Resource
Requirement
Prepare
Cost
Estimate
Resource
Load
Schedule
Finalize
Apportioned
Milestones
Determine
Funding
Constraints
Approve
Plan
Perform
Functional
Analysis

Scheduling
Only comes
after
Planning
 What are the
individual,
dependent and,
sequential steps
needed to deliver
these Capabilities?
 The schedule has
durations,
dependencies,
timing, dates,
resources and
other things
related with to
Plan.
 The idea that 19/50
No sensible decision can be made
without taking into account, not
only the world as it is, but the world
as it might be. ‒ Isaac AsimovGlen B. Alleman, Copyright © 2018

If we can compute the probability of success of a satellite that has never flown
before,
Confidence in Cost, Schedule, and Technical
Performance is driven by Uncertainty, that Creates
Risk, which must be addressed and reduced as the
project proceeds
Current Confidence Range

Q3: Do We Have Everything We Need to Get
to Done? 21/50Glen B. Alleman, Copyright © 2018

Q3. Do We Have Enough Time,
Money, and Resources To Get To
Done?
A Common Problem A Simple Solution
We have undue optimism.
Use documented procedures – no matter the
method – for estimating and planning using
historical data.
We attempt to avoid risk and
uncertainty.
Understand and prioritize risks for each critical
component empowers management and staff.
Use this knowledge to control your optimism.
We rely too much on intuitive
judgment.
Simple statistical models are more often correct
than human judgment.
Have the numbers to back up your intuition.
The Rational Planning of (Software) Projects, Mark C. Paulk, Software Engineering Institute, Carnegie Mellon
University, Pittsburgh, PA 15213–3890
In the resource management business,
optimism is always the source of trouble

Q4: What Are the Impediments to Getting to
Done?
Risk Management is Project Management for Adults ‒ Tim
Lister
Innovation requires Risks Taking.
Risk Taking requires taking Calculated Risks.
We know Risk comes from Uncertainty, calculated Reducible and Irreducible Risk must
be Managed if our project is to be successful

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 Number One success factor
Q4. What Impediments Well Be
Encountered Along the Way to
Done?

Uncertainties
is something
we can not be
certain about.
Uncertainty is
created by our
incomplete
knowledge;
not by our
ignorance.Glen B. Alleman, Copyright © 2018 25/50

No Point
Estimate,
without
variance
measure
s, Can Be
Correct

Taxonomy of Uncertainties that Create
Irreducible and Reducible Risk
Require Estimates of Direct and Residual
Impacts of these risks on the Probability
of Project Success
Uncertainty
Irreducible
(Aleatory)
Reducible
(Epistemic)
Natural
Variability
Ambiguity about
behavior of
process Ontologica
l
Uncertaint
y
Probability of
Event’s
Occurrence
Probabilistic
Impact from
Event
Period of
Exposure to
Event
Period of
Exposure to
Aleatory Process

Risk
Management
Demands
Direct
Communicati
on Between
All
Participants
in the Project

Continuous Risk Management Means
We Take These Steps for Every Risk
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

Connecting Continuous Risk Management to
Decision Making Processes is the Foundation for
Increasing the Probability of Project Success
Top N Risks Assigned
Responsibili
ty
Required
Indicators
Status / Forecast
Risks
Technical
Leads
Team
Members
Project Lead

Q5:
How Do We Know We Are
Making Progress Toward
Done?

32/50
Primary Measures
of Progress to
Plan
Are We Done?
When will we be Done?
What will it cost to be
Done?
What does Done look like
for the customer?
How will we recognize
Done when it arrives?
What’s our confidence of
getting to Done?
Are we removing or
reducing impediments toGlen B. Alleman, Copyright © 2018

Technical Performance
Measure(s) …
 Use actual or predicted values from:
– Engineering measurements
– Tests
– Experiments
– Prototypes
 For Example:
– Response time
– Range
– Power
– Weight
– MTTFF/MTTR/MTBF
 Tell us how well a system is achieving the planned
performance requirements at the planned time, for
the planned cost in units of Physical Percent Complete
to Plan
… are Attributes determing how well a system or
system element is satisfying or expected to satisfy a
technical requirement or goal.

Q5. How Do We Know If We Are Making
Progress We Planned To Make?
The only measure of progress is Physical Percent
Complete for the planned deliverables.
A
Physical Percent Complete means tangible evidence
of the outcomes that were planned – measured at
the time they were planned to be delivered.
B
This is the basis for full Earned Value Management
with Physical Percent Complete.
This is also a natural fit with the agile approaches to
software development.
C
All successful methods measure evidentiary
outcomes in units meaningful to the stakeholders.
These units must be more than “money” and “time.”
D
34/50

Trade Offs Between
Cost, Schedule,
and
Technical
Performance is a
Ponzi Scheme
without Margin and
a Risk Management
Plan
When we’re on baseline,
the algebraic
relationship between
C,S,P, means when
there is a change in one
of these measures
everyone looses. 35/50Glen B. Alleman, Copyright © 2018
Charles Ponzi,
Born March 3, 1882, Italy.
Died Jan 18, 1949, Brazil.
Served 5 years federal prison,
9 years state prison,
deported to Italy.

Physical Percent Complete
 Measuring Physical Percent
Complete is the core of every
successful project management
method.
 It answers the question of what
“done” looks like in units of
measure meaningful to the decision
makers.
 It answers questions like:
– What does done look like for today, this
week?
– What does done look like for entry/exit
into the technical review?
– What does done look like for quality
No stretching the
truth allowed once
we measure
Technical
Performance with
tangible evidentiary
materials at the time
they are supposed
to appear.

We Know We’re Applying the 5
Principles if …
We have a defined Mission, Vision, Capabilities,
and Requirements, by which to create, …
1
the Plan for fulfilling these capabilities and
requirements and the Schedule for producing the
needed outcomes to meet this Plan; and have, …
2
allocated enough Time, Money, and Resources to
increase the probability of our project’s success;
by …
3
knowing what Risks are in front of us and the
retirement and mitigation plan; and we can, …
4
measure progress as Physical Percent Complete
for each planned Deliverable in our Plan “on or
before” its planned time and “at or below” the
planned cost.
5

The Five Principles Of Project Success
No Matter the Domain or Method
What does done look like?
How do we get to done?
Resources to get to Done?
Impediments to getting to
Done?
Measuring progress to Done?

Evidence of the 5 Principles into
PracticePrinciple
Traditional
Practice
Agile
Practice
What does Done Look Like
in Units of Measure
Meaningful to the Decision
Makers?
Capabilities Based Planning
with Measures of
Effectiveness and
Performance
Product Road Map
How do we get to Done? Integrated Master Plan Release Plan
What Resources needed to
get to Done?
Resource loaded Integrated
Master Schedule
Agile development team
staff assignments to
Sprints, Integration and
User Acceptance Testing
What are the Impediments
to getting to Done?
Management Plan for Reducible and Irreducible
Uncertainties that Create Risk
What are the Meaningful
Measures of Progress
toward Done?
using risk adjusted
Performance Management
to produce Estimate to
Complete
measuring progress to
Release Plan and Product
Roadmap outcomes as
planned

The Project Train Wreck Starts When
There Is …
 Inattention to budget, schedule and
technical responsibilities.
 Work authorizations not always
followed (out of sequence work).
 Issues with Budget, Schedule, and
Technical data reconciliation.
 Lack of an Integrated Management
System.
 Plans fluctuations with frequent
replanning.
 Improper use of Management Reserve.
 Performance Measures don’t reflect
actual Physical Percent Complete.
 Lack of predictive variance analysis from data.
 Untimely and unrealistic Revised Estimates.
 Progress to Plan not monitored in a regular and consistent
manner.
 Lack of connection between cost, schedule, and technical
performance.
 Lack of project performance oversight by independentGlen B. Alleman, Copyright © 2018 41/50

If We Learned Anything Today, it Should
be …
… So no matter our tolerance for risk, or the
methods we use to Manage Projects
The 5 Immutable Principles Must Always in

All Project Success is Built on Principles and the Practices and Processes that
Implement those Principles
The notion that we can Make Things Up as we go has no Basis in Fact

Glen B. Alleman
Niwot Ridge Consulting
4347 Pebble Beach Drive
Niwot, Colorado 80503
303.241.9633
glen.alleman@niwotridge.com
Performance-Based Project Management®
Integrated Master Plan
Integrated Master Schedule
Earned Value Management Systems
Risk Management
Proposal Support Services
Performance-Based Project Management® is a field proven, practical
approach to increasing the Probability of Program Success by
providing actionable information in units of measure meaningful to
the decision maker.

Backup for Risk Management
Process
PMI and SEI Risk Management
Processes are a starting point.
Here’s a Risk Management
Processes from an actual
Program

"Knowledge is of two
kinds. We know a
subject ourselves, or
we know where we
can find information
upon it. When we
enquire into any
subject, the first thing
we have to do is to
know what books
have treated of it.
This leads us to look
at catalogues, and at
the backs of books in
libraries."
— Samuel Johnson
(Boswell's Life of
Johnson)

Principles and Processes for Project Success
 “Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities,”
INCOSE–TP–2003–002–03.1, August 2007, www.incose.org
 Systems Engineering: Coping with Complexity, Richard Stevens, Peter Brook, Ken Jackson,
and Stuart Arnold, Prentice Hall, 1998.
 Henri Fayol: Critical Evaluations in Business and Management, John C. Wood and Michael
C. Wood, Routedge, 2002.
 “Technical Performance Measurement, Earned Value, and Risk Management: An
Integrated Diagnostic Tool for Program Management,” Commander N. D. Pisano, SC, USN,
Program Executive Office for Air ASW, Assault, and Special Mission Programs (PEO(A))
 “Architectural optimization using real options theory and Dependency structure matrices,”
David M. Sharman, Ali A. Yassine+, Paul Carlile, Proceedings of DETC ’02 ASME 2002
International Design Engineering Technical Conferences 28th Design Automation
Conference Montreal, Canada, September 29–October 2, 2002.
 “Modeling and Analyzing Cost, Schedule, and Performance in Complex System Product
Development,” Tyson Browning, Massachusetts Institute of Technology, February 1999.
 “The Integrated Project Management Handbook,” Dayton Aerospace, 8 Feb 2002, Dayton
Ohio.
 “Analytic Architecture for Capabilities–Based Planning, Mission–System Analysis, and
Transformation,” Paul K. Davis, RAND Corporation.

Identify Needed System Capabilities
 “Analytic Architecture for Capabilities–Based Planning, Mission–System Analysis, and
Transformation,” Paul K. Davis, RAND Corporation.
 Portfolio–Analysis Methods for Assessing Capability Options, Paul K. Davis, Russell D.
Shaver, and Justin Beck, Rand Corporation, 2012
 “Architectural optimization using real options theory and Dependency structure matrices,”
David M. Sharman, Ali A. Yassine+, Paul Carlile, Proceedings of DETC ’02 ASME 2002
International Design Engineering Technical Conferences 28th Design Automation
Conference Montreal, Canada, September 29–October 2, 2002.
 “Modeling and Analyzing Cost, Schedule, and Performance in Complex System Product
Development,” Tyson Browning, Massachusetts Institute of Technology, February 1999.
 The Art of Systems Architecting, Mark W. Maier and Eberhardt Rechtin, CRC Press, 2000.
 Systems Engineering: Coping With Complexity, Richard Stevens, Peter Brook, Ken Jackson,
and Stuart Arnold, Prentice Hall, 1998.
 Assumption Based Planning: A Tool for Reducing Avoidable Surprises, James A. Dewar,
Cambridge University Press, 2002.
 Capabilities–Based Planning: A Methodology for Deciphering Commander’s Intent, Peter
Kossakowski, Evidence Based Research, Inc. 1595 Spring Hill Road, Suite 250 Vienna, VA
22182.
 Competing on Capabilities: The New Rules for Corporate Strategy, George Stalk, Philip
Evans, and Lawrence Shulman, Harvard Business Review, No. 92209, March–April 1992.
 Effects–Driven, Capabilities–Based, Planning for Operations, Maj Kira Jeffery, USAF and Mr
Robert Herslow.
 Effects–based Operations: Building Analytical Tools, Desmon Saunder–Newton and Aaron
B. Frank, Defense Horizons, October 2002, pp 1–8.
 Guide to Capability–Based Planning, Joint Systems and Analysis Group, MORS Workshop,

Establishing the Requirements Baseline
 “Issues with Requirements Elicitation,” Michael G. Christel and Kyo C. Kang, Technical
Report, CMU/SEI–92–TR–12, Software Engineering Institute, Carnegie Mellon University
Pittsburgh, Pennsylvania 15213.
 The Requirements Engineering Handbook, Ralph R. Young, ArcTech House, 2004
 Software Risk Management, Barry W. Boehm, IEEE Computer Society Press, 1989.
 Software Requirements Analysis & Specifications, Alan M. Davis, Prentice Hall, 1990.
 Requirements Engineering: A Good Practice Guide, Ian Sommerville and Pete Sawyer, John
Wiley & Sons, 1997.
 Systems Requirements Practices, Jeffery O. Grady, McGraw Hill, 1993
 “Four Key Requirements Engineering Techniques,” Christof Ebert, IEEE Software, May /
June 2006.
 “Intent Specifications: An Approach to Building Human–Centered Specifications,”
Aeronautics and Astronautics, MIT.
 “Sample TCAS Intent Specification,” Nancy Leveson and Jon Damon Reese, Software
Engineering Corporation .

Project Risk Management
 “Understanding Risk Management in the DoD,” Mike Bolles, Acquisition Research Journal,
Volume 10, pp. 141–145, 2003.
 Effective Risk Management: Some Keys to Success, 2nd Edition, Edmund H. Conrow, AIAA
Press, 2003.
 Managing Risk: methods for Software Systems Development, Elaine M. Hall, Addison
Wesley, 1998
 “Integrating Risk Management with Earned Value Management,” National Defense Industry
Association.
 “Three point estimates and quantitative risk analysis a process guide for risk practitioners,
Acquisitioning Operating Framework,” UK Ministry of Defense,
http://www.aof.mod.uk/index.htm
 Effective Opportunity Management for Project: Exploring Positive Risk, David Hillson,
Taylor & Francis, 2004.
 Catastrophe Disentanglement: Getting Software Projects Back on Track, E. M. Bennatan,
Addison Wesley, 2006.
 Software Engineering Risk Management, Dale Walter Karolak, IEEE Computer Society Press,
1998.
 Assessment and Control of Software Risks, Capers Jones, Prentice Hall, 1994
 “Three Point Estimates and Quantitative Risk Analysis – A Process Guide For Risk
Practitioners – version 1.2,” May 2007 – Risk Management – AOF,
http://www.aof.mod.uk/aofcontent/tactical/risk/downloads/3pepracgude.pdf
 “How much risk is too much risk?,” Tim Lister, Boston SPIN, January 20th, 2004.
 “Risk Management Maturity Level Development,” INCOSE Risk Management Working
Group, April 2002.
 “A Methodology for Project Risk Analysis using Bayesian Belief Networks within a Monte

Project Risk Management
 “An Industry Standard Risk Analysis Technique,” A Terry Bahill and Eric D. Smith,
Engineering Management Journal, Vol. 21 No 4., December 2009.
 Risk Management Process and Implementation, American Systems Corporation, 2003.
 The Basics of Monte Carlo Simulation: A Tutorial, S. Kandaswamy, Proceedings of the
Project Management Institute Seminars & Symposium, 1–10 November 2001.
 Bayesian Inference for NASA Probabilistic Risk and Reliability Analysis, NASA/SP–2009–
569, June 2009.
 Common Elements of Risk, Christopher J. Alberts, CMU/SEI–2006–TN–014, April 2006.
 “Development of Risk Management Defense Extensions to the PMI Project Management
Body of Knowledge,” Edmund H. Conrow, Acquisition Review Quarterly, Spring 2003.
 Continuous Risk Management Guidebook, Audrey J. Dorofee, Julie A. Walker, Christopher
J. Alberts, Ronald P. Higuera, Richard L. Murphy, and Ray C. Williams, Software
Engineering Institute, 1996.
 Risk Management Guide for DoD Acquisition, Fifth Edition, June 2002.
 Emerging Practice: Joint Cost & Schedule Risk Analysis, Eric Drucker, 2009 St. Louis SCEA
Chapter Fall Symposium, St’ Louis, MO.
 Making Risk Management Tools More Credible: Calibrating the Risk Cube, Richard L.
Coleman, Jessica R. Summerville, and Megan E. Dameron, SCEA 2006, Washington, D.C.,
12 June 2006.
 A Theory of Modeling Correlations for Use in Cost–Risk Analysis, Stephen A. Book, Third
Annual Project Management Conference, NASA, Galveston, TX, 21–22 March 2006.
 The Joint Confidence Level Paradox: A History of Denial, 2009 NASA Cost Symposium, 28
April 2009.
 Identifying and Managing Project Risk: Essential Tools for Failure‒Proofing Your Project,
Third Edition, Tom Kendrick, American Management Association, 2015

Immutable Principles of Project Management (Toronto PMI)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Immutable Principles of Project Management (Toronto PMI)

Similaire à Immutable Principles of Project Management (Toronto PMI) (20)

Plus de Glen Alleman

Plus de Glen Alleman (20)

Dernier

Dernier (20)

Immutable Principles of Project Management (Toronto PMI)