Software development methods are sometimes confused with Project Management principles. There are 5 irreducible principles used to manage projects, no matter the domain or context. We need to assure our development work is guided by these 5 Project Management principles.

1. The 5 Irreducible
ˌir-i-ˈdü-sə-bəl, -ˈdyü-
Principles of Project Management
Needed To
Increase the Probability of Project Success
(PoPS)
Glen B. Alleman
VP, Program, Planning, and Controls
Aerospace and Defense Sector
Lewis & Fowler
Denver, Colorado
Presented
at
Carnegie Mellon Silicon Valley
February 1st and 2nd 2010
1/17
The bent pyramid was changed during construction to adapt to collapses in the foundation
or to speed up the completion. Either way, “adaptive” management was necessary.
Any method for managing projects or developing products or services within those projects
must be adaptive to external and internal changes

2. Today We Will Learn That …
§ Software development
methods are some times
confused with Project
Management principles.
§ There are 5 irreducible
principles used to manage
projects, no matter the
domain or context.
§ We need to assure our
development work is guided
by these 5 Project
Management principles.
We need to remember, Yogi’s advice …
In theory, there is no difference between theory and practice. In
practice there is. 2/17

3. Flying to Mars
on a specific
week, 36
months from
now
Building Internal
Web Site for
our warehouse
The 3 Fundamental Variables of Projects
Cost
Schedule TPM
How can we
determine that the
products we’re
producing meet the
specifications of the
buyer, in what units
of measure?
How can we know
when we will be
finished with the
project, with what
level of
confidence?
Can I know how much this project will cost when
we are done, with what level of confidence?
The Range of Tolerance for Risk and Reward
3/17

4. Why is Software Development Not The
Same as Project Management?
Process Management Acronym Level 2 Level 3 Level 4 Level 5
Organization Process Focus OPF R
Organization Process Definition OPD R
Organization Training OT R
Organization Process Performance OPP R
Organizational Innovation and Deployment OID R
Project Management Level 2 Level 3 Level 4 Level 5
Project Planning PP R
Project Monitoring and Control PMC R
Supplier Agreement Management SAM R
Integrated Project Management IPM R
Risk Management RSKM R
Quantitative Project Management QPM R
Engineering Level 2 Level 3 Level 4 Level 5
Requirements Management RM R
Requirements Development RD R
Technical Solution TS R
Product Integration PI R
Verification VER R
Validation VAL R
Support Level 2 Level 3 Level 4 Level 5
Configuration Management CM R
Process and Product Quality Assurance PPQA R
Measurement and Analysis MA R
Decision Analysis and Resolution DAR R
Causal Analysis and Resolution CAR R
CMMI-DEV 1.2
Separates
“Engineering”
from the
management
of Engineering
for a reason …
“Doing, is not
the same as
management
of the Doing”
4/17

5. 1. Where Are We Going?
2. How Do We Get There?
3. Do We Have Enough
Time, Resources, And
Money To Get There?
4. What Impediments Will
We Encounter Along The
Way?
5. How Do We Know We
Are Making Progress?
IRREDUCIBLE
Of Project Management
Project Success
5/17

6. § Can we tell where we are
going?
§ Do we have a path to get to
done?
§ Do we have everything we
need to get to done?
§ What’s going to stop us from
getting done?
§ How do we know we’re
making progress toward
done?
So What Does All This Have To Do With
Software Development Methods?
§ When we look at any software development method – no matter the method – can we
answer these questions with any level of confidence?
§ If we can’t say this with confidence, then how can we convince those funding our
efforts to be happy with us spending their money? 6/17

7. 1. Where Are We Going?
Eliciting Requirements Is Domain Dependent
“Design and integrate 18 major weapon systems and platforms
simultaneously within strict size and weight limitations, while
synchronizing the 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 the 8 stories for our new
warehouse inventory package tracking
system using the existing web site
platform as a starting point.
7/17

8. 2. How Do We Get There?
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 solution
This approach works
well when we don’t
know what “done”
looks like with enough
clarity
So
Does
This!
8/17

9. 3. Do We Have Enough Time, Money,
And Resources To Get There?
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 the human judgment.
Have the number to back up your intuition.
The Rational Planning of (Software) Projects, Mark C. Paulk, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA
15213–3890
9/17

10. Risk
Management Is
How Adults
Manage
Projects
‒ Tim Lister
4. What Impediments Will We Encounter
Along The Way?
10/17

11. 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
Five Fundamental Principles of Risk Management
11/17

12. 5. How Do We Know If We Are Making
Progress As Planned?
The only measure of progress is the 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 a fit with the agile approaches to
software development.
C
All successful methods measure the evidentiary
outcomes in units meaningful to the stakeholders.
These units are usually “money” and “time.”
D
12/17

13. Project Management Means …
We have a defined mission, vision, capabilities, and
requirements; by which to create,
the Plan for fulfilling these capabilities and
requirements and the Schedule for producing the
needed outcomes to meet this Plan; and have,
allocated enough time, money, and resources to
increase the probability of our project’s success; by
knowing what risks are in front of us and the
retirement and mitigation plan; and we can,
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.
1
2
3
4
5
13/17

14. Applying Project Management to Software
Development Methods
Where Are
We Going?
How Do We
Get There?
Do We Have
Enough Time,
Resources,
And Money
To Get
There?
What
Impediments
Will We
Encounter
Along The
Way?
How Do We
Know We Are
Making
Progress?
Agile Stories Iterations
Fixed
Iterations
Iteration
Planning
Features per
Iteration
IMP/IMS
Concept of
Operations &
Requirements
Integrated
Master Plan
Integrated
Master
Schedule
Formal Risk
Management
Performance
Based
Earned Value
RUP Inception Elaboration Elaboration Construction Construction
Prince 2
Initiating a
Project (IP)
Planning (PL) Managing
Delivery (MP)
Initiating a
Project (IP)
Controlling a
Stage (CS)
§ When we speak of a development method, does it answer the 5 Principle questions?
§ If not, then we’re not “managing” the project.
§ If we’re not “managing” the project, then we’re late and over budget and probably
don’t know it.
14/17

15. The REAL Problem For Every Project Is …
The Activities Are Arranged In A Probabilistic Network With
Interdependent Connections Between Work Elements
§ The solution to this problem starts with clearly defining these dependencies using the 5 principles.
§ If we have no visibility into these dependencies, “done” is no loner visible.
§ If this is acceptable the customer, we can proceed.
§ If not, we need a baseline plan showing Done 15/17

16. A Few More Principles to Live By
§ Late Starts = Late Finishes
ü The key to success is starting all work on time
§ Without schedule margin we’re late on day one
ü All duration estimates are random variables
§ Without budget margin we’re over budget on day one
ü All cost estimates are random variables
§ Only speak about our project in units of measure
meaningful to the customer
ü This almost always means monetized beneficial outcomes
§ Never confuse effort with results
ü The customer paid for an outcome, not our effort to
produce it
16/17

17. Deliverables Based Planning Handbook for A&D, Copyright © 2008, 2009, Lewis & Fowler
Did We Learn Anything Useful?
17/17
Now matter our tolerance for risk, the
methods we use – the 5 immutable
principles are always in place