Immutable principles of project management (fw pmi)(v4)

Copyright ® 2010, Lewis & Fowler, All Rights Reserved

I’d like to thank you for inviting me to
speak at your workshop.
My contribution to this topic is from the
point of view of a program controls
manager in the aerospace and defense
business.
The programs we work are software
intensive, but not in the way commercial
software projects are.
The software on our programs is
embedded in other systems – avionics,
flight controls, ground management
systems of aircraft and spacecraft.
Other parts of our firm work programs
for commercial enterprise IT.
The principles I’m going to introduce you
to today are applicable to all projects no
matter the domain or the context in that
domain.
From software, COTS IT, construction, any
project where the outcome is critical to
the success of the participants.

The 5 Immutable Principles of Project Management 1/62


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.



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.



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.



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.



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.



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



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



When we confuse product development
with project management, we’ve missed
answering the 5 immutable principles
questions.
We skipped directly to the “doing” part
of the project.
The “managing of the doing” is not the
same as the “doing.”
Both are needed of course.
If we only have the “doing” part, then the
project is guided by the immediate
outcomes of the development process.
The project outcomes “emerge” as it
progresses. This is the basis of some forms
of Agile. There may be broader goals,
but the development team only responds
to the “next” increment.
Many projects are successful applying
this product development method as a
replacement for project management.
The other approach – and this is a
context sensitive approach – is to define
the needed capabilities, the requirements
needed to fulfill those capabilities, and
the work plan to make those requirements
appear.
This does not mean the fidelity of the
requirements is complete. Some could be
vague, some could be altered as we
proceed. But the end-to-end goal is
defined with enough fidelity to assure the
customer we understand what DONE
looks like.

11


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.



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.



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



Let’s start our exercise with a topic that
should be familiar to you – flying to the
moon.
We flown to the moon and returned
safely before.
It can’t be that hard.
Yea right.
We’ll use the current moon mission as a
framework to ask and answer the
questions posed by the five (5) immutable
principles.



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.



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.


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.



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.



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.



Know that we know something about our
“mission,” “vision” – going to the moon,
let’s see if we can answer the question of
“how” do we get there?



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.



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.



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.



So let’s see if we can gather everything
we need for our project.



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.



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.



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.



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



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.



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.



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.



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.



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.

36/62


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



So let’s look for some impediments in our
project to fly to the moon.
There are many of course, but let’s see if
we can come up with some that are not so
obvious.



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.



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.



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



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.



There are many opinions about
measuring progress to plan.
Here’s what some authors have said.



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

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.


Immutable principles of project management (fw pmi)(v4)

Immutable principles of project management (fw pmi)(v4)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Immutable principles of project management (fw pmi)(v4)

Similar to Immutable principles of project management (fw pmi)(v4) (20)

More from Glen Alleman

More from Glen Alleman (20)

Recently uploaded

Recently uploaded (20)

Immutable principles of project management (fw pmi)(v4)