PMI chapter meeting (v4)

Copyright ® 2010, Lewis & Fowler, All Rights Reserved

Thank you for inviting me to your
Chapter meeting tonight. I'm speaking
tomorrow at the Symposium on two
topics – Establishing the Performance
Measurement Baseline and the
Immutable Principles of Project
Management.
Both of these topics are critical to
increasing the probability of success for
your project.
Both these topics are founded on a set
of principles that have emerged over the
past decade in the aerospace and
defense business and are now moving
into commercial project management
processes.

PMI Fort Worth, Chapter Meeting, 15 July, 2010 1/18


There are four outcomes for this talk.
1. I’m going to suggest there are gaps
in the understanding of the elements
of a project management process.
Not that our current PMBOK® based
processes are in error, but the units
of measure of progress, DONE,
effectiveness and performance are
missing.
1. That connecting the dots between
cost, schedule, and Technical
Performance Measures are needed
to improve the probability of
success.
2. Making these connections lives in
the discipline of Systems
Engineering.
3. Once these connections have been
made, we need to realize that all the
programmatic elements are random
variables, and we need to act
accordingly.



We’re all project managers or have
some relation to project management.
What’s the core problems we’ve seen in
the past and will likely see in the future
around project management.
Here’s a popular list I’ve encountered
over the years.
You’re list many have some of these or
even better ones.
No matter what the list is, any project
management framework must address
them head on if you’re going to have a
chance to end successfully.
I’m going to show you five principles of
project management that have served us
well over the years.
I’m going to suggest these principles are
immutable. That is they are the same for
every project management domain and
context in that domain.
From mega projects in construction and
defense to small agile software
development projects with the customer
in the same room.
Immutable = not subject or susceptible
to change or variation in form or quality
or nature.



So how can we put these principles in
practice?
The anchor to the practices that are
guided by the principles is to focus on
the Deliverables.
All other elements of the project are
secondary or possibly unimportant to
the deliverables.
This paradigm may appear different than
the process groups and knowledge areas
of PMBOK®.
These PMBOK® elements are certainly in
support of this deliverables view, but it
may not be explicitly stated in a way we
can “connect the dots.”
When we leave tonight I’m going to
suggest you’ll have a different paradigm
when you look at PMBOK®
One focused on “what does DONE look
like.”
How to measure DONE in units
meaningful to the buyer.



With this notion in mind, we can define
what DONE looks like.
It is defined when we answer these five
(5) questions.
These questions are core to every
project. They the are source of processes
that define the immutable principles.
They must be answered for success.
When they are not asked or not
answered the probability of success is
lowered, many times lowered to the
point that the project goes off track and
possibly fails.
We’ll see in the coming slides how these
questions and their answers can be your
means to increasing the probability of
success.



The five irreducible principles of project
management that answer the previous
questions 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 question “where are we going” must
be answered in ways meaningful to the
buyer.
The answer can be in the form of a
needed capability.
This answers the question, “What
capabilities to we need to posses to call
the project DONE?”
Or what are the requirements that need
to be fulfilled to call the project DONE?
The answer to this question is a PLAN.
The PLAN says where we are going. It
does not say how we’re going to get
there, just where.
One critical missing element for many
troubled projects is the answer to the
question WHY. WHY are we doing this
project?
The PLAN comes after we answer the
question WHY. This answer comes from
the business strategy or mission strategy
of the project and is outside the context
of the five (5) immutable processes.



HOW to get there is described in the
Schedule.
Let’s walk through an example.
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. I
t’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.
The PLAN is to summit in a day and
return safely. The SCHEDULE is the steps
needed to actually reach the summit and
return.
This SCHEDULE includes all the work
effort needed to summit, the order in
which we’d perform these work
element, the dependencies between the
elements, any resources we’ll need for
success, and both schedule and cost
margins.



With the destination in mind and
schedule of all the activities needed to
reach our destination, do we know if we
have everything we need to get there?
This answer includes all the resources,
technology, processes, and other items
that will enable success.
These dependencies must be identified
in the Master Schedule.
For example in NASA programs –
Government Furnished Equipment is
common.
Same for external dependencies in
Enterprise IT projects.
These dependencies have their own
schedules and the credibility of those
schedules must be assessed in the same
way we are going to do in the next steps.
This “all in” System of Systems approach
is needed to collect “all” the elements of
the project PLAN and SCHEDULE.



