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

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.
5 Immutable Principles of Project Success
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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

Glen B. Alleman, Niwot Ridge Consulting, LLCPage 25

Glen B. Alleman, Niwot Ridge Consulting, LLCPage 26

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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (15)

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

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

Mais de Glen Alleman

Mais de Glen Alleman (20)

Último

Último (20)

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