Immutable principles of project management

All projects are disappointments. That’s

why they call it a project. All projects

push the boundaries of schedule, cost,

and technical performance, otherwise it

would be called production.

We need to face up to this. We need to

acknowledge that projects are managed

in the presence of uncertainty.

Uncertainty drives risk. Risk drives cost,

schedule, and technical performance.

We must manage in the presence of risk.

This starts with having NO, I mean NO

surprises. Is something goes wrong that

was a surprise, a REAL surprise, them

someone didn’t do their job. A risk was

ignored. A risk was overlooked. A risk

was hiding in plain site.

Risk management is the primary role of

project management. And By The Way,

agile is not a risk management process

unless it has a risk register, a probabilistic

assessment for those risk and the impact

of those risks, and a monetized outcome

for the handling strategy for each risk in

the Risk Register.

Risk is an Uncertainty that Matters. Risk is

any uncertainty that if it occurs will affect

achievement of objectives.

The role of risk management is to reduce

or eliminate the surprise of being over

budget, behind schedule, and not have

your thing work. Risk management means

knowing bad things are going to happen

soon enough to do something about them.

The other four principals of success are in

support of risk management

Copyright ® 2012, Glen B. Alleman, All Rights Reserved

1/36

The five immutable principles of project

success 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

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. In units meaningful to the

decision makers.

The 5 Immutable Principles of Project Management 2/36


The key is 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.



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

This value and maturity is meaningful to

the business.

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.



Now that we know about the existence of

a Plan, what is the Schedule?

Why is it different from the 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.



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, is 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 deal 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.



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



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. The 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 to 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 everyone’s time.



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

And therefore a critical success factor for

the project itself.



For successful measurement of progress

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

All units of measure must be meaningful

to the decision makers.

The Technical Performance Measures

must be traceable to the requirements,

the capabilities and back to the

Measures of Effectiveness (MoE).

MoE’s are how the customer measures

progress. The customer didn’t buy the

development environment, or even the

code produced by the development

environment. The customer bought the

capabilities that the software

implements. Or any product, not just

software.

One example is the program of the

Hubble Robotic Service Mission (HRSM).

The customer Goddard Space Flight

Center bought the capability to fly to

Hubble, do not harm to the telescope,

change the Wide Field Camera, and

connect the umbilical cord of th

external batteries latched to the towel

bars on the ass end of the telescope.

That’s what done looked like, that’s

what Frank Cepollina bought for his

telescope.



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



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.

This is not always the first image of a Project Manager. Many times we think of a personnel coordinator, a facilitator, all those soft skills that are taught at the PM conferences.

But at the end of the day, the customer has little concern about that. It is assumed that all that is handled. It is considered hygiene, part of the normal operations.

The customer wants to know

When will you be done? How much will it cost? Will it work the way the customer

wants it to work? With a good plan, a schedule, a description of the needed capabilities and related requirements, the needed resources to deliver on the requirements and all the impediments to progress identified and handling plans - 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?

Without clear and concise answers to these question all the other aspects of project management are going to add little to the probability of success.

This is the source of most project failures, the dreaded Death March of Ed Yourdon.



Performance measurement is the

comparison of actual performance

against the planned performance in 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.



Project management means being able to

state with confidence these phrases 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.



OK, enough principles, let’s go to work.


19/36

All projects are over budget, behind

schedule, and many times don’t deliver

what was promised.

This is the realm of projects.

The BIG problem is when this comes as a

surprise, when it comes too late to do

anything about it, when there is no

margin for schedule slips, cost over runs,

or technical performance shortfalls.

That’s when projects should be labeled as

troubled. If you’re late but have schedule

margin and use that margin to cover the

lateness, then you’re not late.

If you’re over budget but have

contingency funds to cover your over

budget condition, then you’re not really

over budget, you just used your

contingency.

By The Way, Management Reserve is not

the same as contingency, but that is

another topic.

You’re product doesn’t meet the 90th

percentile of performance, but your

design will still function if the product

performs at the 80th percentile of the

performance band on the first release.

Without defining these margins,

contingencies, performance bands up

front, you’ll never know if you’re actually

performing well or not.

But most importantly, you don’t have a

leg to stand on with your customer when

you are actually late, over budget, and

in a performance short fall.


20/36

