Establishing the performance measurement baseline (pmi fort worth)(v4)
-
Upload
glen-alleman -
Category
Technology
-
view
8.515 -
download
1
Transcript of Establishing the performance measurement baseline (pmi fort worth)(v4)
Thank you all for coming to the work
shop today.
The title of the Work Shop title speaks
about the Performance Measurement
Baseline.
This may be a new term for some of
you. After our four hours today, I’m
hoping it will be a term you'll be using
back on your own projects.
Let’s define what we mean at this point
in the work shop. At the first slide.
The Performance Measurement
Baseline is a time-phased budget plan
for accomplishing work, against which
the project performance is measured.
It includes the budgets assigned to
scheduled work , their budget spreads,
and the applicable indirect budgets.
This budget plan is derived from a
resource loaded Master Schedule.
These resource loads, along with other
information, are contained in Work
Packages.
You’ll hear many times the phrase
“cost and schedule.” I want you to start
thinking about what it sounds like when
you say “schedule and cost.”
It’s the schedule – the sequence of the
Work Packages – that is the basis of
the cost.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
1/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
This will be our agenda for the next
four hours.
We’ll have a quick survey of where
we’re going, some background on the
concept and then we’ll walk through
the six steps needed to establish the
Performance Measurement Baseline.
The outcome of these six steps is an
understanding of how to put the
information to work on your projects.
Along the way we’ll have hands on
exercises that will demonstrate the
processes and outcomes for each of
the six (6) steps in building the
Performance Measurement Baseline.
Our exercises will define the PMB for
a home toaster.
It’ll be a nice toaster, but we’ll touch
each of the steps in enough detail, that
you’ll be able to replicate them on
your real projects.
So let’s get started.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
2/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Here’s how we are going to build our
Performance Measurement Baseline.
It’s a simple process in principle. But of
course in practice, it’s always harder in
practice.
We’ll use the exercises to pull out
these practices from the principles, but
let’s have a quick look first at the
principles.
1. Build a Work Breakdown
Structure.
2. Define the Work Packages that
produce the deliverables at the
terminal nodes of the WBS.
3. Arrange these Work Packages in
some logical sequence.
4. Assign the resources needed to
complete the Work Packages in a
timely manner.
5. Turn this whole collection of
information into a credible
Performance Measurement
Baseline (PMB).
One final step is to perform the
continuous risk management processes
inside these five (5) steps, so we
actually increase our probability of
success.
The key here is “increasing the
probability of success.” We need to
remember this phrase. It’s the inverse
of many of the efforts made to
manage projects.
Connecting actions with outcomes is the
Critical Success Factor.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
3/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Let’s look at a broader context of the
five (5) essential process areas for
managing any project.
Other project management paradigms
have even other process areas –
Prince2 for example.
But the process areas here have
emerged over the course of several
decades of managing defense, large
construction, and enterprise IT projects.
These five (5) processes are:
Identify the needed capabilities – this
is commonly missing from many
projects. A capability is not the same
as a requirements. One way to think of
this in the Enterprise IT is the ask “if I
had the system, it was free, it worked
on Monday, what would I do with it?
Once you’ve defined the needed
capabilities, you need to identify the
technical and operation requirements
needed to enable these capabilities.
Then comes establishing the
Performance Measurement Baseline.
And then the execution of the PMB.
At each process, we must apply
continuous risk management in place
and operational.
The other 4 processes areas are work
shops unto themselves, so for today,
we’ll concentrate on building the PMB
and assume the other 4 areas are in
place.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
4/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
The term “baseline” has an important
role here. It is a “controlled” document
that contains the agreed on
information about the future
performance of the project.
When we say “baseline,” we really
mean three baselines.
The Technical Baseline is the
agreed on set of technical
requirements. These can be changing
or they can be frozen, or any place
in between.
From the technical requirements
baseline, we have the work needed
to implement them in the Schedule
Baseline.
From this work we can establish the
Cost Baseline.
All three baselines are connected in an
inseparable relationship, change one
and the other two are impacted.
This is sometimes called the “iron
triangle.”
Trying to make tradeoffs between the
three variables can be done early in
the project.
Once underway, trade offs between
these three baselines and the belief
that there will be no negative impacts
is a Ponzi scheme.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
5/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
What we’re here for today is to build
the Performance Measurement
Baseline. The core elements of the PMB
are Work Packages.
Work Packages are “lumps of work,”
that produce a single outcome. The
idea of the single outcome has
important attributes.
If we have multiple outcomes, it’s hard
to measure progress with 0% or 100%
completion criteria.
If we have multiple outcomes who’s
accountable for each outcome?
Try as hard as possible to have a
single outcome for each Work
Package.
Once we’ve connected the Work
Package with an outcome, we can ask
other questions:
How long will it take?
How much will it cost?
Who’s accountable for delivering the
outcome?
What are the risks involved in
delivering this outcome?
What dependencies are there for
this Work Package or other Work
Packages or external items?
We need to answer these questions, if
we ever have a chance at having a
credible PMB. By credible I mean
“believable.” It doesn’t have to be
“right,” there are few “right” answers.
It has to be feasible and it has to be
credible.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
6/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Let’s move to the six (6) steps needed
to build this “credible” Performance
Measurement Baseline.
These six (6) steps are all mandatory.
They need to be performed in the
defined order.
They need to perform their internal
detailed steps in the right order as
well.
But first let’s have a look at what is
going to take place from this point
forward.
Since this is a workshop, we’ll be doing
workshop things.
This means I’ll be asking you questions,
you’ll be engaging me in the answers,
and I’ll be drawing pictures on these
flip charts of those answers.
The Work Shop is designed to produce
useable output that you can take back
to your projects and put to work in
some form.
So let’s get started.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
7/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Before we start with the Performance
Measurement Baseline development,
let’s talk a bit about the predecessor
activities we saw on Page 4.
Capabilities are not that well known
outside government and large
construction projects.
But they are a critical success factor of
any project. In the IT world a simple
example of a capability would be the
“process invoices from our top tier
suppliers.”
How do we do this – we don’t know.
But we need to posses this capability
to have some business benefit.
General Patton stated the capability
he needed.
We need to state the technical and
business capabilities needed that result
from the project.
We need to have these capabilities
made public.
They need to be the backbone of
WHY we are doing this project.
When things start heading for the ditch
– and they will – the stated
capabilities bring us back to reality.
8/62
Here’s a page from our Deliverables
Based Planning ® method handbook.
This method is applied in a variety of
domains and contexts in those
domains.
The critical success factor for
Deliverables Based Planning® is to
focus on the deliverables.
Not on the effort, the technology, the
resources.
These items are important. But the
customer paid for the deliverables. By
customer I mean the general notion of
a customer. A business customer, a
government customer, an internal
customer.
The units of measure for these
deliverables must be meaningful to the
customer. This is the reason to start with
the Capabilities Based processes
shown in slide 4.
We’ll assume these have been
defined, and the technical and
operational requirements defined.
Now we’re taking those requirements
and building the Performance
Measurement Baseline that will make
them appear.
These 6 steps are “immutable” in that
they are all needed and they need to
be performed in the proper order.
This doesn’t mean they not iterative
and incremental, but each step takes
information for the previous step.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
9/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
The first step is the obvious one.
What are these deliverables and what
are the components of each
deliverable?
What are the products that represent
these deliverables?
What are the processes that build
these products?
This is the role of the Work Breakdown
Structure (WBS).
The best place to start with learning
about how to build a WBS is the MIL-
HDBK-881A. You can find that on the
web.
In 2011 this “handbook” will be
migrated to a Standard, which means
it will be mandatory for many domains
For the moment, ignore all other
descriptions and advice for building
the WBS.
Always start with the guidance that
has WBS in its title.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
10/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Here’s a “notional” starting point.
We have a business need, that was
provided prior to establishing the
Performance Measurement Baseline.
The need is “Process Invoices for Top
Tier Suppliers.”
In order to fulfill this “mission need” or
provide this capability, we’ll need to
do two more things:
Capture the invoices electronically.
Route them to payables.
For each of these “accomplishments”
(we’ll talk in a bit what that term
means), we’ll to produce a few
deliverables:
We’ll need to verify the receipt of
materials – that is we the system to
provide a way to verify the receipt
of materials.
We’ll need to update the “on hand”
balance for the materials.
Verify the payables account
information.
And then schedule the payment.
These “terminal nodes” are the
deliverables for the software elements
– in this example.
In any example, the terminal nodes
should be a single unit of functionality,
a “thing” that is functional or parts for
things that are functional.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
11/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
These terminal nodes are the
deliverables.
To get them delivered we need to do
work. The work is performed in a
Work Package.
So what is a Work Package?
A Work Package is simply a task /
activity or grouping of work. A WP
is the point at which work is planned,
progress is measured, and earned
value is computed. It can be
translated into different terms in
different companies and functions. It
can be a design job, a tool design
package, a build-to-package, a shop
order, a part number, a purchase
order or any other definable task /
activity at whatever level control is
normal for project management with
in the company.
– Defense Acquisition University.
The Work Package is a “lump of
work” that produces an output.
Preferably a single output that fulfills
a requirement, which in turn enables a
capability to exist that the customer
can make use of.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
12/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
The WBS is a framework for
specifying project deliverables .
It defines the project in terms of
hierarchically related, product-
oriented elements.
The goal is to develop a WBS that
defines the logical relationship among
all project elements to a specific level
(typically Level 3) of indenture that
does not constrain our ability to define
or manage the project and resources.
Other attributes include:
a. A product-oriented tree composed
of hardware, software, services,
data, and facilities.
b. A WBS displays and defines the
product(s) to be developed and/or
produced. It relates the elements of
work to be accomplished to each
other and to the end product.
c. A WBS can be expressed to any
level of detail. However, the top
three levels are the minimum
recommended any project or
contract needs for reporting
purposes unless the items identified
are high cost or high risk. Then, and
only then, is it critical to define the
product at a lower level of WBS
detail.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
13/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
A good WBS is easy to recognize, but
hard to build.
A bad WBS is also easy to recognize
but hard to correct.
Here’s some attributes:
When someone says “I have a
WBS,” test that they do by looking
for the artifacts from these
statements.
If someone says “we don’t need no
stink’in WBS,” ask how they would
recognize the artifacts from these
statements.
I’ll repeat this again, the WBS IS the
Project.
The WBS does what it says – it is the
breakdown of the work needed to
produce the product or service.
It is the breakdown of the processes
that go along with the work to build
the products.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
14/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Let’s connect the dots between the
WBS and the Work Packages that
guide the activities that produce the
artifacts of the WBS.
This picture shows where the Work
Package lives in this process.
We take our notional WBS and for
each terminal node make a Work
Package.
The Work Package contains many
things, but the first thing it contains is
the list of work needed to produce the
deliverable.
This might be called a schedule, but
let’s not go there yet.
Let’s just get the list of work activities,
maybe their sequencing.
And most of all the list of “named”
deliverables produced by the Work
Package.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
15/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Here’s our two (2) step process for
producing a Work Package.
Remember the Work Package is the
“lump of work” that produces the
desired outcomes needed by the
customer to enable a desired
capability.
In this case – Process Invoices for the
Top Tier Customers.
These steps are simple:
Define what is being delivered in
some clear and concise manner.
Define the effort and duration for
doing the work that produces the
deliverable.
That’s it, it’s that simple. OK, maybe
there’s a few more details, but at the
top level that’s all there is.
You may not have noticed, but this
definition process is for a single Work
Package.
A Work Package at the terminal node
of the Work Breakdown Structure.
These Work Packages can be built in
parallel by the project team. We
haven’t connected them in a schedule
yet.
They should be – must be –
independent from each other.
Other wise our WBS tree is ill-formed.
A terminal node would have multiple
parents . Only baby cats and dogs
can do that – not a WBS.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
16/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
When we are defining the
deliverables we need to capture some
more data.
Here’s the start of that data capturing
process.
First a description of what it is we’re
delivering.
Then a name for the deliverable itself.
This deliverable can be a “thing,” in
the sense of a “thing” with a part
number.
It can be a report, ir can be a process
applied to a “thing.” in all cases it is
something tangible, something you can
point to.
Then a critical step must be taken.
We need to state how we will
recognize that our “thing” is complete,
how it is whole, how it is DONE.
We need to write down the criteria for
DONE and assign that criteria to a
Milestone or some other means of
assessing the DONE-ness of the “thing.”
This assessment must have some unit of
measure of DONE. We can’t just say
DONE. What do we mean when we
say DONE?
The answer has to be recognizable to
everyone on the project.
The DONE-ness of the Work Package
is the “exit criteria.” It is the evidence
that the Work Package is complete.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
17/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
With our definition of DONE, we can
start to define how long it will take to
get to DONE for the “thing” produced
by the Work Package.
This example is done in a table. We
have the name of the “thing” being
produced, we have an estimated
“effort” and a duration over which
that effort is applied. This is called the
“period of performance.” we must
separate effort from duration.
But most importantly, we have the
confidence in the duration and the
effort. The method used here is a
geometric scale of confidence
1 means we have good confidence
– this means we know the scope, the
duration and the effort is some level
of confidence. This level is
dependent on the domain and the
context in that domain. But for now
let’s say it’s to the 80% level.
2 means we know two of the
following – duration, effort, scope.
5 means we only know one of the
following – duration, effort, scope.
The reasons for the 1, 2, and 5 and
not 1, 2, and 3 has to do with
attributes of geometric series rather
than linear series.
It’s outside the scope of this Work
Shop to speak about this, but it is
critical to avoid using linear series to
rank things.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
18/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
With this simple example, here the
contents of a “real” Work Package.
Now let’s remember the advice from
Yogi.
The advice about there being a
difference between theory and
practice.
You'll have to decide what content you
want in your Work Package’s, but this
list has been developed over many
years of use.
So when you find something new and
useful to add, please call me and I’ll
add it here.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
19/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
There are all kinds of fancy tools for
managing stuff like this.
The best tool of all is Excel or Word.
Keep it simple. The nice thing about
word is you can make a template file
and send it around to all your Work
Package builders and they can work
on these in parallel.
The Excel way is cleaver, but doesn’t
support parallel work very well.
No matter the tool, make these
documents “controlled documents.”
Version numbers, archive all previous
versions. Publish the updates to a
public place.
Put these on a wall – the “wall of
truth.”
Walk the wall when you have
questions about the content.
Make this a “group” process – a group
ownership of the content.
Building the Work Packages
successfully sets the stage for all the
efforts that come next.
If you don’t invest time here, you’ll be
disappointed with the future outcomes.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
20/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
So now we’ve got our first cut at the
Work Package content.
Let’s visit an important concept.
In many cases, we tend to name things
in a short hand notation.
Test, Develop, Integrate. MSFT Project
provides 255 characters for the NAME
field and another bunch of characters
in the NOTES field.
We need to use these to make clear
and concise phrases about what we
are doing.
This chart comes from the guidance
used to construct the Integrated Master
Plan and Integrated Master Schedules
mandated on Aerospace and Defense
contracts.
It uses a grammar that makes it clear
what we are doing, what we are
doing it to, what the outcome is, and
most importantly what the planned
technical maturity of the “thing” will be
when we finish the work.
Since only the last work efforts
produce the final product or service,
the previous work efforts result in
partially complete – in terms of the
overall project – outcomes.
Preliminary, Initial, Testable, are
typical adjectives for the work.
When you start speaking in a
grammar like this, the clarity of DONE
results.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
21/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Now for some heavy lifting.
When it comes to estimating there are
two basic schools of thought.
1. Estimating is a black art, it never
results in any credible outcomes, is
a waste of time, and I really don’t
want to commit to do it.
2. The numbers I produce are
padded enough to protect me
from all the stuff I just said above.
Well here’s a 3rd option.
We can estimate with some level of
confidence almost anything in the
universe using a simple process. Here’s
an example. Suppose you want to
estimate the duration of a software
development deliverable.
Could you do this in a week? Of
course not, are you nuts.
How about a year? Sure, that’s a no
brainer.
OK, how about 6 months? Well that
seems like it might be possible if we
have what we need.
Uhm, how about 3 months? Nope too
short.
Well how about 4 months? Yea that
sound better.
In 5 questions we’ve got an answer to
within 15%.
Move that up to 20% and the work
can be done between 4 months and 5
months.
Repeat until done.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
22/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Now that we’re starting to assemble the Work Packages, we need to define what DONE looks like and how we are going to measure this DONE.
The measures of completion need to be tangible evidence from the Work Package.
The number of planned drawings, some kind of working software, a paved road, a flying machine. Something that can be measured. Something that can be defined up front.
A primary attribute of the Work Package approach is the notion that the what is delivered is 100% complete for the definition of what DONE looks like for that Work package.
Defining DONE is part of the Work Package definition. DONE can be a partial deliverable, a piece of another deliverable, really anything that moves the project forward in its maturity.
The key is that the deliverable is “pre defined” in the Work Package description and all progress is measured against this description.
There is no opportunity to have a partially complete – by the definition of DONE – deliverable.
The project planning then focuses on producing outcomes rather than effort. These outcomes support the increasing maturity of the product that fulfills the requirements developed prior to starting the PMB efforts.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
23/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Now for our first exercise.
Let’s start with a project and a simple
set of deliverables. Our project is to
build a toaster.
We all know what as toaster does – it
toasts bread. The result is toast.
But if we wanted to build one – or
actually many, what would the
Performance Measurement Baseline
look like?
Let’s start with the WBS for this
toaster.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
24/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
With our Work Packages, durations,
work efforts, deliverables, and
associated information, we need a
single integrative responsibility to look
after each Work Package.
The Work Package Manager is the
single point of accountability for the
delivery of the Work Package content.
She can make assignments in any way
needed, but in the end, there is only
one person “Accountable.”
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
25/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
The common Responsible, Accountable,
Informed, Consulted (RACI) diagram is
important for all projects.
It says who does what.
But Responsible is not the starting
point.
It’s who’s Accountable.
With the named accountable person,
responsibility flows from there.
Make this document public – put it on
the wall.
Walk the RAM when there is a
question about who is doing what.
Make this a public process, so
everyone knows who is doing what.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
26/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Just a reminder of what this person is
accountable for.
It’s always about the deliverables.
There are other activities of course, but
the deliverables are what the customer
bought.
This is why the planning and scheduling
process stops at the Work Package.
With the Work Package manager
being accountable for the
deliverables, “how” the work package
is executed must be the role of the
Work Package Manager and her
team.
Within the project governance guides,
you want to push down the
accountability to those doing the work.
They can’t do this work in any
arbitrary way, but they must be
accountable for the outcomes.
On our large projects, Work Packages
have a period of performance (start-
end), assigned resources, and a
budget profile. The Work Package
Manager may have a detailed
schedule, or just a bunch of notes stuck
to the wall.
This is called a “supplemental
schedule.” The details are not on
baseline. The Work Package is.
Below this level detailing out the work
is the role of the Work Package
manager.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
27/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Let’s take a quick look at what a RAM
(Responsibility Assignment Matrix)
looks like.
Remember the role of the RAM is to
make visible the Accountabilities for
the deliverables of the project.
The RAM is an “information radiator.”
It “says its name,” the responsibility
(accountability) assignment matrix.
When you don’t have one of these
hanging on the wall, confusion reigns ,
work overlaps, and gaps appear in
the work effort.
This may appear to be too controlling,
too “managerial.” If it’s just you and
two friends in the same room with the
customer, then you’ve got an implicit
RAM.
Move outside the room, have work
done in different parts of the building,
or have work done in different parts
of the city, state, country, continent and
not have the RAM – trouble follows
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
28/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
That section was easy, but now we
have some heavy lifting to do.
We need to put the Work Packages in
a logical sequence.
By this I mean the order of work that
maximizes (or minimizes) something
for the project.
It could be maximum use of the
resources. The minimum time to market.
The maximum business value.
The maximum mission capabilities –
getting the highest needed features in
the hands of the user at the earliest
possible time.
What ever this “maximization” is (or it
could be a minimization as well), it
must be shown in some visible form.
We’re back t o the BIG VISIBLE CHART
approach.
This can be a formal drawing hanging
on the wall, sticky notes, a white board
with doodles on it.
But it has to be visible.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
29/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
With the Work Packages in place,
documented to some level of detail,
the estimated durations, and work
efforts, it’s time to lay them out in some
order of execution.
We need to identify the predecessors
and successors of the “lumps of work.”
Note the tasks – that’s an issue for the
Work Package Manager.
The order needs to be logical in the
sense that the products produced by
the Work Packages can be consumed
by the next Work Package.
With this sequence, we can ask
questions about the flow of value, the
impacts on resources, the general logic
of how the work progresses toward
DONE.
At this level of granularity, the
emerging Master Schedule comes out.
This is then the basis of the Work
Authorization process.
The authorization of work is not used
to prevent work from being
performed, but to assure the work is
performed in the agreed on order.
Performing work “out of order,”
creates lots of problems, not the least
of which is outcomes sit idle while
others are waiting for materials.
This is a “work flow” issue and needs
to be addressed to ensure the best
effectiveness from the resources.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
30/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Here’s a really simple example.
But simple examples should be moved
into simple practices.
While there are many networks of
Work Packages around, complexity
should be there only when there is a
reason.
The Work Packages for building the
manned spaceflight systems in the
Orion project are complex.
Large ERP deployments around the
world are complex.
These are extreme examples.
The majority of project management
work should be just moderately
complex.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
31/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
When we say “well formed” what
does that mean. We know now that
units of measure of DONE are needed
to answer a question like that.
So what are the units of measure of a
“well formed” network?
All the work is arranged finish to start.
There are lots of ways to make
connections. But Finish To Start should
be the overwhelming majority of
connection logic. The reason is simple,
future work should not start until the
previous work is complete – 100%
complete.
There should be no constraints in a
perfect schedule. This is not possible of
course, but minimum constraints should
be your goal. This makes for a
“dynamic” schedule. A schedule that
can react to any changes – freely.
The next concept is a bit subtle. The
concept of “increasing maturity” may
be new in some domains. This means
that the products or services produced
by the Work Packages increase in
their maturity as the project moves
from left to right. This maturity is the
technical maturity. Performance,
stability, and things like that. This is
obvious as an after thought. Actually
planning this maturity is much better.
This maturity process has connections
with “value stream maps.” The value of
the work stream increases from left to
right.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
32/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Let’s take a short diversion here for a
critically important concept.
Leads and Lags in the schedule are
restricted in most defense projects.
NAVAIR, the Navy’s aviation arm,
allows 5 days lead or lag in the
Integrated Master Schedule between
any two Work Packages. On a 5 year
project 5 days might as well be zero
(0) days.
The reason to restrict leads and lags is
the follow on work activity then uses
partially complete products. This is the
source of “rework.”
When the predecessor activities finally
complete, there is likely more work
done and likely changes in that work.
The successor work then has to readjust
for these changes.
If there is intermediate output needed
by successor work, split the Work
Package and produce 100% of the
maturity for the intermediate output.
By “thinking” in terms of “increasing
maturity,” leads and lags can be
removed.
The project is a work flow of
increasing maturity. We want to
maximize this value within the
constraints of schedule and cost.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
33/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Here’s a picture of “real” Work
Packages being arranged by “real”
Work Package managers, on a “real”
project.
This is a simple process. Brown paper,
sticky notes, hand written Work
Package descriptions.
This process is called Product
Development Kaizen.
The critical idea is to have collective
ownership of the arrangement of the
Work Packages, while having single
accountability of the contents of each
Work Package by the Work Package
Manager.
Arranging the Work Packages is a full
contact sport.
When complete, leave the sticky notes
on the wall for all to see.
You will move these into a project
scheduling tool of course, but even then
you should have a “plot” of these
Work Packages.
34
Let’s see how we can arrange our
work packages in some logical order
in the next 5 minutes.
It may be obvious, but there might be
some subtle issues as well.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
35/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Money, we need money. Hopefully
other people’s money.
Budgeting is a painful process for all
projects. Whether it’s our money or
someone else's money.
Budgeting drives work, capabilities,
progress, event features.
We’ve waited this long to talk about
budget, because we need to know
what DONE looks like at some high
level before we can ask how much
does this cost.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
36/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Putting budget to Work Packages at
this point is real simple.
We’ve got definitions of the
deliverables, the needed resources
assigned – at least in lumps – to the
Work Packages.
Now it’s simple to budget.
From the head count, assign a labor
rate, possibly forward adjusted for all
the changes – and see what number
comes out for each Work Package.
In Earned Value terms – which we’ve
avoided so far – this is the Budgeted
Cost for Work Schedule – BCWS.
No matter what cost performance
management system we are using,
we’ve now got the “budget spreads”
defined for each Work Package.
Put this number back into the document
that describes the Work Package. This
is one advantage of building the
Work Packages in Excel, you can now
do math on the budget numbers.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
37/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
But in the end this budgeting process
needs to be in the project tool.
You’ll never get cost and schedule
integrated if you don’t start the
integration on day one.
NEVER separate these pieces of data.
If you do, you’ll never get them back
together.
It is important to remember that we set
the duration (period of performance)
of the Work Package up front from
the planning process.
Now is NOT the time to be making
changes to the contents of the Work
Package.
You missed that opportunity when we
baselined the Work Packages.
We can assemble the sequence with
sticky notes – my preference. Or with
a scheduling tool.
The reason to do the assembly on the
wall with sticky notes – or printed
cards is better – is you can rearrange
the Work Packages very easily and
that be a group effort.
With this sequence we can then go
through and spread the resources we
have, or figure out what resources we
need, or any combination.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
38/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
The inverse approach which is useful
sometimes is to take the resources
we’ve got an lay out the sequence.
This is how agile projects plan work.
Moving stories from the “to do” column
to the “worked and completed” column
on the cork board.
In both cases, we’re bound by the
resources, budget, periods of
performance.
In both cases we know what DONE
looks like – we’re never confused
about that.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
39/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Let’s not do too much effort here, just
enough to get the idea of allocating
budget to the Work Packages.
If we let to tool do the math we can
have MSFT Project calculate the total
project cost, from the Work Package
cost for projects that have a Not To
Exceed target.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
40/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Now comes something that is rarely
seen outside government projects.
What are the units of measure – the
meaningful units of measure – for the
completion of the Work Package, and
the project as a whole?
We MUST define these before we
start any work.
There’s a simple reason for this – if we
don't define DONE up front, we won’t
recognize DONE when it walks in the
door.
Think of the GPS navigation
paradigm.
The driving navigation product
“knows” when you’ve arrived at your
destination, even if you don’t
recognize the building.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
41/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
The first thing to do when defining the units of measure of DONE is to agree that they must be “objective.”
Tangible Evidentiary Materials is the formal word.
They have to be tangible. Something you can touch, see, smell, look at.
A simple example can be around drawings.
Our Work Package produces 10 drawings for our workshop example toaster.
We say the period of performance for these drawings is 2 weeks.
Assuming a linear production of work, we should see 5 drawings at the close of business Friday for the first week.
We defined this Measure of Performance (MoP) in the Work Package. On the Friday afternoon, you can walk over to the drafting area and ask to see the 5 drawings that are planned to be completed.
If you see the 5 hanging in the stick-file, then you are 100% complete for the planned 50% completion point in the Work Package. The Estimate to Complete is now 50% - the other 5 drawings – and with the past performance of “on time,” you can naively assume you’ll get the next 5 at COB next Friday.
It may serve you better if you went to visit the drafting department over lunch on Wednesday to see if 2 ½ drawings are done – this answers the question how long are you willing to wait before you find out you’re late?
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
42/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
In the file that contains all the project
information, we need to write down
what these success criteria or exit
criteria are, so no one forgets what we
agreed to when we planned out the
Work Packages.
The term “earned value method” is on
this slide and we haven’t mentioned its
use – and we won’t go there for now.
But EV is a critically important
measurement tool for any type of
project.
This is a topic for another workshop,
but I want to plant the seed around
EV.
EV measures physical percent
complete against planned percent
complete in ways no other project
management performance
measurement process can.
Agile’s story points are Uncalibrated,
Lean and Critical Chain’s “value flow”
is Uncalibrated.
EV measures progress to plan in units
of “money.” And money is what project
management is all about.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
43/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
So let’s see if we can come up with
some performance measures for our
toaster.
If we pretend we’re not going to use
Earned Value, what would be some
good measures of performance for our
Work Packages?
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
44/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
We’ve got Work Packages, we’ve got
period of performance, budget
spreads, and the performance
measures.
We’ve got the Work Packages
arranged in a logical sequence –
maybe not the final sequence, but one
that we can live with for now.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
45/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
So why all these words about “setting
the baseline?”
The baseline is the “contract” between
the people doing the work, the people
managing the work, and the people
receiving the results of that work.
It is a “contract” about “how long,”
“how much,” “when,” sometimes “why,”
and most importantly “what.”
It’s an agreement of how to get to
DONE.
Like all good agreements, making
changes to the agreement is only done
with the full consent of all the parties
involved.
So where do we go to look at what we
agreed to?
The Baseline.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
46/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Setting the baseline is a document
management and control process.
Version numbers, safe locations, public
evidence in the form of a drawing on
the wall – “The Wall of Truth,” is a
common phrase.
The baseline becomes the “information
radiator” for the project.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
47/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
OK, let’s take a breather here.
We’ve got our Performance
Measurement Baseline, assembled
from the Work Packages.
Each Work Package as a credible
budget spread, period of
performance, predecessors and
successors, and all the other attributes
of a Good work package.
These Work Packages are sequenced
in some logical – emphasize logical –
order so we have some credibility
when we say we can get this project
done on or before a date, for some
cost or less, and it will meet the
specifications within some statistical
tolerance.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
48/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
But just because we have all this stuff
arranged in a credible sequence,
doesn’t mean the project is credible
itself.
We need to assess the credibility of
the Plan, the Schedule, the Cost
estimates, and all the other attributes
of the Performance Measurement
Baseline.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
49/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
We need to ask a few questions.
Do the estimates for labor make
sense?
Do we have the right people filling
these roles?
Can we see the “flow of work,”
connected to the “flow of value” to the
customer?
This is starting to sound like an Agile
project, but we’re not there yet.
The paradigm I’d like to introduce is
the one used in the Integrated Master
Plan / Integrated Master Schedule
world of large mission critical projects.
It starts with defining how progress is
made and measured in units
meaningful to the customer.
What are these units?
They have to be a provided capability
to do something with the product or
service.
They have to be business capabilities.
They have to define outcomes that
support the business or “mission.”
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
50/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Here’s an approach that is derived
from the “big time defense” projects
applied to an ERP project in the health
insurance domain.
This is a picture of the “value flow” of
the project. Each circle is a “join up”
point where some form of a usable
capability is available.
In the defense and space domain this
is where the project can be canceled
and the government can received
some form of value.
In the commercial domain this is where
the business can put something to work.
It is not a partial capability, it is a fully
formed capability.
You can go back to work, and rarely
have someone come back and make
changes to the “thing” that is working.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
51/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
So now we’re back to the credibility
issue.
This is really a conversation about the
schedule and cost.
It sounds rude to ask “is your schedule
credible?” But it is exactly how we
want to talk. Because it is all about the
schedule, and the cost, and the
technical performance measures.
It’s all about the project. The people,
the processes, and the tools contribute
of course.
But the customer didn’t pay for that.
they may not even care.
They want the outcomes of the project.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
52/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
So what does credible mean?
It’s simple.
Credible means it’s believable.
“What is the truth,” is the question
about credible.
Here’s some attributes of credible.
We know the critical path. I know
the critical path can change every
day at the lowest level. But at the
highest level there is a consistent
path through the network of Work
Packages that is the shortest path –
the critical path.
Are our estimates “accurate” to some
measure of confidence. It does no
good to state a number without a
variance.?
Do we know about the past
variances.? Are we using this
information to forecast future
variances?
Do we know about the “what if’s?”
Do we have mitigation or retirement
plans for all those “what if’s” and
risks?
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
53/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
So in the end it comes down to risk
management.
Credibility means you’ve got your
hands wrapped around the risks.
Tim Lister’s quote:
Risk Management is How Adults
Manage Projects
is just as important today as it was
decades ago when he first used it.
Project management is about risk
management.
Here’s a simple risk management flow
model.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
54/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
When we speak about risk, we need
to speak in this grammar.
Why, because risk management is one
of those processes that gets less
attention than it needs and has more
impact than anyone understands.
So like talking to teenagers, we need
clear, concise, unambiguous, succinct,
and short words.
DO YOU UNDERSTAND WHAT I AM
SAYING????
There are some common mistakes in
this grammar:
We often confuse issues with risk.
Issues are risks that have come true.
We rarely connect the identification
and management of risk in the
schedule.
We rarely make adjustments to the
cost and schedule for the risks. We
list them, but where can we find the
“response” to these risks in the
planning and management
processes?
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
55/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
So now that we’ve done a few
exercises and come up with the raw
material of the Performance
Measurement Baseline, here’s a picture
of a notional Work Package with all
the parts connected.
We have a Master Schedule, we have
risk adjusted durations, we can show
deliverables and outcomes, and its all
in one place.
This picture connects cost, schedule,
and technical performance measures in
one place.
If you were at the other PMI
symposium you saw a picture of
Charles Ponzi.
Making trades between cost, schedule
and the technical performance
measures without impacts all of them is
a Ponzi scheme.
It can’t be done.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
56/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Here’s one reason why.
If we have no schedule margin, we’re
late before we start.
If we have no cost margin, we’re over
budget before we start.
We must have margin for cost,
schedule, and the technical
performance boundaries.
Here’s a short discussion of what to do
with this margin when we have it.
And have it we must.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
57/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Here’s why we MUST have it.
All the variables in a project are
random variables.
These series of random variables are
coupled together in an activity
network.
These are called stochastic networks.
There is a vast body of knowledge
about these stochastic networks, that is
entering the project management
domain.
This goes to the temperature in Cody
Wyoming and Trinidad paradigm.
Don’t make decisions without knowing
the variance of the variables you’re
using as decision data.
The most recurring temperature in
Cody and Trinidad are pretty close.
Without knowing the variance, don’t
come to Cody in the winter in your
shorts.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
58/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
We’re almost done, and we should be
right on schedule, on budget and on
the planned value.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
59/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
I want to leave you with some thoughts
that are derived from this work shop.
Schedule is King.
Period.
We can usually find more money to
cover our budget overages.
We can never find more time unless
we slip the end date.
To “attack” the schedule, we need to
answer the question, how long are we
willing to wait before we find out
we’re late?
Then measure progress to plan in
periods short enough to make
corrections to the schedule so you’re
not late.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
60/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Thank you for investing your time
today.
With the time we have left, let’s open
this up to questions.
If we run out of time, please drop a
card with my colleague and we’ll
make direct contact.
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
61/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved
Here’s my contact information if you
have any questions later, want a soft
copy of this presentation with the
speaker notes, or any other items
Fort Worth PMI SymposiumJuly 15th and 16th, 2010
62/62Copyright ©, 2010, Lewis & Fowler, All Rights Reserved