Immutable principles of project management (fw pmi)(v4)

I’d like to thank you for inviting me to

speak at your workshop.

My contribution to this topic is from the

point of view of a program controls

manager in the aerospace and defense

business.

The programs we work are software

intensive, but not in the way commercial

software projects are.

The software on our programs is

embedded in other systems – avionics,

flight controls, ground management

systems of aircraft and spacecraft.

Other parts of our firm work programs

for commercial enterprise IT.

The principles I’m going to introduce you

to today are applicable to all projects no

matter the domain or the context in that

domain.

From software, COTS IT, construction, any

project where the outcome is critical to

the success of the participants.

The 5 Immutable Principles of Project Management 1/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved

There are three outcomes for this talk.

1. I’m going the suggest there is common

misunderstanding that software

development and project

management are the same thing.

2. There are 5 irreducible principles for

managing any project, no matter the

domain or the context.

3. And, as software developers, along

with the project manager, if you are

not answering the questions from

these irreducible principles, you’re

probably doing project management

and your project is in jeopardy and

you may not know it.



We’ve all seen the numbers.

We’ve all been told how bad things are.

77% of project failures are due to poor

planning or poor project management.

Here’s one more look.

But we’re here to work on only one of the

aspects of the “money flushing” part of

your project activity

We’re here today to talk about the

project management aspects of projects.

The planning, scheduling, costing,

management verbs of projects.

These are called the Programmatic

Elements of the project. Versus the

technological aspects.

As a program manager I’m very

interested in the technology. But my job is

to make sure the programmatic aspects

work, so the technology has a chance of

actually showing up on time.



So first let’s review what is a project.

It’s a one off event. It’s not operations. It’s

not repeatable processes – although the

processes that manage projects are

repeatable, the project itself is a one

time occurrence.

The reason this is important is that

projects are a “one chance to get it right”

type of endeavor. Operations has

several chances to get it right. Maybe a

lot of chances. Sometimes only a few. But

never just one.

Now there is another word here –

probability.

Projects have a probability of success.

There is no guarantee. We’d like this

probability to be as high as possible. For

some projects the probability is high –

close to 100%. For some projects the

probability, while acceptable, is actually

low.

There is 1 chance in 149 of losing the

mission for the Orion Manned Spaceflight

program with specific types of launch

vehicles.

What’s the probability of having your

Enterprise ERP project rollout fail in a

way that causes an unrecoverable loss to

your company? Good question.

How can you improve the probability of

success for your project? Another good

question.



Mr. Blaise’s quote is applicable to almost

every major project we’ve encountered.

It’s sad but true that we simply don’t

know how to stop work once we’ve

started.

The work shop today is not about that

decision though.

It’s about applying the principles of

project management, so we don’t have to

treat projects in such a “black and white”

manner.



Management is a verb.

When applied to an object, like a

project, this verb is the actions needed to

control and guide the development of the

outcomes of the project.

No matter what your approach, self

guided or all the way to formal project

management methods, projects need a

framework in which to make progress.

The definitions here define the

boundaries of the processes applied to

the project.



When we put these terms together we

arrive at the basis of today's work shop.

We need knowledge, skills, tools, and

techniques in order to increase our

Probability of Project Success (PoPS).

The five (5) immutable project

management principles are independent

of all these things.

At the same time they apply to any and

all these things.

And finally they are independent of any

project domain and any context in that

domain.

With the concept of Project +

Management in hand, let’s look at the

domain and context in those domains for

applying this verb and noun.



The notion of simplicity has entered the

discussion around project management

methods, tools, processes, and other

elements.

On one end we have Leonardo’s quote

about simplicity being the ultimate

sophistication.

On the other we have Mencken’s

reminder that complex problems and

their solutions are connected in ways we

may not actually understand.

Searching for simplicity in the absence of

understanding the “system” usually leads

to disappointment.

When we’re walking through our

immutable principles today, let’s keep in

mind the connection between simplicity

and complexity and the solutions we

need to address this complexity.



Here’s an idea that we don’t always

consider upfront when we look for

processes and principles.

The amount of risk a project can tolerate

is directly related to the business domain

and the context of the project within that

domain.

Understanding the tolerance for these risk

levels are critical to choosing and

applying any software development

method.

However, the five immutable principles

presented here are juts that, immutable.

They must be present in some form no

matter the product development method,

the level of risk tolerance of the domain

