5 immutable principles of project success (v3)(notes)

5 Immutable Principles of Project Success
Thank you for inviting me here today.
The topic should be one we all are
familiar with, since it is nearly impossible
to not have experienced a project failure
at least once in our career.
The principles I’m going to speak to you
about are universal. Applicable to any
project, of any size, in any domain.
The example project was one I was
involved with as a Program Manager. One
that was manifestly important, and nearly
impossible. One that shaped how I see
the principles, practices, and processes of
managing projects in ways I had not
considered before.
What you’re going to hear is not the
solution to project failure. It is the
framework for that solution. The actual
mechanics of managing a project are
based on these principles. The practices
used in this management should be
based on the se principles. And of course
the process ad tools should implement
the practices.
I’d like to present the 5 Immutable
Principles of project success using
examples from a program I was a
participant in. Rocky Flats Environmental
Technology Site, in Golden Colorado.

Page 1

Glen B. Alleman, Niwot Ridge Consulting, LLC


Let’s start with positioning our interest in
the project domain.
Nearly every business activity is based on
a project in some way. Even the
operational aspects of a business are
projectized through processes,
procedures, and business management.
Today I’d like to focus that types of
projects Land speaks of. The really
important ones that are nearly
impossible.
I was a participant in one of those
projects – Rocky Flats Environmental
Technology Site. The name of the site was
a nice marketing term for the cleanup of
a nuclear bomb factory.
It was nearly impossible. The previous
contractor had spent $4B and not done
much.
When Kaiser-Hill (a joint venture between
ICF Kaiser and CH2MHill) won the
contract, they had a plan that was
dramatically different from the past
attempts to cleanup and close the site.

Page 2



Rocky Flats was a U.S. Department of
Energy National Nuclear Security Agency
production site that operated from 1952
to 1992.
Rocky Flats was the most contaminated
nuclear weapons plant in the country,
was an environmental disaster and the
site of rampant worker unrest.
Estimates projected that cleaning up and
closing the facility would take 70 years
and $36 Billion. The actual project was
completed in 10 years for $6B.

Page 3



For projects where success is mandatory,
the outcome critical to the business, and
risks are high, success comes about
through principles, practices, and
processes.

I’m going to try and convince you today
that the 5 Immutable Principles are the
foundation of any projects success.
These Principles are “Immutable”
because they must always be present.
They are the foundation on which the
Practices and Processes are built.
We won’t look at the Practices and
Processes, but they are critical to the
success of any project as well.

Page 4



After the Rocky Flats project had completed,
the book Making the Impossible Possible was
written about the lessons learned from the
cleanup. This book examines the cleanup
and closure of 800 buildings with 3 million
square feet under roof, on a 6,000 acre site
with many tons of hazardous materials just
10 miles from Denver’s suburban
population.
Success is explained in the book through the
model of Positive Deviance or Heliotropic
Abundance. The theoretical framework of
Competing Values (shown here) is the basis
of the book.
The 5 Immutable Principles of Project
Success are derived from my experiences as
a Program Manager at this site.
Two elements of the competing values
framework are the basis of this talk. Control
and Create. Both are needed for success.
Control alone limits creativity. Creativity
alone results in out of control work
activities.
Control provides stability measurement,
clarity of objectives, discipline, and detailed
planning.
Creativity enables agility in the presence of
constant change.

Page 5


Of the four quadrants of positive
Deviance we are interested in Control and
Create as the basis of the 5 Immutable
Principles of project success.
The focus is on clear and concise
descriptions of Done, while innovative
solutions to technical, programmatic, and
operational problems are needed at
every step along the way to Done.
We need both, but Control is the basis of
Create. Control is often criticized as
inhibiting or sabotaging performance.
Control emphasizes efficiency, smooth
functioning, predictability and
standardized procedures. It focuses on
tight control of internal activities. The
result is consistency and dependability in
contrast to innovation and dynamism.

The success of any project is still
grounded in extending beyond doing well
to doing spectacularly well, and
developing the mechanism that produces
extraordinary results.
This requires creativity, a clear and shared
vision of the future, symbolic leadership
(leaders doing the work as well),
innovative ideas about work, and creating
a sense of meaning and importance
attached to the tasks being pursued.

Page 6



With this background, let’s look at the 5
Immutable Principles of Project Success.
I would suggest these are applicable to
any technical domain. Any project
management method. Any business
domain. They are universal and
Immutable – meaning they don’t change
over time. They are permanent principles
that must be applied for the success of
any project.
The Principles are in the form of
questions in this example. There are more
formal statements about the Principles,
but starting by asking 5 questions shows
how the principles can be applied in any
situation.
When there is not a credible answer to
the question, this is an indication there is
likely trouble on the project and the
probability of success has been lowered.