Here are 16 program management

processes that must be in place for any

business that depends on managing

projects for revenue generation.

For the moment we’ll only talk about 7 of

these.

Planning, measuring performance of the

Plan, requirements, finance, earned

value, scheduling and risk.

2. You need a plan to know where you

are going.

3. You need some way to measure

progress of that plan

6. Earned Value tell you how you can

measure physical percent complete

and with that forecast future

performance.

7. Requirements tell you what things you

need to produce to meet the plan.

8. You need a schedule of the work,

how it will be performed, and what

order it will be performed in.

9. Finance, so one has to fund your

project and will be asking what you

did with their money.

10. Risk is how adults manage projects


21/36

The 5 Immutable Principles of project

success are based on 5 process areas of

project management. The five process

areas are the basis of Performance

Based Management(sm), they are:

1. Identify the capabilities needed to

fulfill the mission, vision, business case,

or any other forward looking

description of the project.

2. Identify the technical and operational

requirements needed to enable the

capabilities to be fulfilled.

3. Define the cost, schedule, and

technical performance measures of

the work activities needed to

implement the requirements.

4. Determine how the work activities will

be measured to assure their planned

performance is being achieved.

5. Identify and handle the impediments

to progress for the project.


22/36

Capabilities are where the business value

is.

Capabilities drive requirements, but

rarely do requirements by themselves

have value to the business.

The business wants a capability. A

capability to do something with the

outcomes of your project. There are lots

of ways to implement a capability, so

focus first on establishing a baseline set

of capabilities before you start

developing requirements and solving the

perceived problems.

Capabilities are what you would do with

the resulting system. The business would

put it to work making money, satisfying

customers, running the business, running

the products the business produces.

If you don’t know want capabilities you

need to produce from the project, you

rally can’t talk about the business value,

and therefore you really can’t speak

about what DONE looks like in are

meaningful way other than the passage

of time and consumption of money.


23/36

The first step in identifying requirements

that fulfill the needed capabilities is to

separate “product” requirements from

“process” requirements.

The product could be a service as well,

but the product (or service) is not the

same as the process that delivers the

service that may be enabled by the

product.

We can see there are several

components of this separation.

While this type of taxonomy looks

unnecessary, later on we’ll see it can

serve to reduce complexity, focus our

efforts on important parts of

requirements management, and reduce

the overall effort of managing these

requirements.

Copyright © 2012


24/36

The Baseline of the project is actually three

baselines:

1. The technical baseline assures that all the

deliverables are identified. Even if the

details are not know, the needed

capabilities must be defined in some

meaningful manner. Otherwise the

project will have no way to control the

scope.

2. The schedule baseline says when the

needed capabilities will be available

3. The cost baseline says how much each of

these capabilities is planned to cost.


25/36

When we talk about Plans and Schedule,

we need to speak about outcomes in

terms of needed capabilities and then

speak about how we are going to

produce those outcomes through “work.”

The work that produces an outcome,

produces a “Deliverable.” A tangible

evidence that the customer has received

a capability.

This is the picture of the Integrated Master

Plan and the Integrated Master Schedule.

The Plan is needed first. It tells us what

DONE looks like in terms of capabilities.

What capabilities we’ll posses when the

project is done. Most importantly it tells

how the maturity of these capabilities

evolves over time.

The Integrated Master Schedule shows

the packages of work that must be

performed in a specific order to produce

the needed capability.

Both the Plan and the Schedule are

needed. If you have the Plan without the

schedule, then you know what done looks

like, but not how to get there.

If you have the schedule and not the Plan

you cannot determine if your work is

increasing the maturity of the desired

capabilities.


26/36

With the Work Packages defined in the

Integrated Master Schedule, shown below

the line in the previous slide, the

execution of the work is straight forward.

So simple in fact, you just have to do the

work in the order is says to do it. This

sounds too simple of course, but this is

where the Planning process pays off.

Just like an Agile development process

using sticky notes and iterations, the

project agrees what work is going to be

performed in what order – the iteration

in the example of Scrum. Work Packages

in the example here.

It turns out that formal project

management using Work Packages is

very close to Scrum in many ways.


27/36

Continuous Risk Management, when

performed successfully, provides a

number of benefits:

Prevents problems before they occur –

identifies potential risks and deals