and the context within that domain.

The risk tolerance for cost is defined as

the ability for the customer to absorb

changes in the planned cost through

management reserve and the application

of additional funds.

The risk tolerance for schedule slippage is

defined as the ability to still produce

value for the customer in the presence of

a late or slipping schedule.

The risk tolerance for Technical

Performance means the customer is willing

to accept technical capabilities that are

less than planned.

With this background, let’s look at the

five (5) immutable principles.



The five immutable principles of project

management are:

1. Know where you are going by

defining “done” at some point in the

future. This point may be far in the

future – months or years from now. Or

closer in the future days or weeks from

now.

2. Have some kind of plan to get to

where you are going. This plan can be

simple or it can be complex. The

fidelity of the plan depends on the

tolerance for risk by the users of the

plan.

3. Understand the resources needed to

execute the plan. How much time and

money is needed to reach the

destination. This can be fixed or it can

be variable.

4. Identify the impediments to progress

along the way to the destination.

Have some means of removing,

avoiding, or ignoring these

impediments.

5. Have some way to measure your

planned progress, not just your

progress. Progress to Plan must be

measured in units of physical percent

complete.



When we confuse product development

with project management, we’ve missed

answering the 5 immutable principles

questions.

We skipped directly to the “doing” part

of the project.

The “managing of the doing” is not the

same as the “doing.”

Both are needed of course.

If we only have the “doing” part, then the

project is guided by the immediate

outcomes of the development process.

The project outcomes “emerge” as it

progresses. This is the basis of some forms

of Agile. There may be broader goals,

but the development team only responds

to the “next” increment.

Many projects are successful applying

this product development method as a

replacement for project management.

The other approach – and this is a

context sensitive approach – is to define

the needed capabilities, the requirements

needed to fulfill those capabilities, and

the work plan to make those requirements

appear.

This does not mean the fidelity of the

requirements is complete. Some could be

vague, some could be altered as we

proceed. But the end-to-end goal is

defined with enough fidelity to assure the

customer we understand what DONE

looks like.

11


Our first step here is to separate a Plan

from a Schedule.

The PLAN is a procedure used to achieve

an objective. It is a set of intended

actions, through which one expects to

achieve a goal.

The SCHEDULE is the sequence of these

intended actions, needed to implement

the PLAN.

But we don’t what to mix the PLAN with

the SCHEDULE.

The PLAN is the strategy for the successful

completion of the project.

In the strategic planning domain, a PLAN

is a hypothesis that needs to be tested

along the way to confirm we’re headed.

The SCHEDULE is the order of the work to

execute the PLAN.

We need both. PLANS without

SCHEDULES are not executable.

SCHEDULES without PLANS have no

stated mission, vision, or description of

success other than the execution of the

work.



When we say “where are we going,” we

should be talking about physical

outcomes – the deliverables.

When we say deliverables, what

deliverables are we talking about?

The deliverables should be those that

fulfill the requirements.

So what are the requirements?

As our quote says here, the single hardest

part of building a system is deciding

what to build.

No matter what method you use to make

these decisions – from the agilest of

methods to the most formal, we need to

have the requirements stated in a form

that is testable, verifiable, and traceable

to the PLAN and SCHEDULE.



Here’s some words that we’ll encounter

during the development of requirements.

These are not the only words of course,

but these words are important ones.

One critical set of words are “Stated”

versus “Real.” Stated requirements are

any requirement that is written down –

that is stated. “Real” requirements are of

course requirements that are really

needed by the system to fulfill its business

case.

Other words are important as well.

“Verified” and “Validated” are a pair.

One of the requirements words that

causes much extra work is “derived.” A

derived requirement is one that is not

primary, but is secondary. As such it may

not be obvious that it is a requirement.

There are requirements words that should

be avoided. The first one – that may not

be obvious – is “Customer.” Which

customer? How do we know what the

customer wants? One simple way out of

this is to state the requirement, that we

think is a customer requirement, in terms

of a business requirement. Complete with

a business reason, business case, business

payback, other business reasons.

Of course there are phrases that should

be avoided as well. “User Friendly” has

started to be purged from the

vocabulary – at long last. But “flexible”

and “reliable” are still hanging around.



The key here is that requirements tell us something about where we are going.

But requirements come in all shapes and sizes.

Here’s a sample of two extremes.

A small project and a not-small project.

