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


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.



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.



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

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.



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.



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.



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?



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.



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.



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.



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.



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.



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



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.



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.



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?



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.



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?



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.



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.



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.



We’re almost done, and we should be

right on schedule, on budget and on

the planned value.



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.



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.



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



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

Technology

term baseline

toscheduled work

work neededto

fort worth pmi symposium

technical baseline

thecost baseline

lewis fowler

work breakdown structure