with them when it is easier and

cheaper to do so – before they are

issues.

Improves product or service quality –

focuses on the program’s objectives

and consciously looks for things that

many effect quality throughout the

program lifecycle.

Enables better use of resources –

allows the early identification of

potential problems – proactive

management – and provides input into

management decisions regarding

resource allocation.

Promotes teamwork – involves

personnel at all levels of the program.

Copyright, Glen B. Alleman 2012


28/36

No matter what method you are using for

the management of your project,

someone outside your project has an

interest in how things are going.

This interest is usually measured in units

different from yours as a project

manager or as a developer.

Here are 11 critical activities needed to

answer almost any question from anyone

in your organization about how is it

going?


29/36

Performance Based Management(sm)

method provides the tools, processes, and

training needed to increase the

probability of success of projects.

This approach is unique in its integration

of the critical success factors for projects,

no matter the domain.

This approach answers the following 5

immutable principles:

Where are we going?

Do we have a definitive description of

the needed capabilities and the

requirements needed to deliver those

capabilities?

How do we get there?

What is the sequence of the work

efforts to achieve the plan?

Do we have enough time, resources,

and money to get there?

Are the resources properly allocated to

the sequence of work activities?

What impediments will we

encounter along the way?

Have we captured the risks and their

handling plans for all the critical work

activities?

How do we know we are making

progress?

Can we measure progress to plan in

units meaningful to the decision

makers?



30/36

Performance Based Management(sm)

method provides the tools, processes, and

training needed to increase the

probability of success of projects.

This approach is unique in its integration

of the critical success factors for projects,

no matter the domain.

This approach answers the following 5

immutable principles:

Where are we going?

Do we have a definitive description of

the needed capabilities and the

requirements needed to deliver those

capabilities?

How do we get there?

What is the sequence of the work

efforts to achieve the plan?

Do we have enough time, resources,

and money to get there?

Are the resources properly allocated to

the sequence of work activities?

What impediments will we

encounter along the way?

Have we captured the risks and their

handling plans for all the critical work

activities?

How do we know we are making

progress?

Can we measure progress to plan in

units meaningful to the decision

makers?



31/36

With the principles and practices in

place, the next step is to put them to

work on your projects.

This is a call to action.

Start with agreeing to measure all

progress to plan (you do have a plan

right) with tangible evidence of physical

percent complete.

This means the phrase show me has to be

used all the time.

You have to define what done looks like

in fine grained increments with pre-

defined units of measure. Otherwise

you’ll never recognize done when it

arrives, if it arrives.

Planning is a dynamic process that must

deal with change, emergent situations.

The planning horizon can not be further in

the future than you have capabilities to

manage. Otherwise your plan is bogus.

You need a mission and a vision of what

done looks like to guide your plan, to

anchor your efforts.

But don’t be fooled by plans that state

outcomes beyond the horizon if you

actually haven’t been beyond the horizon

to see what it looks like out there.


32/36


33/36

Now comes the part where all the soft

skills come into play.

You need to be ruthless about the 5

principles and the 5 processes, without

appearing to be ruthless.

This is where good project managers

excel.

I personally am not one of those people.

I’ve grown up in the weapons systems

business, with a prior military

background, worked on large programs

where people die if things go wrong.

Or people die when things go right

(Intercontinental Ballistic Missiles).

But in many domains, IT being one,

people skills are critically important.

But these principles and practices are

universal.

In order to make them work though, the

Project Manager must adhere to the

principles first and the practices that

result.

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




36/36

37

Here’s the five practices needed for

success with the five immutable principles.

These practices are general purpose for

all project domains and independent of

any development method.

The five principles contain the activities

needed to implement the principle. There

is of course much more detail needed. But

this is a framework and not the step by

step methods, that's several 100 ore

pages of overview.

38

Here’s the next level down of 3 more

levels.

The idea here is that increasing fidelity of

the produced outcomes requires

increasing fidelity of the processes

needed to produce those outcomes. They

go hand in hand.

For example to Identify Needed

Capabilities, you just can’t say Identify

Needed Capabilities, there are 4major

steps to do that

1. Define capabilities as operational

concepts, means a clear and concise

definition of how the capability with

be used in production. This is usually

some narrative. I want to fly to