The small project is straight forward in terms of requirements. There is a list of them on the flip chart. They are likely well understood. They probably can be estimated in terms of cost and schedule. And most importantly the interactions between the requirements can be intuited with a little effort.

The project on the right is a different class of effort. This is the top level components (if you can call them that) of the Future Combat System. It’s a $35B, that’s billion with a B program to restructure the entire US Army Battle Space Management processes.

I help one of the teams – the Class I team – build their Performance Measurement Baseline and get that information into a cost and schedule management system, so they can use Earned Value Management to “manage” their program.

FCS is a software intensive system, where software is in everything from small hand held devices to major facilities housing the “battle space management command.”

If the software doesn’t work, the FCS doesn’t work. Soldiers can’t do their job. If soldiers can’t do their job – there’s a BIG PROBLEM.



Let’s start our exercise with a topic that

should be familiar to you – flying to the

moon.

We flown to the moon and returned

safely before.

It can’t be that hard.

Yea right.

We’ll use the current moon mission as a

framework to ask and answer the

questions posed by the five (5) immutable

principles.



For the moment, let’s use a simpler

analogy to connect with something more

tangible.

Let’s pretend we want to go on a hike. A

nice hike to the saddle just to the right of

the peak above this lake. That saddle is

Pawnee Pass. It’s just west of Boulder

Colorado, and a bit south of Rocky

Mountain National Park.

We’d like to go to Pawnee Pass in a

single day – there and back. Not get too

wet if it rains. Not be too hungry. And

have a good time along the way with our

hiking group.

That’s our mission.



These two words should be tattooed on

your wrist.

If we don’t have a Plan, our schedule is

not credible. Plans are not Schedules.

And Schedules are not Plans.

A Plan is the Strategy for the successful

delivery of the project. Plans state “what”

is to be done (programmatically what,

not technically what). Schedules state

“how” it is to be done –

programmatically how it is to be done.

While this may seem subtle or maybe not

even useful, it is critically important for

several reasons:

The plan shows how the project

produces increasing value and

increasing maturity of the products.

It’s is the “road map” from the

beginning to end, INDEPENDENT from

the actual durations of the work.

The Plan speaks to What we are

doing.

The schedule is the “driving instructions”

for the vehicles on the roads, following

the map.

The execution of the schedule is the

actual “driving” of the vehicle by the

driver along with the passengers.

All three are needed, no one can be

missing, all three interact with each other.



Plans are strategies. They tell us the flow of

the project in terms of deliverables and the

increasing value and maturity of those

deliverables. I’m going to introduce some new

words here that we’ll use later. They are just

words for now, so their exact meaning is not

important.

This is similar to the Value Stream Map found

in Lean Six Sigma.

The “map” is the flow of the Significant

Accomplishments in the project or program.

For these Accomplishments, there are a set of

Criteria that define the “exit conditions” for

the underlying work. Defining these criteria

BEFORE defining the details of the work is the

basis of the Planning process.

This is a top down-first approach . It is NOT a

Top Down only approach, just the 1st step in

the process. But with the Accomplishments and

the Criteria defined, there is a notional view

of what “done” looks like. Measureable in

some units meaningful to the project

management team and the stakeholders in

the project.

This focus on the definition of “done” is

important for several reasons:

1. “Done” is a measure of 100% done, not

partially done, not almost done. But

DONE. This is the concept of “starting

with the end in mind,” popularized by

Covey.

2. Along the way to DONE, there are

measures of “getting to done” that are

“mini-dones.” These “maturity assessment

points” are the way to measure physical

percent complete in terms of the product

maturity rather than the consumption of

resources or passage of time.



Now that we know about the existence of

a Plan, what is the Schedule? Why is it

different from a Plan?

The Schedule shows the work needed to

produce the “deliverables” in the Plan.

This sounds like a tautology – a statement

of the obvious.

But there’s more to it than that.

This work is ONLY the work needed to

cause the “exit criteria” to appear of

each individual definition of the criteria

for named Accomplishment.

In a previous slide we mentioned the

definition of the Accomplishments come

first. With these definitions – and most

importantly the order in which these

Accomplishments must be accomplished

I know this is not as clear as you’d expect

at this point.

But we’ll need to use an example before

we get back to the details.

For now think of the schedule as the

description of how the individual Exit

Criteria from the “lumps of work” are to

be accomplished.



Now that we know where we want to go, the next question is how to get there.

How do we build the products or provide the services needed to reach the end of our project.

