1
Dec 21, 2015
There are three outcomes for this talk.
1. I’m going the suggest there is common
misunderstanding that software
development and project
management are the same thing.
2. There are 5 irreducible principles for
managing any project, no matter the
domain or the context.
3. And, as software developers, along
with the project manager, if you are
not answering the questions from
these irreducible principles, you’re
probably doing project management
and your project is in jeopardy and
you may not know it.
The 5 Immutable Principles of Project Management 2/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
We’ve all seen the numbers.
We’ve all been told how bad things are.
77% of project failures are due to poor
planning or poor project management.
Here’s one more look.
But we’re here to work on only one of the
aspects of the “money flushing” part of
your project activity
We’re here today to talk about the
project management aspects of projects.
The planning, scheduling, costing,
management verbs of projects.
These are called the Programmatic
Elements of the project. Versus the
technological aspects.
As a program manager I’m very
interested in the technology. But my job is
to make sure the programmatic aspects
work, so the technology has a chance of
actually showing up on time.
The 5 Immutable Principles of Project Management 3/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
So first let’s review what is a project.
It’s a one off event. It’s not operations. It’s
not repeatable processes – although the
processes that manage projects are
repeatable, the project itself is a one
time occurrence.
The reason this is important is that
projects are a “one chance to get it right”
type of endeavor. Operations has
several chances to get it right. Maybe a
lot of chances. Sometimes only a few. But
never just one.
Now there is another word here –
probability.
Projects have a probability of success.
There is no guarantee. We’d like this
probability to be as high as possible. For
some projects the probability is high –
close to 100%. For some projects the
probability, while acceptable, is actually
low.
There is 1 chance in 149 of losing the
mission for the Orion Manned Spaceflight
program with specific types of launch
vehicles.
What’s the probability of having your
Enterprise ERP project rollout fail in a
way that causes an unrecoverable loss to
your company? Good question.
How can you improve the probability of
success for your project? Another good
question.
The 5 Immutable Principles of Project Management 4/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Mr. Blaise’s quote is applicable to almost
every major project we’ve encountered.
It’s sad but true that we simply don’t
know how to stop work once we’ve
started.
The work shop today is not about that
decision though.
It’s about applying the principles of
project management, so we don’t have to
treat projects in such a “black and white”
manner.
The 5 Immutable Principles of Project Management 5/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
No matter what type of project you work,
no matter what the domain, no matter
what project management method you
use, you must be capable of managing
the work in the presence of change.
It is not possible to manage change, you
must manage in the presence of change.
Change is everywhere, it is constant, and
it is simply part of the environment of
project work.
The Five Immutable Principles we’ll speak
to today will provide you with the tools to
manage in the presence of change.
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
6/58
Management is a verb.
When applied to an object, like a
project, this verb is the actions needed to
control and guide the development of the
outcomes of the project.
No matter what your approach, self
guided or all the way to formal project
management methods, projects need a
framework in which to make progress.
The definitions here define the
boundaries of the processes applied to
the project.
The 5 Immutable Principles of Project Management 7/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
When we put these terms together we
arrive at the basis of today's work shop.
We need knowledge, skills, tools, and
techniques in order to increase our
Probability of Project Success (PoPS).
The five (5) immutable project
management principles are independent
of all these things.
At the same time they apply to any and
all these things.
And finally they are independent of any
project domain and any context in that
domain.
With the concept of Project +
Management in hand, let’s look at the
domain and context in those domains for
applying this verb and noun.
The 5 Immutable Principles of Project Management 8/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
When we hear about principles we think
about the foundation of a principles.
There are the principles of playing
baseball. Or the principles of planting a
garden.
These are the guidelines by which the
practice can be successful.
But principles must be put into practice
and have some hope of being successful.
The principles must be based on practices
that have been shown to actually work in
the domain you are trying to apply them
to.
I’m going to try and convince you today
that these 5 Immutable Principles can be
applied in all domains, where projects
are the means of producing results.
9 The 5 Immutable Principles of Project Management
Here’s an idea that we don’t always
consider upfront when we look for
processes and principles.
The amount of risk a project can tolerate
is directly related to the business domain
and the context of the project within that
domain.
Understanding the tolerance for these risk
levels are critical to choosing and
applying any software development
method.
However, the five immutable principles
presented here are juts that, immutable.
They must be present in some form no
matter the product development method,
the level of risk tolerance of the domain
and the context within that domain.
The risk tolerance for cost is defined as
the ability for the customer to absorb
changes in the planned cost through
management reserve and the application
of additional funds.
The risk tolerance for schedule slippage is
defined as the ability to still produce
value for the customer in the presence of
a late or slipping schedule.
The risk tolerance for Technical
Performance means the customer is willing
to accept technical capabilities that are
less than planned.
With this background, let’s look at the
five (5) immutable principles.
The 5 Immutable Principles of Project Management 10/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
The notion of simplicity has entered the
discussion around project management
methods, tools, processes, and other
elements.
On one end we have Leonardo’s quote
about simplicity being the ultimate
sophistication.
On the other we have Mencken’s
reminder that complex problems and
their solutions are connected in ways we
may not actually understand.
Searching for simplicity in the absence of
understanding the “system” usually leads
to disappointment.
When we’re walking through our
immutable principles today, let’s keep in
mind the connection between simplicity
and complexity and the solutions we
need to address this complexity.
The 5 Immutable Principles of Project Management 11/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
The five immutable principles of project
management are:
1. Know where you are going by
defining “done” at some point in the
future. This point may be far in the
future – months or years from now. Or
closer in the future days or weeks from
now.
2. Have some kind of plan to get to
where you are going. This plan can be
simple or it can be complex. The
fidelity of the plan depends on the
tolerance for risk by the users of the
plan.
3. Understand the resources needed to
execute the plan. How much time and
money is needed to reach the
destination. This can be fixed or it can
be variable.
4. Identify the impediments to progress
along the way to the destination.
Have some means of removing,
avoiding, or ignoring these
impediments.
5. Have some way to measure your
planned progress, not just your
progress. Progress to Plan must be
measured in units of physical percent
complete.
The 5 Immutable Principles of Project Management 12/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Our first step here is to separate a Plan
from a Schedule.
The PLAN is a procedure used to achieve
an objective. It is a set of intended
actions, through which one expects to
achieve a goal.
The SCHEDULE is the sequence of these
intended actions, needed to implement
the PLAN.
But we don’t what to mix the PLAN with
the SCHEDULE.
The PLAN is the strategy for the successful
completion of the project.
In the strategic planning domain, a PLAN
is a hypothesis that needs to be tested
along the way to confirm we’re headed.
The SCHEDULE is the order of the work to
execute the PLAN.
We need both. PLANS without
SCHEDULES are not executable.
SCHEDULES without PLANS have no
stated mission, vision, or description of
success other than the execution of the
work.
The 5 Immutable Principles of Project Management 13/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
When we say “where are we going,” we
should be talking about physical
outcomes – the deliverables.
When we say deliverables, what
deliverables are we talking about?
The deliverables should be those that
fulfill the requirements.
So what are the requirements?
As our quote says here, the single hardest
part of building a system is deciding
what to build.
No matter what method you use to make
these decisions – from the agilest of
methods to the most formal, we need to
have the requirements stated in a form
that is testable, verifiable, and traceable
to the PLAN and SCHEDULE.
The 5 Immutable Principles of Project Management 14/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Here’s some words that we’ll encounter
during the development of requirements.
These are not the only words of course,
but these words are important ones.
One critical set of words are “Stated”
versus “Real.” Stated requirements are
any requirement that is written down –
that is stated. “Real” requirements are of
course requirements that are really
needed by the system to fulfill its business
case.
Other words are important as well.
“Verified” and “Validated” are a pair.
One of the requirements words that
causes much extra work is “derived.” A
derived requirement is one that is not
primary, but is secondary. As such it may
not be obvious that it is a requirement.
There are requirements words that should
be avoided. The first one – that may not
be obvious – is “Customer.” Which
customer? How do we know what the
customer wants? One simple way out of
this is to state the requirement, that we
think is a customer requirement, in terms
of a business requirement. Complete with
a business reason, business case, business
payback, other business reasons.
Of course there are phrases that should
be avoided as well. “User Friendly” has
started to be purged from the
vocabulary – at long last. But “flexible”
and “reliable” are still hanging around.
The 5 Immutable Principles of Project Management 15/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
The key here is that requirements tell us something about where we are going.
But requirements come in all shapes and sizes.
Here’s a sample of two extremes.
A small project and a not-small project.
The small project is straight forward in terms of requirements. There is a list of them on the flip chart. They are likely well understood. They probably can be estimated in terms of cost and schedule. And most importantly the interactions between the requirements can be intuited with a little effort.
The project on the right is a different class of effort. This is the top level components (if you can call them that) of the Future Combat System. It’s a $35B, that’s billion with a B program to restructure the entire US Army Battle Space Management processes.
I help one of the teams – the Class I team – build their Performance Measurement Baseline and get that information into a cost and schedule management system, so they can use Earned Value Management to “manage” their program.
FCS is a software intensive system, where software is in everything from small hand held devices to major facilities housing the “battle space management command.”
If the software doesn’t work, the FCS doesn’t work. Soldiers can’t do their job. If soldiers can’t do their job – there’s a BIG PROBLEM.
The 5 Immutable Principles of Project Management 16/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
For the moment, let’s use a simpler
analogy to connect with something more
tangible.
Let’s pretend we want to go on a hike. A
nice hike to the saddle just to the right of
the peak above this lake. That saddle is
Pawnee Pass. It’s just west of Boulder
Colorado, and a bit south of Rocky
Mountain National Park.
We’d like to go to Pawnee Pass in a
single day – there and back. Not get too
wet if it rains. Not be too hungry. And
have a good time along the way with our
hiking group.
That’s our mission.
The 5 Immutable Principles of Project Management 17/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
These two words should be tattooed on
your wrist.
If we don’t have a Plan, our schedule is
not credible. Plans are not Schedules.
And Schedules are not Plans.
A Plan is the Strategy for the successful
delivery of the project. Plans state “what”
is to be done (programmatically what,
not technically what). Schedules state
“how” it is to be done –
programmatically how it is to be done.
While this may seem subtle or maybe not
even useful, it is critically important for
several reasons:
The plan shows how the project
produces increasing value and
increasing maturity of the products.
It’s is the “road map” from the
beginning to end, INDEPENDENT from
the actual durations of the work.
The Plan speaks to What we are
doing.
The schedule is the “driving instructions”
for the vehicles on the roads, following
the map.
The execution of the schedule is the
actual “driving” of the vehicle by the
driver along with the passengers.
All three are needed, no one can be
missing, all three interact with each other.
The 5 Immutable Principles of Project Management 18/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Plans are strategies. They tell us the flow of
the project in terms of deliverables and the
increasing value and maturity of those
deliverables. I’m going to introduce some new
words here that we’ll use later. They are just
words for now, so their exact meaning is not
important.
This is similar to the Value Stream Map found
in Lean Six Sigma.
The “map” is the flow of the Significant
Accomplishments in the project or program.
For these Accomplishments, there are a set of
Criteria that define the “exit conditions” for
the underlying work. Defining these criteria
BEFORE defining the details of the work is the
basis of the Planning process.
This is a top down-first approach . It is NOT a
Top Down only approach, just the 1st step in
the process. But with the Accomplishments and
the Criteria defined, there is a notional view
of what “done” looks like. Measureable in
some units meaningful to the project
management team and the stakeholders in
the project.
This focus on the definition of “done” is
important for several reasons:
1. “Done” is a measure of 100% done, not
partially done, not almost done. But
DONE. This is the concept of “starting
with the end in mind,” popularized by
Covey.
2. Along the way to DONE, there are
measures of “getting to done” that are
“mini-dones.” These “maturity assessment
points” are the way to measure physical
percent complete in terms of the product
maturity rather than the consumption of
resources or passage of time.
The 5 Immutable Principles of Project Management 19/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Now that we know about the existence of
a Plan, what is the Schedule? Why is it
different from a Plan?
The Schedule shows the work needed to
produce the “deliverables” in the Plan.
This sounds like a tautology – a statement
of the obvious.
But there’s more to it than that.
This work is ONLY the work needed to
cause the “exit criteria” to appear of
each individual definition of the criteria
for named Accomplishment.
In a previous slide we mentioned the
definition of the Accomplishments come
first. With these definitions – and most
importantly the order in which these
Accomplishments must be accomplished
I know this is not as clear as you’d expect
at this point.
But we’ll need to use an example before
we get back to the details.
For now think of the schedule as the
description of how the individual Exit
Criteria from the “lumps of work” are to
be accomplished.
The 5 Immutable Principles of Project Management 20/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Now that we know where we want to go, the next question is how to get there.
How do we build the products or provide the services needed to reach the end of our project.
There are numerous choices, depending on the domain and the context of the project in that domain.
For the software domain there are many context’s. Using the example on the previous page, let’s look at two methods. These are the extreme ends of the spectrum of contexts and methods. They can serve to focus the discussion on project management rather than product development methods, by hopefully disconnecting project management from product development so we can look at them separately.
In the first software development context – a list of features, SCRUM is a popular approach.
But there are many more software based project, possibly more complex than the example from the previous page to the “wickedly” complex program also shown on the previous page.
The SCRUM method is shown in its common diagram. But below it is the method used for product procurement in the US Department of Defense – DoD 5000.02. The products are not actually developed by the DoD (except in rare cases). But are instead, procured. So acquisition management is guided by this process.
Both are iterative, both are incremental, both can deal with emerging requirements, both make use of “test driven planning,” and both have clear and concise measures of physical percent complete.
The 5 Immutable Principles of Project Management 21/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Now that we know some things about
what capabilities we need and how we
might cause these capabilities to appear
at the appointed time and place for the
planned cost and schedule, do we know
what we need to be successful?
We need to constantly ask this question.
If we don’t ask and answer the question,
we’ll find out what is missing when they
arrive on our doorstep.
At that point it will be too late. It is not
too late to acquire them, but too late to
acquire them within our planned schedule
and planned budget.
The 5 Immutable Principles of Project Management 22/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Now that we know where we’re going
and how to get there – do we have all
we need to reach the end?
Staff, time, money, the necessary skill and
experience and the proper management
support.
These are all obvious on any project – at
least any well managed project.
But there are always underlying issues
with answering these questions.
The first is that management as well as
the development organization are
always optimistic about the outcome. This
is the very nature of project
management. Why be pessimistic?
Well maybe not pessimistic, but how
about realistic? What do we mean when
we say realistic? One good word is
credible. Credible could be optimistically
credible or pessimistically credible. But
either way we have a credible
understanding of what it takes to reach
the end.
One part of credible is knowing what the
risks and uncertainties are and how we
are going to dealing with them.
Managing in the Presence of these
uncertainties is critical to reaching our
goal. Risk and uncertainty never go
away. They are always there. They are
unavoidable.
The 5 Immutable Principles of Project Management 23/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Once we recognize that time is not money
and money is not time, the next eye
opener for all project work is there is a
natural statistical variability of both these
elements.
So no matter what software development
method you are applying inside a project
management set of processes, you must
come to grips with the statistical nature of
cost, schedule, and technical
performance.
This area is called Programmatic Risk and
its cousin Technical Risk.
The Programmatic Risk concept is not well
understood outside the defense and
space business. There it is mandated that
Programmatic Risk be managed – DID
81650 describes this mandate.
The Monte Carlo simulation method is the
way to assess the behavior of the
network of activities, but there subtleties
beyond just the simulation of the network.
The Monte Carlo tools don’t easily model
the coupling and correlations between
the work activities in a proactive manner.
There are other tools for modeling the
network, but they are also outside this
presentation.
The 5 Immutable Principles of Project Management 24/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Project Managers constantly seek ways to eliminate or control risk, variance, and uncertainty. This is a hopeless pursuit.
Managing “in the presence” of risk, variance and uncertainty is the key to success. Some projects have few uncertainties –only the complexity of tasks and relationships is important – but most projects are characterized by several types of uncertainty.
Although each uncertainty type is distinct, a single project may encounter some combination of four types:
1. Variation – comes from many small influences and yields a range of values on a particular activity. Attempting to control these variances outside their natural boundaries is a waste (Muda).
2. Foreseen Uncertainty – are uncertainties identifiable and understood influences that the team cannot be sure will occur. There needs to be a mitigation plan for these foreseen uncertainties.
3. Unforeseen Uncertainty – is uncertainty that can’t be identified during project planning. When these occur, a new plan is needed.
4. Chaos – appears in the presence of “unknown unknowns.”
“Managing Project Uncertainty: From Variation to Chaos,” Arnoud De Meyer, Christoph H. Loch and Michael T. Pich, MIT Sloan Management Review, Winter 2000.
The 5 Immutable Principles of Project Management 25/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Project duration and costs are random
variables drawn from some underlying
probability distribution.
In probability theory, every random
variable is attributed to a probability
distribution.
The probability distribution associated
with a cost or duration describes the
variance of these random variables.
A common distribution of probabilistic
estimates for cost and schedule random
variables is the Triangle Distribution.
Using the Triangle Distribution for the
costs and durations, a Monte Carlo
simulation of the network of activities and
their costs can be performed.
Monte Carlo methods are used to numerically transform and integrate the posterior quantitative risk assessment into a confidence interval.
The result is a “confidence” model for the
cost and completion times for the project
based on the upper and lower bounds of
each distribution assigned to each
duration and cost.
The 5 Immutable Principles of Project Management 26/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
If risk management is how adults manage projects, here are some principles of project risk management.
These five principles are simple, obvious, but difficult to implement. This reason they’re difficult is that most people shy away from risk. Managing in the presence of risk does not come naturally.
It is a learned behavior. And once learned it has to be practiced. But before it can be learned and then practiced, “managing in the presence of risk,” must become part of the business culture.
Some cultures doe this better than others. NASA is probably better than others. But even NASA has moved a risk adverse culture in the past decades.
1. Hoping that something positive will result is not a very good strategy. Preparing for success is the basis of success.
2. Single point estimates are no better than 50/50 guesses in the absence of knowledge of the standard deviation of the underlying distribution.
3. Without connecting cost, schedule, and technical performance of the effort to produce the product or service, the connection to value cannot be made.
4. Risk management is not an ad hoc process that you can make up as you go. A formal foundation for risk management is needed.
5. Identifying risks without communicating them is a waste of time.
The 5 Immutable Principles of Project Management 27/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Project Managers constantly seek ways to eliminate or control risk, variance and uncertainly. This is a hopeless pursuit.
Managing “in the presence” of risk, variance and uncertainty is the key to success. Some projects have few uncertainties –only the complexity of tasks and relationships is important – but most projects are characterized by several types of uncertainty. Although each uncertainty type is distinct, a single project may encounter some combination of four types:
1. Variation – comes from many small influences and yields a range of values on a particular activity. Attempting to control these variances outside their natural boundaries is a waste (Muda).
2. Foreseen Uncertainty – are uncertainties identifiable and understood influences that the team cannot be sure will occur. There needs to be a mitigation plan for these foreseen uncertainties.
3. Unforeseen Uncertainty – is uncertainty that can’t be identified during project planning. When these occur, a new plan is needed.
4. Chaos – appears in the presence of “unknown unknowns.”
“Managing Project Uncertainty: From Variation to Chaos,” Arnoud De Meyer, Christoph H. Loch and Michael T. Pich, MIT Sloan Management Review, Winter 2000.
The 5 Immutable Principles of Project Management 28/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
The use of point estimates for durations
and costs is many times the first impulse in
an organization low on the project
management maturity scale.
Understanding cost and durations are
actually “random variables,” drawn from
an underlying distribution of possible
value is the starting point for managing in
the presence of uncertainty.
The Triangle Distribution is used as a
subjective description of a population for
which there is only limited sample data,
and especially where the relationship
between variables is known but data is
scarce. It is based on the knowledge of
the minimum and maximum and a “best
guess” of the modal value (the Most
Likely).
Using the Triangle Distribution for the
costs and durations, a Monte Carlo
simulation of the network of activities and
their costs can be performed. Monte
Carlo methods are used to numerically
transform and integrate the posterior
quantitative risk assessment into a
confidence interval. The result is a
“confidence” model for the cost and
completion times for the project based on
the upper and lower bounds of each
distribution assigned to each duration
and cost.
This approach to estimating provides
insight into the behavior of the plan as
well as sensitivity between the individual
elements of the plan.
The 5 Immutable Principles of Project Management 29/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
In many descriptions of project
management – cost, schedule, and quality
are considered as the “Iron Triangle.”
Change one and the other two must
change as well. It turns out this is too
narrow a view of what's happening on a
project.
It’s the Technical Performance
Measurement that replaces Quality.
Quality is one of the Technical
Performance measures.
Technical Performance Measures describe
the status of technical achievement of the
project at any point in time.
The Planned technical achievement is part
of the Performance Measurement
Baseline (PMB) in the same way the
Planned Value (BCWS) is part of the
PMB.
The TPMs use the techniques of risk
analysis and probability to give program
managers the early warning needed to
avoid unplanned costs and slippage in
schedule. Systems engineering uses
technical performance measurements to
balance cost, schedule, and performance
throughout the life cycle.
TPMs compare actual versus planned
technical development and design. They
also report the degree to which system
requirements are met in terms of
performance, cost, schedule, and
progress in implementing risk handling.
The 5 Immutable Principles of Project Management 30/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Risk Management means using a proven
risk management process, adapting this
to the project environment, and using this
process for everyday decision making.
Technical performance is a concept
absent from the traditional approaches
to risk management. Yet it is the primary
driver of risk in many technology
intensive projects.
Cost growth and schedule slippage often
occur when unrealistically high levels of
performance are required and little
flexibility is provided to degrade
performance during the course of the
program. Quality is often a cause rather
than an impact to the program and can
generally be broken down into Cost,
Performance, and Schedule components.
The framework shown here provides:
Risk management policy.
Risk management structure.
Risk Management Process Model.
Organizational and behavioral
considerations for implementing risk
management.
The performance dimension of
consequence of occurrence.
The performance dimension of Monte
Carlo simulation modeling.
A structured approach for developing
a risk handling strategy.
The 5 Immutable Principles of Project Management 31/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
It does no good to manage risks if the
results are not communicated to all the
participants.
Risk communication is the basis of risk
mitigation.
This plan needs to address the following:
Executive summary – a simple summary
of the program and the risks
associated with the activities of the
program. Each risk needs an ordinal
rank, a planned mitigation if the risk is
active (a risk approved by the Risk
Board), and the mitigations shown in
the schedule with associated costs.
Program description – a detailed
description of the program and the risk
associated with each of the
deliverables. This description should be
“operational” in nature, with the
consequences description in
“operational” terms as well.
Risk reduction activities by phase –
using some formal risk management
process that connects risk, mitigation
and the Master Schedule. The efforts
for mitigation need to be in the
schedule.
Risk management methodology – using
the DoD Risk Management process is a
good start. This approach has proven
and approved by high risk, high
reward programs. The steps in the
processes are not optional and should
be executed for ALL risk processes.
The 5 Immutable Principles of Project Management 32/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Risk Management is a full time effort.
Even if it is a part-time job.
Someone needs to “own” the risks and the
process around risk management.
Someone or a collection of “someone's”
needs to have risk management in their
mind(s) at all times.
Risk Management is not something you
can do once and them forget. The risks
don’t just go away.
They are forever there, even if they are
mitigated, retired or bought down.
The 5 Immutable Principles of Project Management 33/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
When we ignore the fundamental
statistical nature of project work, we are
creating risk.
This risk comes not from the underlying
probabilities, but from our ignorance of
this process.
We believe, wrongly, that our estimates
are static point values – a single number
representing the estimate. We fail to
take into account the statistical processes
that drive this number.
Durations, costs, technical performance.
When we fail to make these variances
visible we are managing our project with
a “head in the sand,” just like this guy.
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
34/58 The 5 Immutable Principles of Project Management
Many speak about risk management as
part of the project management process.
But do they do risk management as part
of the project management process?
Test yourself and anyone who claims to
be doing risk management
The 5 Immutable Principles of Project Management 35/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Measures of progress are one of the
difficult topics in project management.
Typically we measure progress by the
consumption of resources and the
passage of time.
We talk about “budget,” being “on
budget,” being “over budget.”
We talk about the passage of time.
“We’re on schedule,” “we’re late,” “our
schedule is slipping.”
These are all necessary things to talk
about. But they are not sufficient for our
project’s success.
The 5 Immutable Principles of Project Management 36/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Performance measurement is the
comparison of actual performance
against an integrated baseline plan
consisting of integrated cost, schedule
and technical goals. The baseline used
for performance measurement should be
a single, integrated plan, because the
analysis of cost performance must include
schedule considerations and the
evaluation of schedule performance must
include technical performance
considerations.
Given a project where some tasks are on
schedule, some are ahead of schedule
and some are behind schedule, overall
project status is virtually impossible to
determine. It is no wonder that many
project managers are literally “flying by
the seat of their pants” without a good
feel for where the project stands at any
given point in time.
A systematic, organized process for
collecting performance information and
presenting it in a clear manner on a
regular basis is essential to the project
management process.
The 5 Immutable Principles of Project Management 37/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
With the information from the previous 4 irreducible principles, we now need to confirm we are making progress. The key principle here is “planned progress.” We must pre-define what progress we must make at any specific point in the project, otherwise all we can determine is the passage of time and the consumption of money. Preplanning the progress is the basis of “performance based” measurement for both project processes and technical products.
Like Kent Beck’s (eXtreme Programming) advice we need feedback on our progress.
There is only one kind of feedback for projects – measures of physical percent complete.
No soft touchy feely measures of progress. No hand waving measures. Physical, tangible evidence of progress.
Something that can be physically shown to the customer. Something that is compliant with the planned technical outcomes at this point in the plan.
Scrum does this by predefining the outcomes of the iteration. DoD 5000.02 does this as well with the Integrated Master Plan and Integrated Master Schedule.
So looking at two extremes of the spectrum – one a software development method and the other a mega-program procurement method. Both share the same principles and outcomes. Something that is tangible and measurable at incremental steps along the way to “done.”
The 5 Immutable Principles of Project Management 38/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
For successful measurement of progress in
a project we need to have:
Tangible evidentiary materials
measure progress to plan.
Pre–defined existence of this evidence
in meaningful units of measure
established before starting work.
Progress is defined in these same units
of measure.
The 5 Immutable Principles of Project Management 39/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
There are many opinions about
measuring progress to plan.
Here’s what some authors have said.
Notice that all speak in terms of tangible
outcomes.
This tangible evidentiary materials concept
is the basis of all credible forms of
measurement.
The 5 Immutable Principles of Project Management 40/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Let’s talk a bit about a common fallacy in
the project management world.
The notion of the “iron triangle” has fallen
into disrepute lately.
We all should know about the iron
triangle. It connects cost, schedule, and
quality – or some 3rd element in place of
quality.
Actually the variable in place of quality
is “Technical Performance Measures”
(TPM).
The 5 Immutable Principles of Project Management 41/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Technical Performance Measurement (TPM) is a technique for predicting the future value of a key technical performance parameter of the higher-level product based on current assessments of products lower in the system structure.
Continuous verification of actual versus anticipated achievement of technical parameters confirms progress and identifies variances that might jeopardize meeting a higher-level end product requirement.
Assessed values falling outside established tolerances indicate the need for management attention and corrective action. A well thought out TPM program provides early warning of technical problems, supports assessments of the extent to which operational requirements will be met.
When we say “project management” we
have to say “management” in terms of
measuring progress to plan.
The question is how to measure progress
to plan?
How do we define what the planned
progress “should” be, what actual
progress we made to date, and how
much work there is to go?
With the remaining progress to go, what
should or pace be to arrive at the end of
the project at the planned time?
The 5 Immutable Principles of Project Management 42/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Pulling essential cost, schedule and
technical performance information
together in a meaningful, coherent
fashion is always a challenge facing the
project manager.
If this cannot be done, management
information will be fragmented, will not
contribute effectively to project
management, and may actually mislead
the manager by presenting a distorted
view of project status.
Performance measurement is the
comparison of actual performance
against an integrated baseline plan
consisting of integrated cost, schedule
and technical goals.
The baseline used for performance
measurement should be a single,
integrated plan because the analysis of
cost performance must include schedule
considerations and the evaluation of
schedule performance must include
technical performance considerations.
Performance measurement is the art of
determining, organizing, and presenting
cost, schedule and technical performance
information in a way that contributes to
making those tradeoffs. It is a systematic,
organized process for collecting
performance information and presenting
it in a clear manner on a regular basis.
The 5 Immutable Principles of Project Management 43/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
We hopefully have all heard the term
“earned value,” and maybe even seen
the term in use.
Here is the cheat sheet for the Earned
Value variables and the formulas used to
calculate the indices needed to manage
a project using Earned Value.
We won’t get into the details of EV. But
EV is one of the best measures of project
performance available.
Is straight forward to apply. Provides
credible forecasts of future performance
and has natural connections to Scrum and
some other agile software development
methods.
The 5 Immutable Principles of Project Management 44/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
The use of Earned Value, Earned Value
Management, with an Earned Value
Management System connects cost and
schedule into a performance
measurement system.
The cost and schedule performance
indices are used to forecast future
program performance in the presence of
unchanged technical performance.
By using Earned Value in conjunction with
probabilistic risk analysis of cost,
schedule, and technical performance
measures, a forecast of future cost and
schedule impacts can be made.
The primary motivation for earned value
is to stimulate action on the part of the
project or program manager to make
changes that will alter the course of
performance and bring the project or
program into conformance with the value
proposition as defined in the charter.
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
45/58 The 5 Immutable Principles of Project Management
There are some other motivations as well:
Earned Value tools help the project
manager measure and assess the
accumulation of value throughout the
project implementation.
The purpose of earned value is to give
the project manager information
sufficiently early so poor performance
can be corrected before it impacts the
value performance of the project.
Cost centric earned value systems are
robust measures of project
performance in the measurement
system are in place to provide the
necessary data for analysis.
Time centric earned value systems are
a substitute for cost centric systems
when the cost collection measures are
not available.
Managing Projects for Value, John
Goodpasture, Management Concepts,
2002.
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
46/58 The 5 Immutable Principles of Project Management
Performance measurement is the
comparison of actual performance
against an integrated baseline plan
consisting of integrated cost, schedule
and technical goals. The baseline used
for performance measurement should be
a single, integrated plan, because the
analysis of cost performance must include
schedule considerations and the
evaluation of schedule performance must
include technical performance
considerations.
Given a project where some tasks are on
schedule, some are ahead of schedule
and some are behind schedule, overall
project status is virtually impossible to
determine. It is no wonder that many
project managers are literally “flying by
the seat of their pants” without a good
feel for where the project stands at any
given point in time.
A systematic, organized process for
collecting performance information and
presenting it in a clear manner on a
regular basis is essential to the project
management process.
The 5 Immutable Principles of Project Management 47/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
If we’re going to be successful measuring
performance of the project, we must have
tangible measures of progress.
These means the evidence must be
defined upfront, so we can recognize it
when it arrives.
If we don’t define the evidence up front,
then we fall victim to the “emergent”
measure of progress.
Or worse, progress is what we have done
this week.
The units of measure of progress must be
meaningful to the project participants.
Numbers and statement of progress are
of no value if we can’t make decisions
with this information.
The 5 Immutable Principles of Project Management 48/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
When we use traditional forecasting
based on cost and schedule adherence,
we ignore the “technical performance” of
the product we’re building.
We’re on schedule, we’re on budget, the
thing we’re building doesn’t work exactly
as we had planned.
So how can we be on-schedule and on-
budget?
We can’t.
We’re driving in the rearview mirror.
This can be done, but you usually run
over something stinky.
The 5 Immutable Principles of Project Management 49/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
We need a way for forecasting the
future performance of the project, from
it’s past performance. The risk adjusted
past performance.
We need to drive the car by looking out
the front windshield.
Or in this case the windshield of the
Shuttle.
The 5 Immutable Principles of Project Management 50/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Project management means being able to
state with confidence these any time
someone asks you “how are you
managing the project?”
If you cannot say this with a straight face,
then you need to take action to start to
move in that direction.
The 5 Immutable Principles of Project Management 51/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Since we visited the principles and done
some sample exercises with the principles
to get a feel of how they could be
applied.
Now we need to connect these principles
with the practices.
Here’s some examples how to make these
connections.
1. The statement of where we are going
doesn’t have to be complex. But it
must address the details appropriate
for the problem.
2. A Master Plan and Master Schedule
show “how” we’re going to get there
on-time, on-budget, and on-
specification.
3. These Plans and Schedules, have all
the needed resources defined and
loaded into the Work Packages.
4. With this Plan and Schedule, we can
now define the risks and their
mitigations or retirement plans.
5. Finally we’ll ALWAYS measure
progress as physical percent
complete.
There, now we’ve connected principles
with practice.
The 5 Immutable Principles of Project Management 52/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
There are also a few “laws of physics”
for projects. The first is late starts mean
late finishes. If you start late you’ll likely
finish late if you don’t have schedule
margin. How much schedule margin is
needed? Good question. There are ways
to find out. Some fancy some simple. But
for sure if you have no margin and you
start late you're late.
Same goes for budget.
While we said before we need to
measure progress as physical percent
complete, the units of measure must be
meaningful to the stakeholders. As an
undergraduate physics major we used to
play a joke on our TA – which I got back
in spades a few later when I was a TA.
The joke in classical mechanics is to do all
the calculations in the right units of
measure – Standard International (SI)
units. Then convert those to olde English
measures. Volume in cubic meters can be
converted to Hogs Heads. Or kilometers
per hour to furlongs per fortnight.
So we need to consider what the
stakeholders really want to know. This
turns into a metrics problem and is
outside the scope of this brief talk, but it
must be addressed if you’re really
managing the project. But as the bullet
says – time and money – are good
starting points.
Finally a universally applicable principle
is to never confuse effort with results. The
customer paid for results.
The 5 Immutable Principles of Project Management 53/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
So now we can understand that we need
all three measures
Cost, schedule, and technical
performance to establish the basis of
credibility.
Each measure must be statistically
adjusted for its particular probability
distribution.
Each measure must have a model of how
it interacts with all the other measures.
Each measure must describe the work
processes that are used to increase the
maturity and therefore the probability of
program success.
A simple static model the program is not
credible. A dynamic model is the
beginning of this credibility.
The 5 Immutable Principles of Project Management 54/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
So what happens if we don’t get all these
principles put into practice.
We tried really hard, but didn’t make it.
What happens is you reduce the
Probability of Project Success (PoPS).
How much, depends on the project.
What are the impacts, depends on the
project.
But why do it.
Why not make every attempt to do it
right?
The 5 Immutable Principles of Project Management 55/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Now for questions.
The 5 Immutable Principles of Project Management 56/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
So we’ve arrived at the end of our short
time here. What did we learn?
There are 5 immutable principles of
project management, no matter the
project domain and context.
We need to confirm are project is
applying these principles, and look for
the evidence in the form of practices for
each principle.
Hopefully I’ve conveyed the notion that
project management is not the same as
product development.
Both are needed, some times more than
the other depending on the context and
the domain.
If I’m building a web site I approach the
project management and development
method differently than if I’m building the
terminal guidance control software for an
autonomous Mars Lander
The 5 Immutable Principles of Project Management 57/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved
Here’s my contact information.
If you have questions that weren’t
answered here, would like a soft copy of
this briefing or any others from today or
last night’s PMI Chapter meeting, please
drop me a note.
The 5 Immutable Principles of Project Management 58/58
Copyright ® 2012, Glen B. Alleman, All Rights Reserved