There are always impediments to
progress.
It’s just part of a project. It’s actually
part of everything we do as project
managers.
But do we know them? Can we name
them and what their impact might be on
the project?
Do we have some way of “handling”
these impediments – the risks to the
project.
There are of course the named ways:
1.Risk avoidance eliminates the sources
of high risk and replaces them with a
lower-risk solution.
2.Risk transfer is the reallocation of risk
from one part of the system to
another.
3.Risk control manages the risk in a
manner that reduces the probability /
likelihood of its occurrence and / or
minimizes the risk's effect on the
program.
4.Risk assumption is the
acknowledgment of the existence of a
particular risk situation and a
conscious decision to accept the
associated level of risk without
engaging in any special efforts to
control it.



Here’s where many projects start their
path toward the ditch.
Progress can only measured in the
assessment of Physical Percent
Complete. The percent of the Planned
progress.
 How far along should we be at this
point in the project?
 Where are we actually along the path
to complete?
 What was our planned progress at this
point in the project?
The unit of measure for Physical Percent
Complete starts with tangible
evidentiary Materials brought to the
table and shown to project participants.
The passage of time and consumption of
resource is never a measure of progress
to plan.
This last approach is common in projects
that have gone off the rails.
When we are planning and scheduling
the project we need to define upfront
what these measures of percent
complete are. Predefining them.
Agreeing we measure progress with
them.
There can be no retroactive assessment
of progress to plan. Once defined the
measures of physical percent complete
are placed “on baseline,” and represent
the only assessment of progress.



If we look back to the beginning of
tonight's talk to the 4+1 major activities
of Deliverables Based Planning® and
connect them with the five (5)
immutable principles of managing any
project, we have to look for the evidence
that we’re following the processes using
the principles.
You may have other evidence.
No matter what you have, there has to
be artifacts showing that you’ve done
the work to answer the 4+1 questions
and satisfied the five (5) immutable
principles.
One critical concept in any successful
project management method is
“evidence based” assessment of
progress.
Personal opinion, verbal discussion,
management statements are not
acceptable.
Only tangible evidence of progress to
plan is acceptable.



Each of these pieces of evidence must
provide some level of credibility.
One method of measuring this credibility
and its tangible value is through a
systems engineering paradigm.
This by the way is one of the difficulties
agile processes run into.
They mention “value” but don’t have
units of measure for that value.
Independent of that, here’s how we do it
in the systems engineering world.
MoE’s are defined by the customer.
They are the measures of the capabilities
needed to fulfill some mission.
MoP’s are defined by the supplier.
They describe the behaviors needed to
fulfill the mission.
The KPP’s are the numbers we’ll assign
to the MoP’s.
The Technical Performance Measures
(TPM) are the collection of these
individual elements.



All this effort, definitions, processes ,and
information has only one goal.
The goal is to describe in a tangibly
measureable way what DONE looks like.
This is the only reason for all these
processes.
This is the role of the Project Manager
and the Project Controls staff.
To define what DONE looks like, manage
all the resources toward that
description, handle all the risks and
impediments to progress.
All of this starts – and ends – with what
the customer needs in terms of
“capabilities.”



If we fail to provide credible answers to
the five (5) immutable project
management processes, then we’re
headed in the wrong direction.
 We will not be able to measure our
progress to plan.
 We will have not defined what
business or mission capabilities are
needed for success.
 We won’t know what the
requirements are to fulfill these
needed capabilities.
 We'll have failed to identify and
handle the impediments to our
progress to plan.
Our only source of success will be HOPE.
Hope that we’ll discover these as we go.
Hope, that the potential impediments to
progress won’t come true.
Hope that our customer can articulate
what DONE looks like for us along the
way.
When Hope is are strategy, we’ve
started on the road to failure.



In closing here’s the next level down for
Deliverables Based Planning®.
Each of the four (4) processes shown
here – plus the continuous risk
management has major sub-processes,
which also have sub-sub-processes .
There are 74 processes in all.
I have handouts that cover all these
processes, you’re welcome to.



So with that brief overview of
Deliverables Based Planning® and its
application to projects in general, are
there any questions I can answer in the
short time we have left?
My colleague and I will be here for more
questions and answers.
Tomorrow the Symposium Work Shops
will delve into these topics in greater
detail, I look forward to seeing you
there.



Here’s my contact information if you’re
unable to attend tomorrow’s work shop
or would like more information about
these processes.


PMI chapter meeting (v4)

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a PMI chapter meeting (v4)

Semelhante a PMI chapter meeting (v4) (20)

Mais de Glen Alleman

Mais de Glen Alleman (20)

Último

Último (20)

PMI chapter meeting (v4)