There are numerous choices, depending on the domain and the context of the project in that domain.

For the software domain there are many context’s. Using the example on the previous page, let’s look at two methods. These are the extreme ends of the spectrum of contexts and methods. They can serve to focus the discussion on project management rather than product development methods, by hopefully disconnecting project management from product development so we can look at them separately.

In the first software development context – a list of features, SCRUM is a popular approach.

But there are many more software based project, possibly more complex than the example from the previous page to the “wickedly” complex program also shown on the previous page.

The SCRUM method is shown in its common diagram. But below it is the method used for product procurement in the US Department of Defense – DoD 5000.02. The products are not actually developed by the DoD (except in rare cases). But are instead, procured. So acquisition management is guided by this process.

Both are iterative, both are incremental, both can deal with emerging requirements, both make use of “test driven planning,” and both have clear and concise measures of physical percent complete.



Know that we know something about our

“mission,” “vision” – going to the moon,

let’s see if we can answer the question of

“how” do we get there?



Now that we know some things about

what capabilities we need and how we

might cause these capabilities to appear

at the appointed time and place for the

planned cost and schedule, do we know

what we need to be successful?

We need to constantly ask this question.

If we don’t ask and answer the question,

we’ll find out what is missing when they

arrive on our doorstep.

At that point it will be too late. It is not

too late to acquire them, but too late to

acquire them within our planned schedule

and planned budget.



Now that we know where we’re going

and how to get there – do we have all

we need to reach the end?

Staff, time, money, the necessary skill and

experience and the proper management

support.

These are all obvious on any project – at

least any well managed project.

But there are always underlying issues

with answering these questions.

The first is that management as well as

the development organization are

always optimistic about the outcome. This

is the very nature of project

management. Why be pessimistic?

Well maybe not pessimistic, but how

about realistic? What do we mean when

we say realistic? One good word is

credible. Credible could be optimistically

credible or pessimistically credible. But

either way we have a credible

understanding of what it takes to reach

the end.

One part of credible is knowing what the

risks and uncertainties are and how we

are going to dealing with them.

Managing in the Presence of these

uncertainties is critical to reaching our

goal. Risk and uncertainty never go

away. They are always there. They are

unavoidable.



Once we recognize that time is not money

and money is not time, the next eye

opener for all project work is there is a

natural statistical variability of both these

elements.

So no matter what software development

method you are applying inside a project

management set of processes, you must

come to grips with the statistical nature of

cost, schedule, and technical

performance.

This area is called Programmatic Risk and

its cousin Technical Risk.

The Programmatic Risk concept is not well

understood outside the defense and

space business. There it is mandated that

Programmatic Risk be managed – DID

81650 describes this mandate.

The Monte Carlo simulation method is the

way to assess the behavior of the

network of activities, but there subtleties

beyond just the simulation of the network.

The Monte Carlo tools don’t easily model

the coupling and correlations between

the work activities in a proactive manner.

There are other tools for modeling the

network, but they are also outside this

presentation.



So let’s see if we can gather everything

we need for our project.



Project Managers constantly seek ways to eliminate or control risk, variance, and uncertainty. This is a hopeless pursuit.

Managing “in the presence” of risk, variance and uncertainty is the key to success. Some projects have few uncertainties –only the complexity of tasks and relationships is important – but most projects are characterized by several types of uncertainty.

Although each uncertainty type is distinct, a single project may encounter some combination of four types:

1. Variation – comes from many small influences and yields a range of values on a particular activity. Attempting to control these variances outside their natural boundaries is a waste (Muda).

2. Foreseen Uncertainty – are uncertainties identifiable and understood influences that the team cannot be sure will occur. There needs to be a mitigation plan for these foreseen uncertainties.

3. Unforeseen Uncertainty – is uncertainty that can’t be identified during project planning. When these occur, a new plan is needed.

4. Chaos – appears in the presence of “unknown unknowns.”

“Managing Project Uncertainty: From Variation to Chaos,” Arnoud De Meyer, Christoph H. Loch and Michael T. Pich, MIT Sloan Management Review, Winter 2000.



Project duration and costs are random

variables drawn from some underlying

probability distribution.

In probability theory, every random

variable is attributed to a probability

distribution.

The probability distribution associated

with a cost or duration describes the

variance of these random variables.

A common distribution of probabilistic

estimates for cost and schedule random

variables is the Triangle Distribution.