Hubble and fix the wide field camera.

2. Then we need scenarios or use cases

describing all the activities that will

take place while using this capability.

3. Trade offs between needs, risks, and

costs have to consider all the

interactions. This is the Anlysis is

Alternative (AoA) described in

Systems Engineering.

4. Then the actual trade offs must be

performed. A trade space built where

quantitative assessment can be

performed.

39

Here’s another view of connecting

the Five Principles with the Five

Practices while building the Needed

Capabilties.

And another view.

Multiple views of the same process and

problem are always needed.

40

41

For the IT world, here’s a way to

assemble the deliverables based

planning into a business process.

42

A way to show how capabilities can

drive requirements and how

capabilities can be connected to

business benefits.

43

An example of a Product

Development Kaizan for a space

craft.

44

From the sticky note a Mind Mapping

tool is used to capture the stuff on

the wall.

From there this tool – MindJet – can

produce a schedule directly. You still

have to hook up the work, assign

durations, and resources, but the

topology of the project – the Program

Architecture is captured during the

Kaizan process.

45

Another view of a Value Stream Map,

showing how the maturity of products and

services move from left to right.

This is a picture of a Plan for the project.

This is a real project. It is a health

insurance claims processing system

integration. It shows what capabilities we

would like to have, the order of those

capabilities, the preconditions for each

capability, and the outcomes of each

capability when it is available.

This is the Integrated Master Plan.

It is NOT the Integrated Master Schedule.

But having this Plan is critical to

developing the Integrated Master

Schedule.

If you look back to the early slides in this

session you’ll see similar charts. People

standing in front of a board of sticky

notes were doing the same thing.

The process lays out the “value flow” for

the project. This is the mythical “value”

spoken about in many Agile development

processes.

We can monetize the presence of a

capability and assign that monetary

value to a section of the business case.

With this “value flow” we can identify the

needed capabilities, the technical and

operational requirements that must be in

place to enable these capabilities and

finally the “packages of work” needed to

produce the solutions that meet those

requirements.

Glen B. Alleman, PMI Mile High Symposium, 2012 46/38

Time: 00 :00 Total: 00:00

Using the topology from the previous slide, we can now see what the Plan looks like. The Data in Marts for ERP Ready is a capability needed by the business. This capability can be put to work. The business case can monetize this capability and we can connect our development efforts with the production of this monetized value. In order to arrive at this capability, we need several Significant Accomplishments:

Billing is complete.

Internal process complete.

Data store look up complete.

Data marts complete.

Portals and others complete.

Each of these Significant Accomplishments has a set of Work Packages (not shown here) that must be completed. The Exit Criteria of these Work Packages is called the Accomplishment Criteria.

The Accomplishment Criteria, Significant Accomplishments, and the Milestones or Events that release the Capability are the Integrated Master Plan (IMP).

The Work Packages and their internal Tasks, when placed in the right sequence are the Integrated Master Schedule. If we look back at the topology of the IMP and IMS, we now have the language needed to describe:

What DONE looks like?

How to get to DONE?

What resources we need on the way to DONE?

The impediments along the way?

The measures of progress to plan?

We’ll have answered the 5 immutable questions in a single integrated document – the Integrated Master Plan / Integrated Master Schedule.


Time: 00 :00 Total: 00:00

The perfect schedule has some attributes we need to understand before we start.

The schedule tells us what DONE looks like in units of measures meaningful to the decision makers. This phrase units of measure meaningful to the decision makers will be at the heart of everything we do today.

The schedule shows us what work needs to be done to produce the outcomes needed for the project to be successful. Actually it shows us the work that needs to be done that increases the probability of success for the project – since all project work is probabilistic.

The schedule shows us what resources are needed to do that work.

The schedule must show us what are the impediments to performing that work. What are the risks to the project’s success.

And finally the schedule shows us how we are measuring the tangible evidence of progress to our plan.

This evidence and these measures are usually not part of the traditional approach to scheduling. In that traditional approach, work is planned left to right, resources assigned – you do have a resource loaded schedule right?. And then that work is executed.

What we’re going to learn today is that another paradigm is needed in order to increase the probability of success.

This paradigm is called the Integrated Master Plan or IMP. The IMP is used – and many times mandated in large defense and NASA programs. But it is also found in Enterprise IT programs. Project like ERP.