In the next charts there will be the
questions – numbered 1 through 5. Then
there are 3 answers. Starting with the
simplest answer – Number 1 – through
the best answer – Number 3.
It is the Number 3 answer that we are
after.
Being able to produce the answer in that
style may be difficult and require
Practices and Processes. But we have to
start with the Principles.
So let’s start.
Page 7



The first Principle is to ask if we know
what Done looks like. This sounds like a
simple question. But turns out to be the
root cause of most project failure.
Done must be described in meaningful
units of measure for the decision makers.
1. Our first response is usually to make a
list of features and functions for the
product of service produced by the
project. This is necessary but far from
sufficient to describe Done. We don’t
know how these features and
functions interact, how they provide
value to the customer.
2. The interdependencies are next. We
need to show how each feature or
function is dependent – if it is – on
other features and functions. This
usually starts with the Work
Breakdown Structure (WBS) showing
all the deliverables from the project.
The WBS needs a WBS Dictionary to
show how we are going to measure
the performance, quality, compliance
of these outcomes with each other
and the customer.
3. But the WBS and its Dictionary are
not enough to know what Done looks
like. We need to know what
Capabilities are being provided by the
project. What is the customer going
to DO with these outcomes? How are
they going to satisfy the business
needs or mission?
The Capability to do something is what
the customer bought.

Page 8


These Capability statements are clear and
concise. Long before we ever arrived in the
moon, Robert Goddard knew what
capabilities were needed to get there.
On October 19, 1899, Goddard climbed a
dead tree to trim some branches. He was 17.
He is quoted as saying … “I imagined,” he
later recalled, “how wonderful it would be to
make some device which had even
the possibility of ascending to Mars, and how
it would look on a small scale, if sent up from
the meadow at my feet. . . I was a different
boy when I descended the tree from when I
ascended, for existence at last seemed very
purposive.”
He had in his mind what capabilities were
needed to fly outside the Earths atmosphere.
He knew some of the units of measure that
had to be fulfilled to do this.
If we don’t have some vision of the project at
the Capabilities level, we really can’t say what
Done looks like. We can describe the
technical aspects, but we can’t say what we
are going to do with those technical aspects.
This definition of Capabilities is a Systems
Engineering role. There are formal processes
to elicit these Capabilities through the
Concept of Operations, Scenarios, and Use
Cases, making tradeoffs between cost, risk,
schedule, and technical performance, and
balancing all the feasible alternatives.
The result is the Measures of Effectiveness
which tell the customer the project will meet
the needed capabilities.

Page 9


With the needed Capabilities we can now
develop a plan and schedule for the work.
Knowing how to get Done on–budget and
on–schedule means knowing what
requirements will have to be fulfilled.
Poorly formed requirements contribute
as much as 25% to the failure modes of
programs and projects.
This starts with Fact Finding, Gathering
and Classifying the Requirements,
Evaluating and Rationalizing the
Requirements, Prioritizing them, and
Integrating and Validating the
Requirements.

With this in hand we can start building
the packages of work that implement the
requirements.
The result is a Plan and a Schedule. The
Plan is the Strategy for the proper
delivery of the Capabilities produced by
the project. The Schedule is the sequence
of work needed to implement the
Strategy. Both are needed.
The Plan is emergent, since it is a
strategy. The Schedule tests this strategy
on short term boundaries, with measures
of physical percent complete.
Both the Plan and the Schedule must be
capable of responding to change as new
information about requirements, program
performance, and risk emerge.
But the needed capabilities should
remain stable if we are to have a baseline
on which to execute our project.
Page 10



The Plan can be very simple or it can be
complex.
Here’s a plan that took us to the moon
and back. This picture shows a simple
concept. Build the launch vehicle,
develop the fuel to power it, the space
craft on the top, train the astronauts, do
the testing, and fly.
The Plan shows the 6 major systems ,
their approximate duration in years, and
the dependencies between them are all
that is needed to confirm the feasibility of
the project.
Notice the longest activity is the training
of the crew. No one had ever flown in
space before all the way to the moon and
back. So training was high risk and critical
to success.

Page 11