Using the Triangle Distribution for the

costs and durations, a Monte Carlo

simulation of the network of activities and

their costs can be performed.

Monte Carlo methods are used to numerically transform and integrate the posterior quantitative risk assessment into a confidence interval.

The result is a “confidence” model for the

cost and completion times for the project

based on the upper and lower bounds of

each distribution assigned to each

duration and cost.



If risk management is how adults manage projects, here are some principles of project risk management.

These five principles are simple, obvious, but difficult to implement. This reason they’re difficult is that most people shy away from risk. Managing in the presence of risk does not come naturally.

It is a learned behavior. And once learned it has to be practiced. But before it can be learned and then practiced, “managing in the presence of risk,” must become part of the business culture.

Some cultures doe this better than others. NASA is probably better than others. But even NASA has moved a risk adverse culture in the past decades.

1. Hoping that something positive will result is not a very good strategy. Preparing for success is the basis of success.

2. Single point estimates are no better than 50/50 guesses in the absence of knowledge of the standard deviation of the underlying distribution.

3. Without connecting cost, schedule, and technical performance of the effort to produce the product or service, the connection to value cannot be made.

4. Risk management is not an ad hoc process that you can make up as you go. A formal foundation for risk management is needed.

5. Identifying risks without communicating them is a waste of time.



Project Managers constantly seek ways to eliminate or control risk, variance and uncertainly. This is a hopeless pursuit.

Managing “in the presence” of risk, variance and uncertainty is the key to success. Some projects have few uncertainties –only the complexity of tasks and relationships is important – but most projects are characterized by several types of uncertainty. Although each uncertainty type is distinct, a single project may encounter some combination of four types:

1. Variation – comes from many small influences and yields a range of values on a particular activity. Attempting to control these variances outside their natural boundaries is a waste (Muda).

2. Foreseen Uncertainty – are uncertainties identifiable and understood influences that the team cannot be sure will occur. There needs to be a mitigation plan for these foreseen uncertainties.

3. Unforeseen Uncertainty – is uncertainty that can’t be identified during project planning. When these occur, a new plan is needed.

4. Chaos – appears in the presence of “unknown unknowns.”

“Managing Project Uncertainty: From Variation to Chaos,” Arnoud De Meyer, Christoph H. Loch and Michael T. Pich, MIT Sloan Management Review, Winter 2000.



The use of point estimates for durations

and costs is many times the first impulse in

an organization low on the project

management maturity scale.

Understanding cost and durations are

actually “random variables,” drawn from

an underlying distribution of possible

value is the starting point for managing in

the presence of uncertainty.

The Triangle Distribution is used as a

subjective description of a population for

which there is only limited sample data,

and especially where the relationship

between variables is known but data is

scarce. It is based on the knowledge of

the minimum and maximum and a “best

guess” of the modal value (the Most

Likely).

Using the Triangle Distribution for the

costs and durations, a Monte Carlo

simulation of the network of activities and

their costs can be performed. Monte

Carlo methods are used to numerically

transform and integrate the posterior

quantitative risk assessment into a

confidence interval. The result is a

“confidence” model for the cost and

completion times for the project based on

the upper and lower bounds of each

distribution assigned to each duration

and cost.

This approach to estimating provides

insight into the behavior of the plan as

well as sensitivity between the individual

elements of the plan.



In many descriptions of project

management – cost, schedule, and quality

are considered as the “Iron Triangle.”

Change one and the other two must

change as well. It turns out this is too

narrow a view of what's happening on a

project.

It’s the Technical Performance

Measurement that replaces Quality.

Quality is one of the Technical

Performance measures.

Technical Performance Measures describe

the status of technical achievement of the

project at any point in time.

The Planned technical achievement is part

of the Performance Measurement

Baseline (PMB) in the same way the

Planned Value (BCWS) is part of the

PMB.

The TPMs use the techniques of risk

analysis and probability to give program

managers the early warning needed to

avoid unplanned costs and slippage in

schedule. Systems engineering uses

technical performance measurements to

balance cost, schedule, and performance

throughout the life cycle.

TPMs compare actual versus planned

technical development and design. They

also report the degree to which system

requirements are met in terms of

performance, cost, schedule, and

progress in implementing risk handling.



Risk Management means using a proven

risk management process, adapting this

to the project environment, and using this

process for everyday decision making.

Technical performance is a concept

absent from the traditional approaches