Time: 00 :00 Total: 00:00


The critical understanding here is that all

the activities in the schedule are

probabilistic processes.

All the numbers, duration, cost, technical

performance are random numbers drawn

from a probability density function – a

probability distribution.

If we don’t acknowledge this, we’ll be

disappointed in ways we may not

understand.

We’ll be surprised when we are late and

over budget. We’ll be surprised when the

project starts to fail and we didn’t see it

coming.

We’ve all seen this, we’ve probably been

on projects that behaved this way. We

may have even been the Project

Manager for a project like that.

So we’re half way through our talk today

and it’s time to start looking forward.


Time: 00 :00 Total: 00:00

Here’s the first look at connecting the dots for the perfect schedule.

We’ll assume we have identified the needed capabilities, derived the requirements – all requirements are derived requirements by the way – and these requirements mapped to the Work Breakdown Structure terminal nodes and onto Work Packages.

This WBS to Work Packages mapping starts in the upper left here. One Work Package for one outcome in the WBS. This is a critical success factor. If we have more than one outcome for each Work Package, we’ll have mixed apples and oranges when it comes to measuring Physical Percent Complete of the Work Package.

With the Work Package, we can now define the work activities – the tasks – inside the Work Package that actually do the work.

Here’s where we need to pay attention. Those tasks inside the Work Package are usually not on baseline. That is the schedule of the tasks is the responsibility of the Work Package Manager. The reason is that the sequence of Work Packages is what drives the perfect schedule. The Work Package Manager looks after resource assignments inside the Work Package, the order of the work inside the Work Package, and reporting the progress to plan inside the Work Package.

Here’s the next piece requiring attention. The measure of progress for the tasks in the Work Package is measured as 0% or 100%. This may be new to many here today. But this is basis of the Earned Value Management guidance in most ANSI–748B System Descriptions.

The details of the motivation are beyond this short time period, but here’s the best reason. 0%/100% is simple to measure – either you’re done or you’re not. Not opinion, not rationalization of the work effort. You finished the work in the task or you didn’t


Time: 00 :00 Total: 00:00

Here is the conclusion of todays talk. There

are 8 steps to building a credible schedule

Have a credible Work Breakdown Structure.

This means all the outcomes of the project are

in the WBS. What’s not in the WBS is the

functional organizations (like QA,

development, support), the functions (like

design, code, test). Only things are shipped to

the customer.

The Project Events or Milestones. The places in

the plan that a capability is produced or an

assessment of progress in terms meaningful to

the customer take place.

The Significant Accomplishments needed to

meet the success criteria of the Events. Define

what needs to be done to provide a

capability that can be put to use by the

customer.

The Accomplishment Criteria are the exit

criteria of the Work Packages that contain

the Tasks. State this criteria in measures of

physical percent complete against the

Technical Performance Measures, the

Measures of Effectiveness, and Measures of

Performance.

The Work Packages say their name. They are

Packages of Work that produce a single

outcome.

Determine the interdependencies between

these Work Packages to minimize cost and

schedule, maximize produced value, reduce

programmatic and technical risk, and provide

visibility to the decision makers.

Resource load the Work Packages, assign all

costs, and define risk handling strategies

Update the schedule in the presence of risk,

uncertainty, and past performance.


Time: 00 :00 Total: 00:00

52

An integrated program management

system has these components.

The notion of Technical Performance

Measures is critical to the success of

measuring physical percent complete.

http://slidesha.re/iiRIw0 is a link to the

PMI Technical Performance Measures

materials.

53

http://slidesha.re/iiRIw0

http://slidesha.re/iiRIw0

54

To put this all together the items in the

picture are needed. Only then can you

have a clear and concise of what Done

looks like, how to get there, how to

measure getting there, and how the

handle the risks along the way.

Connecting principles with practice is a

critical success factor for ay approach to

increasing the probability of project

success. Practices without principles

provide the opportunity to modify the

approach without understanding why.

Principles without practices are interesting

discussions without measurable business

benefits.

Both are needed, both must be present

for success.

But you most start with the principles, then

move to the practices. Without the

principles, there is no way to test the

practices to confirm they are on solid

footing when they need to be adapted to

the situation.


55/36

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.



Business

Immutable principles of project management