One view of the Plan is the vertical
integration of the deliverables.
This is the deliverables traceability view.
At the bottom is our deliverable.
The deliverable is produced by work
contained in a work package. A Work
Package says its name. it produces a
single outcome.
The technical capabilities needed for the
project’s success are produced by the
Work Packages.
Finally these Technical Capabilities
produce business or mission capabilities
needed by the customer for business
success.
This traceability is necessary for a
credible Plan and Schedule. It is also
necessary for a credible project delivery
process.
This traceability tells everyone what Done
looks like and how we are going to get
there.

Page 12


With the Plan in place and the “packages of
work” identified in the Schedule, we can
construct a picture of how we are going to
reach Done.
This picture is not like the typical horizontal
scheduling activities we see in all the
scheduling tools.
This picture starts with the vertical
integration of the deliverables as they
progress through their maturity life cycle.
This is called the Integrated Master Plan. This
Plan shows the Measures of Effectiveness and
Measures of Performance we need to achieve
to reach a specific level of maturity.

This notion of levels of maturity can be seen
is we use some words Preliminary is a work
description. We all know what preliminary
means. It means we’re not done yet. We
have a preliminary design we have a
preliminary cost estimate or a preliminary list
of subcontractors. We know enough about
the project to make some decisions, but we
need more details before we can say for sure
the cost, the design, and the subcontractors
are all in place.
This incremental approach allows us to move
foreword without all the details, while still
having visibility into what Done looks like.
Since RFETS was many times discovery driven,
planning had to be increasing maturity driven
without the planning horizon reaching the
final date. This incremental and iterative
approach is a critical success factor for all
projects.

Page 13



Projects are executed by people.
People consume time, money, and
materials.
How can we know if we have enough of
everything we need for success?
We need a Plan of course, in this case a
Resource Management Plan, showing
people, funding, and materials, and when
and where we need it.
1. We can start with a simple list. This
gets us to write it down.
2. Next we need to assign people and
money to the needed resources. How
many of each special skill type will we
need for this project.
3. In the end though, we need to lay out
these needs against the schedule of
work. We need to resource load the
schedule. This sounds like a lot of
work and it is. But without this in
place we really have no idea if the
project is feasible.

Page 14



Matching people to needs is at the heart
of resource management.
Without understanding what skills are
needed we can’t do this matching. This
information comes from the subject
matter experts that have defined the
“packages of work” and their
deliverables.

Page 15


We usually start by identifying risks. But
risk is the result of uncertainty. There are
two types of uncertainty – reducible
uncertainty and irreducible uncertainty.
We can do something about reducible
uncertainty. We can buy more knowledge
about this uncertainty – it is epistemic.
We can run tests, build prototypes, look
at what others have done. The risk that
results is reducible.
The irreducible uncertainty is part of the
world around us. This uncertainty cannot
be reduced – it is aleatory uncertainty.
The only way to deal with this uncertainty
is through margin. Cost margin, schedule
margin, technical margin.
1. We have to start by identifying these
uncertainties and associating them
with the risks.
2. Then the impacts of the risk are
identified along with their
dependencies.
3. The probability of occurrence and the
probability of their impact can be
assessed and once the reducible risks
are handled the residual uncertainty
and its resulting risk.
With these impediments in hand we can
take actions to either protect our project
with margin or spend money to retire or
handle the resulting risk.
Page 16


The resulting Risk Management Plan
becomes part of the Integrated Master
Plan.
Risk management is how adults manage
projects – Tim Lister.
We can manage the risk with either
margin or with specific risk reducing
actions. Either way, we must manage the
risk.
The discovery of uncertainty and the
resulting risk is a continuous work
process. It is repeated weekly, monthly,
quarterly, annually. It is never ending.
Risk drives variance and variance must be
managed actively as part of the project
management process.
The retirement of risk must be defined in
the planning documents. The reduction
from RED to YELLOW to GREEN must take
place as planned. If we miss the buy
down target we will have created more
risk, since the retired risk was not
removed as planned.
If we spend more money than planned to
retire the risk, we are over budget as
well. Retiring risk is a project work
activity funded on the baseline.
Management Reserve maybe used to
those “reducible” risks we have not yet
decided to retire.
Page 17


With our Plan, Schedule, Resources, and Risk
Management Plan, we can now determine
how we are going to measure progress to
these plans.
1. The customer bought outcomes,
deliverables, capabilities. We need to
describe these in a way the customer
understands. Units of measure that are
meaningful for making decisions.
2. These are best described as Technical
Performance Measures. These are
attributes that determine how well a
system or system element is satisfying or
expected to satisfy a technical
requirement or goal.