to risk management. Yet it is the primary

driver of risk in many technology

intensive projects.

Cost growth and schedule slippage often

occur when unrealistically high levels of

performance are required and little

flexibility is provided to degrade

performance during the course of the

program. Quality is often a cause rather

than an impact to the program and can

generally be broken down into Cost,

Performance, and Schedule components.

The framework shown here provides:

Risk management policy.

Risk management structure.

Risk Management Process Model.

Organizational and behavioral

considerations for implementing risk

management.

The performance dimension of

consequence of occurrence.

The performance dimension of Monte

Carlo simulation modeling.

A structured approach for developing

a risk handling strategy.



It does no good to manage risks if the

results are not communicated to all the

participants.

Risk communication is the basis of risk

mitigation.

This plan needs to address the following:

Executive summary – a simple summary

of the program and the risks

associated with the activities of the

program. Each risk needs an ordinal

rank, a planned mitigation if the risk is

active (a risk approved by the Risk

Board), and the mitigations shown in

the schedule with associated costs.

Program description – a detailed

description of the program and the risk

associated with each of the

deliverables. This description should be

“operational” in nature, with the

consequences description in

“operational” terms as well.

Risk reduction activities by phase –

using some formal risk management

process that connects risk, mitigation

and the Master Schedule. The efforts

for mitigation need to be in the

schedule.

Risk management methodology – using

the DoD Risk Management process is a

good start. This approach has proven

and approved by high risk, high

reward programs. The steps in the

processes are not optional and should

be executed for ALL risk processes.



Risk Management is a full time effort.

Even if it is a part-time job.

Someone needs to “own” the risks and the

process around risk management.

Someone or a collection of “someone's”

needs to have risk management in their

mind(s) at all times.

Risk Management is not something you

can do once and them forget. The risks

don’t just go away.

They are forever there, even if they are

mitigated, retired or bought down.



When we ignore the fundamental

statistical nature of project work, we are

creating risk.

This risk comes not from the underlying

probabilities, but from our ignorance of

this process.

We believe, wrongly, that our estimates

are static point values – a single number

representing the estimate. We fail to

take into account the statistical processes

that drive this number.

Durations, costs, technical performance.

When we fail to make these variances

visible we are managing our project with

a “head in the sand,” just like this guy.


36/62

Many speak about risk management as

part of the project management process.

But do they do risk management as part

of the project management process?

Test yourself and anyone who claims to

be doing risk management



So let’s look for some impediments in our

project to fly to the moon.

There are many of course, but let’s see if

we can come up with some that are not so

obvious.



Measures of progress are one of the

difficult topics in project management.

Typically we measure progress by the

consumption of resources and the

passage of time.

We talk about “budget,” being “on

budget,” being “over budget.”

We talk about the passage of time.

“We’re on schedule,” “we’re late,” “our

schedule is slipping.”

These are all necessary things to talk

about. But they are not sufficient for our

project’s success.



Performance measurement is the

comparison of actual performance

against an integrated baseline plan

consisting of integrated cost, schedule

and technical goals. The baseline used

for performance measurement should be

a single, integrated plan, because the

analysis of cost performance must include

schedule considerations and the

evaluation of schedule performance must

include technical performance

considerations.

Given a project where some tasks are on

schedule, some are ahead of schedule

and some are behind schedule, overall

project status is virtually impossible to

determine. It is no wonder that many

project managers are literally “flying by

the seat of their pants” without a good

feel for where the project stands at any

given point in time.

A systematic, organized process for

collecting performance information and

presenting it in a clear manner on a

regular basis is essential to the project

management process.



With the information from the previous 4 irreducible principles, we now need to confirm we are making progress. The key principle here is “planned progress.” We must pre-define what progress we must make at any specific point in the project, otherwise all we can determine is the passage of time and the consumption of money. Preplanning the progress is the basis of “performance based” measurement for both project processes and technical products.

Like Kent Beck’s (eXtreme Programming) advice we need feedback on our progress.

There is only one kind of feedback for projects – measures of physical percent complete.

No soft touchy feely measures of progress. No hand waving measures. Physical, tangible evidence of progress.

Something that can be physically shown to the customer. Something that is compliant with the planned technical outcomes at this point in the plan.

Scrum does this by predefining the outcomes of the iteration. DoD 5000.02 does this as well with the Integrated Master Plan and Integrated Master Schedule.

