Immutable principles of project management

Copyright ® 2012, Glen B. Alleman, All Rights Reserved
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

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?



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


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.

33/36


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

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.

37

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.

38

Here’s another view of connecting
the Five Principles with the Five
Practices while building the Needed
Capabilties.

39

And another view.
Multiple views of the same process and
problem are always needed.

40

For the IT world, here’s a way to
assemble the deliverables based
planning into a business process.

41

A way to show how capabilities can
drive requirements and how
capabilities can be connected to
business benefits.

42

An example of a Product
Development Kaizan for a space
craft.

43

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.

44

Another view of a Value Stream Map,
showing how the maturity of products and
services move from left to right.

45

Time: 00 :00
Total: 00:00

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.


Immutable principles of project management

Immutable principles of project management

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Immutable principles of project management

Ähnlich wie Immutable principles of project management (20)

Mehr von Glen Alleman

Mehr von Glen Alleman (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Immutable principles of project management