3. But these alone are not sufficient for the
success of the project. We need
Measures of Effectiveness (MoE),
Measures of Performance (MoP), and Key
Performance Parameters (KPP).
 MoEs are operational measures of
success that are closely related to the
achievements of the mission or
operational objectives evaluated in the
operational environment, under a
specific set of conditions. These are
“customer satisfaction” measures.
 MoPs characterize physical or
functional attributes relating to the
system operation, measured or
estimated under specific conditions.
 KPPs represent the capabilities and
characteristics so significant that
failure to meet them can be cause for
reevaluation, reassessing, or
termination of the program.

Page 18



Measuring progress to plan means
measuring physical percent complete at a
fine grained level, where a 0% / 100%
assessments can be made.
You’re either done or your not done. No
in between. No vague assessment of
done.

This means the planning of the work
must identify tangible deliverables at that
level.
This may appear more difficult, but it
provides unassailable measures of
progress. No opinions. No almost done.
No “we’ll be done real soon.” Either
you’re done or not done.
This approach provides the foundation of
Earned Value at the Work Package level. It
makes measuring progress easy.
More importantly it provides the basis to
answer the question – How long are you
willing to wait before you find out you are
late?
With these fine grained measures of
progress to plan, the answer can be the
tangible evidence of progress.
Typically this evidence is produced every
two weeks. No longer than monthly.
But it has to be tangible.
In this picture the tangible evidence is
barrels of waste packaged, sealed, and
ready to leave the site.
Page 19



If we don’t have a plan. If we don’t have
the proper resources available at the
needed time. Of we don’t handle risks if
we don’t have measures of physical;
percent complete.
We can’t have confidence the project will
be successful.
Without these elements, the probability
of project success is reduced. Possibly to
the point of project failure.
Without these elements, we have created
risk to our success with no handling
plans.
It is this unmitigated risk that creates the
unanticipated growth in our Estimate At
Completion.

Page 20



Over a large number of complex, high risk
programs there have been a small
number of root causes discovered for
project failure.
There are shown here.
Reading them they seem obvious.
Dealing with them is more difficult .
But we must deal with them and we must
have information needed to deal with
them.
This information comes from the
practices, processes, and tools used to
manage the project.
Scheduling, cost, risk, performance
measurement, and forecasting tools and
the processes used to apply them.
Only when all this information in
integrated though a single “lens” can we
have the needed visibility to take
corrective action to keep the project
GREEN.
Stay on schedule, stay on budget, comply
with the technical requirements. Or if
not, know about the variances soon
enough to take corrective action.

Page 21


Let’s quickly review the 5 principles of
project success in the time remaining.
1. What does done look like? The
customer needs to know what
capabilities will be possessed when
the project is done. The capabilities
produce the business value or fulfill a
mission objective.
2. How do we get there? We need a
plan and a schedule. We need to
arrange the work properly in the
sequence to produce continuous
value.
3. Are there enough resources? People,
material, facilities? Are they the right
people, does the material arrive at
the needed time, are the facilities
adequate to produce the needed
outcomes?
4. What are the impediments to
progress? Risk management is how
adults manage projects. Do we have a
risk register? Do the risks have
handling plans? Is the cost and
schedule baseline adjusted for these
risks?
5. How do we measure progress? The
only way is tangible evidence of
physical percent complete. This
means “show me” the outcomes and
show me they meet the
specifications, on the planned day for
the planned cost. If not we’re late,
over budget, and out outcomes
probably don’t work right.
Page 22



At the end of the Rocky Flats program,
this is what done looked like.

All cleaned up, lock the gate and throw
the keys over the fence.
On-time, on-budget, met technical
requirements.
Project of the Year, 2006 PMI.
http://goo.gl/oCL0WJ

Page 23



Thank you for your time.
I hope you got some new ideas about
how to increase the probability of success
for your projects.
The advice shown here should be applied
to everything you do in managing your
projects.
Evidence to the answers from the
questions that represent the five
immutable principles.
Evidence of what done looks like.
Evidence that you have a credible plan
and schedule.
Evidence that you have the right
resources, people, facilities, capacity for
work.
Evidence you have identified the risks,
assessed them, have handling plans.
And most of all evidence that your are
making progress to plan through tangible
measures of physical percent complete.

Page 24



Page 25


5 immutable principles of project success (v3)(notes)

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a 5 immutable principles of project success (v3)(notes)

Semelhante a 5 immutable principles of project success (v3)(notes) (20)

Mais de Glen Alleman

Mais de Glen Alleman (20)

Último

Último (20)

5 immutable principles of project success (v3)(notes)