So looking at two extremes of the spectrum – one a software development method and the other a mega-program procurement method. Both share the same principles and outcomes. Something that is tangible and measurable at incremental steps along the way to “done.”



For successful measurement of progress in

a project we need to have:

Tangible evidentiary materials

measure progress to plan.

Pre–defined existence of this evidence

in meaningful units of measure

established before starting work.

Progress is defined in these same units

of measure.



There are many opinions about

measuring progress to plan.

Here’s what some authors have said.



Let’s talk a bit about a common fallacy in

the project management world.

The notion of the “iron triangle” has fallen

into disrepute lately.

We all should know about the iron

triangle. It connects cost, schedule, and

quality – or some 3rd element in place of

quality.

Actually the variable in place of quality

is “Technical Performance Measures”

(TPM).



Technical Performance Measurement (TPM) is a technique for predicting the future value of a key technical performance parameter of the higher-level product based on current assessments of products lower in the system structure.

Continuous verification of actual versus anticipated achievement of technical parameters confirms progress and identifies variances that might jeopardize meeting a higher-level end product requirement.

Assessed values falling outside established tolerances indicate the need for management attention and corrective action. A well thought out TPM program provides early warning of technical problems, supports assessments of the extent to which operational requirements will be met.

When we say “project management” we

have to say “management” in terms of

measuring progress to plan.

The question is how to measure progress

to plan?

How do we define what the planned

progress “should” be, what actual

progress we made to date, and how

much work there is to go?

With the remaining progress to go, what

should or pace be to arrive at the end of

the project at the planned time?



Pulling essential cost, schedule and

technical performance information

together in a meaningful, coherent

fashion is always a challenge facing the

project manager.

If this cannot be done, management

information will be fragmented, will not

contribute effectively to project

management, and may actually mislead

the manager by presenting a distorted

view of project status.





and technical goals.

The baseline used for performance

measurement should be a single,

integrated plan because the analysis of

cost performance must include schedule

considerations and the evaluation of

schedule performance must include

technical performance considerations.

Performance measurement is the art of

determining, organizing, and presenting

cost, schedule and technical performance

information in a way that contributes to

making those tradeoffs. It is a systematic,

organized process for collecting

performance information and presenting

it in a clear manner on a regular basis.



We hopefully have all heard the term

“earned value,” and maybe even seen

the term in use.

Here is the cheat sheet for the Earned

Value variables and the formulas used to

calculate the indices needed to manage

a project using Earned Value.

We won’t get into the details of EV. But

EV is one of the best measures of project

performance available.

Is straight forward to apply. Provides

credible forecasts of future performance

and has natural connections to Scrum and

some other agile software development

methods.



The use of Earned Value, Earned Value

Management, with an Earned Value

Management System connects cost and

schedule into a performance

measurement system.

The cost and schedule performance

indices are used to forecast future

program performance in the presence of

unchanged technical performance.

By using Earned Value in conjunction with

probabilistic risk analysis of cost,

schedule, and technical performance

measures, a forecast of future cost and

schedule impacts can be made.

The primary motivation for earned value

is to stimulate action on the part of the

project or program manager to make

changes that will alter the course of

performance and bring the project or

program into conformance with the value

proposition as defined in the charter.


48/62

There are some other motivations as well:

Earned Value tools help the project

manager measure and assess the

accumulation of value throughout the

project implementation.

The purpose of earned value is to give

the project manager information

sufficiently early so poor performance

can be corrected before it impacts the

value performance of the project.

Cost centric earned value systems are

robust measures of project

performance in the measurement

system are in place to provide the

necessary data for analysis.

Time centric earned value systems are

a substitute for cost centric systems

when the cost collection measures are

not available.

Managing Projects for Value, John

Goodpasture, Management Concepts,

2002.


49/62





and technical goals. The baseline used

for performance measurement should be

a single, integrated plan, because the

analysis of cost performance must include

schedule considerations and the

evaluation of schedule performance must

include technical performance

considerations.

Given a project where some tasks are on

schedule, some are ahead of schedule

and some are behind schedule, overall

project status is virtually impossible to

determine. It is no wonder that many

project managers are literally “flying by

the seat of their pants” without a good

feel for where the project stands at any

given point in time.

A systematic, organized process for

collecting performance information and

presenting it in a clear manner on a

regular basis is essential to the project

management process.



If we’re going to be successful measuring

performance of the project, we must have

tangible measures of progress.

