Establishing the performance measurement baseline (pmi fort worth)(v4)

Fort Worth PMI Symposium
July 15th and 16th, 2010

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.

Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 1/62


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


July 15th and 16th, 2010 Here’s how we are going to build our
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.


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



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.


July 15th and 16th, 2010 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.



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.


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

July 15th and 16th, 2010 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.



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.


Here’s a “notional” starting point.
We have a business need, that was
provided prior to establishing the
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.



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.



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.



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.



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.


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.


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.


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.



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.



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.


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.


July 15th and 16th, 2010 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.


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.



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.



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



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.


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.



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



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.


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.



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.


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.



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.


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.



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.



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.



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.



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.



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.



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.


July 15th and 16th, 2010 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?



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.


Establishing the performance measurement baseline (pmi fort worth)(v4)

Establishing the performance measurement baseline (pmi fort worth)(v4)

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Semelhante a Establishing the performance measurement baseline (pmi fort worth)(v4)

Semelhante a Establishing the performance measurement baseline (pmi fort worth)(v4) (20)

Mais de Glen Alleman

Mais de Glen Alleman (20)

Último

Último (20)

Establishing the performance measurement baseline (pmi fort worth)(v4)