These means the evidence must be

defined upfront, so we can recognize it

when it arrives.

If we don’t define the evidence up front,

then we fall victim to the “emergent”

measure of progress.

Or worse, progress is what we have done

this week.

The units of measure of progress must be

meaningful to the project participants.

Numbers and statement of progress are

of no value if we can’t make decisions

with this information.



When we use traditional forecasting

based on cost and schedule adherence,

we ignore the “technical performance” of

the product we’re building.

We’re on schedule, we’re on budget, the

thing we’re building doesn’t work exactly

as we had planned.

So how can we be on-schedule and on-

budget?

We can’t.

We’re driving in the rearview mirror.

This can be done, but you usually run

over something stinky.



We need a way for forecasting the

future performance of the project, from

it’s past performance. The risk adjusted

past performance.

We need to drive the car by looking out

the front windshield.

Or in this case the windshield of the

Shuttle.



So let’s look at how we can measure

progress to plan in a way that provides

us with information about the future

performance of the project.



Since we visited the principles and done

some sample exercises with the principles

to get a feel of how they could be

applied.

Now we need to connect these principles

with the practices.

Here’s some examples how to make these

connections.

1. The statement of where we are going

doesn’t have to be complex. But it

must address the details appropriate

for the problem.

2. A Master Plan and Master Schedule

show “how” we’re going to get there

on-time, on-budget, and on-

specification.

3. These Plans and Schedules, have all

the needed resources defined and

loaded into the Work Packages.

4. With this Plan and Schedule, we can

now define the risks and their

mitigations or retirement plans.

5. Finally we’ll ALWAYS measure

progress as physical percent

complete.

There, now we’ve connected principles

with practice.



Project management means being able to

state with confidence these any time

someone asks you “how are you

managing the project?”

If you cannot say this with a straight face,

then you need to take action to start to

move in that direction.



There are also a few “laws of physics”

for projects. The first is late starts mean

late finishes. If you start late you’ll likely

finish late if you don’t have schedule

margin. How much schedule margin is

needed? Good question. There are ways

to find out. Some fancy some simple. But

for sure if you have no margin and you

start late you're late.

Same goes for budget.

While we said before we need to

measure progress as physical percent

complete, the units of measure must be

meaningful to the stakeholders. As an

undergraduate physics major we used to

play a joke on our TA – which I got back

in spades a few later when I was a TA.

The joke in classical mechanics is to do all

the calculations in the right units of

measure – Standard International (SI)

units. Then convert those to olde English

measures. Volume in cubic meters can be

converted to Hogs Heads. Or kilometers

per hour to furlongs per fortnight.

So we need to consider what the

stakeholders really want to know. This

turns into a metrics problem and is

outside the scope of this brief talk, but it

must be addressed if you’re really

managing the project. But as the bullet

says – time and money – are good

starting points.

Finally a universally applicable principle

is to never confuse effort with results. The

customer paid for results.



So now we can understand that we need

all three measures

Cost, schedule, and technical

performance to establish the basis of

credibility.

Each measure must be statistically

adjusted for its particular probability

distribution.

Each measure must have a model of how

it interacts with all the other measures.

Each measure must describe the work

processes that are used to increase the

maturity and therefore the probability of

program success.

A simple static model the program is not

credible. A dynamic model is the

beginning of this credibility.



So what happens if we don’t get all these

principles put into practice.

We tried really hard, but didn’t make it.

What happens is you reduce the

Probability of Project Success (PoPS).

How much, depends on the project.

What are the impacts, depends on the

project.

But why do it.

Why not make every attempt to do it

right?



Now for questions.



So we’ve arrived at the end of our short

time here. What did we learn?

There are 5 immutable principles of

project management, no matter the

project domain and context.

We need to confirm are project is

applying these principles, and look for

the evidence in the form of practices for

each principle.

Hopefully I’ve conveyed the notion that

project management is not the same as

product development.

Both are needed, some times more than

the other depending on the context and

the domain.

If I’m building a web site I approach the

project management and development

method differently than if I’m building the

terminal guidance control software for an

autonomous Mars Lander



Here’s my contact information.

If you have questions that weren’t

answered here, would like a soft copy of

this briefing or any others from today or

last night’s PMI Chapter meeting, please

drop me a note.



Immutable principles of project management (fw pmi)(v4)

Technology

Transcript of Immutable principles of project management (fw pmi)(v4)