Building the perfect schedule (v5)(notes)

Time: 00 :22
Total: 00:00
Thank you for coming today to hear
about scheduling. It’s common to think
that scheduling is a simple process.
Get a scheduling tool, enter the tasks,
durations, links, and print out the
schedule.
We’ll find out today that there is more
to this than data entry.
The key to the Perfect Schedule is the
define what done looks like for the
artifact.
The key of course for any project,
effort, and endeavor is the define what
Done looks like before we start.

1

Time: 00 :18
Total: 00:00
Before we venture into developing the
Perfect Schedule, we need to test
some attributes of our organization
and individuals in that organization.
Are we committed – or are we just
putting a check in the box when
someone asks do you have a schedule?
Do we have the capability to produce a
good schedule – have we seen good
schedules? Do we know the attributes
of a good schedule?
Do we have the capacity to do this
work? Is there enough time and
resources to produce the schedule for
the project?
Do we intend to do it right – when we
run into trouble can we persevere to
the end?
Do we posses the core abilities to
make this happen?
It is hoped that end of this session
you’ll have positive answers to all
these questions and be on you way to
building the perfect schedule.

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

Time: 00 :00
Total: 00:00
Here’s a real schedule from a book on
the history of flying to the moon. It’s
simple, its to the point, and it’s close to
what really happened in the Apollo
program.
We’ll want our perfect schedule to
look like this in principle. In practice of
course there are more moving parts.
But this is the notional approach that
tells everyone what done looks like,
how we’re going to get there.


Time: 00 :00
Total: 00:00
The perfect schedule has some attributes
we need to understand before we start.
1. 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.
2. 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.
3. The schedule shows us what resources
are needed to do that work.
4. The schedule must show us what are
the impediments to performing that
work. What are the risks to the
project’s success.
5. 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
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
we 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.
PLANS without SCHEDULES may be
useful, but are not executable.


Time: 00 :00
Total: 00:00
There are many ways to remember what is
needed in a good schedule and the plan
that guides the development of the
schedule. Here’s a simple one. Rudyard
Kipling's poem The Elephants Child
contains a list that he used as a reporter.
This list is the basis of our test for a good
schedule.
These six trusted friends should be
obvious in any schedule to build or look at:
1. Who is doing the work is in the
resource pool and the assignment of
those resources to the work.
2. What are the outcomes or
deliverables from the work. These
deliverables are tangible evidence that
the work has accomplished what it
was planned to do. This evidence is
meaningful to the consumers of the
project.
3. When does this work take place is
shown in the sequence of work
packages in the schedule. Work
Packages are much better that Tasks.
Work Packages result in outcomes
that say their name. They are
Packages of Work. Tasks simply show
the consumption of time and
resources.
4. Where the work is being performed
can be used for locality, functional
departments, or similar information.
5. Why must be answered through a
description of the needed capabilities
for the project to fulfill its mission.
There must be a reason for every
requirement, every action, every
expense.
6. How the work is performed must be
described in the narrative associated
with the Work Packages and the Work
Breakdown Structure.


Time: 00 :00
Total: 00:00
Like all successful approaches to solving
problems, we first need to focus on the critical
few. The same number – in this case 3 – items
that must be addressed first. These are
Who – the resources.
What – the outcomes.
When – the sequence of the Work Packages.
The primary reason for thinking in work
packages is they say their name – they are a
package of work. This package of work
produces one and hopefully only one
outcome. This outcome is complete, done,
finished, to the specifications developed
during the planning of the project. Planning by
the way is not the same as scheduling, but that
is another class.
These packages of work contain tasks, but
we’re not actually interested in the tasks at
this point. What tasks are in the package of
work, how they are arranged is the
responsibility of the Work Package Manager.
That will be addressed later.
What we’re interested in now is what
outcomes are needed to produce the solution
for the project. In what order are those
packages of work performed. These packages
of work are binary – they are done or they are
not done. Partially done work packages on the
day you planned to be done means you’re late
and probability over budget.
Work Packages are a way of asking what have
you done for me lately. Not how hard are you
trying, how much commitment are you
making, none of those things. You’re either
done or you’re not.
The tasks in the Work Package are measured in
the same way 0% or 100%. You did it or you
didn’t. so the development of the perfect
schedule starts by thinking in these black and
white units of measure


Time: 00 :00
Total: 00:00
What are we building is described in
the schedule, but not in the way you
think. The answer to What is described
in the Significant Accomplishments and
the Accomplishment Criteria – or Exit
Criteria – for the Work Packages.
What is represented by tangible
evidence of DONE. Something visible,
something you can bring to the table
to show other people, some form of
measureable outcome.
What is never the passage of time or
the consumption of resources. What is
always a thing.
What is always spoken about in the
past tense. Things like Oracle Database
Initialization Complete. Mechanical
Test Fixture Installed. Concrete core
testing compliant with specifications.
This Plan is common in the Agile
development world. It is also common
in the federal government, where it is
called the Integrated Master Plan.


Time: 00 :00
Total: 00:00
With the Plan, saying what outcomes
will be produced by the project, the
units of measure of DONE for these
outcomes, we now need to put the
Work Packages in the proper order to
cause these outcomes to appear.
This is the role of the schedule. This is
the primary role of the schedule. This
is the only role of the schedule.
All the other heavy lifting for the
project in done in the Integrated
Master Plan and the resource loaded
Work Packages.
With the sequenced Work Packages we
can now see the resource demands on
the available resources. This is called
resource profiling.
When the profile doesn’t work out, we
can re–arrange the Work Packages. But
we should not be changing how the
Work Packages work inside.
If we do, we’ll be continuously chasing
our shadow trying to optimize the
tasks inside the Work Package, when in
fact the Work Packages should be seen
as the lowest level of planning in the
project. They are the Packages of Work
needed to successfully complete the
project.
This is a critical concept and will need
some soak time.
Plan at the Accomplishment and
Criteria level, Schedule at the Work
Package level.
We’ll see some more detail in a bit on
how to think like this.

Time: 00 :00
Total: 00:00
Let’s start with Who. This is arbitrary of
course. We could have started with
What or When. But any credible
schedule is resource loaded.
First, resource loading a schedule is
tricky business. The most important
thing to start is to NOT let the
scheduling tool do the resource
loading. Notice I didn’t say resource
leveling. Don’t let the scheduling tool
do that either.
Why you ask?
Because if the tool does the work for
you, you won’t know why it did what it
did. You won’t be the Master
Scheduler. You won’t understand how
you got the resource spreads that were
created for you by the tool.
This sounds illogical, but it’s one of
those master scheduler pieces of
advise that should be followed
because that’s what Master Schedulers
have come to understand.
Now we can use named resources –
not my favorite – or we can use
resource categories. Let’s start with
resource categories.


Time: 00 :00
Total: 00:00
OK, let’s get started on an example
But one reminder.
Plans and Schedules are needed.
The Plan tells us what DONE looks like,
how we are going to recognize DONE,
what units of measure we’re going to
use to recognize DONE.
The Schedule tells us the work we
need to do to produce the outcomes
that are the basis of DONE.
The Schedule tells us the order of this
work, the resources assigned to the
“packages of work,” and how we are
going to measure physical percent
complete for these work efforts.


Time: 00 :00
Total: 00:00
But before that, one more thing.
Every project, every plan, every
schedule must be capable of dealing
with change.
Managing change is a fools errand.
Managing in the presence of change is
the role of a project manager and the
development team.
Change is simply part of all project
work. How we manage in the presence
of change is the test of our schedule
and our plan.
The plan and the schedule must be
robust in the presence of change. It
must be capable of responding to
change in ways the maintain the value
produced to date and the value sought
in the future.
This of course sounds a lot like Agile,
but that is yet another topic.


Time: 00 :00
Total: 00:00
One more visit to what our Plan tells
us, before we start to talk about
scheduling.
The Plan tells us where we are going.
• What is being delivered – what does
Done look like.
• What work needs to be completed
to move forward toward Done
• What the order of that work is.
• The resources needed to perform
that work. The work in the Packages
of Work.
• And a new concept – what is the
budget for that work.
This is worth repeating – we must have
a plan before we start scheduling. With
a plan, the schedule is just a list of
work activities. We don’t have a
definitive description of what done
looks like, how we would measure
done, what are the impediments to
getting to done.
The schedule is critical to the success
of the project.
The Plan is critical to the success of the
schedule.
Both are needed. But if you’re going to
start somewhere, start with the Plan


Time: 00 :00
Total: 00:00
This is the first mention of something
that has a number associated with it.
The Budget has numbers of currency.
Money.
For our perfect schedule to actually be
perfect we’re going to have to start
thinking in numbers.
Numbers measure performance. How
fast are we driving? How much weight
have we lost? How much did I pay for
that Vente Latte?
Numbers are the lubricant of project
management. Numbers are better than
opinion. Numbers speak about
probabilities of success.


Time: 00 :00
Total: 00:00
So what kinds of numbers?
• Measures of Effectiveness (MoE) are
the operational measures of success
that are closely related to the
achievements of the mission or
operational objectives evaluated in the
operational environment, under a
specific set of conditions. These
measures are stated in units
meaningful to the buyer, Focus on
capabilities independent of any
technical implementation, and are
connected to the mission success.
MoE’s Belong to the End User.
• Measures of Performance (MoP)
characterize physical or functional
attributes relating to the system
operation, measured or estimated
under specific conditions. Measures of
Performance are attributes that assure
the system has the capability to
perform, assessment of the system to
assure it meets design requirements to
satisfy the MoE.
• Cost is derived from the schedule. It’s
not cost and schedule, it’s schedule and
cost. A resource loaded schedule is the
baseline source of the cost. If these are
disconnected, then the credibility of
the project is also disconnected.
• Technical Performance Measures are
attributes that determine how well a
system or system element is satisfying
or expected to satisfy a technical
requirement or goal. Technical
Performance Measures assess design
progress, define compliance to
performance requirements, identify
technical risk, are limited to critical
thresholds, include projected
performance.


Time: 00 :00
Total: 00:00
Let’s remind ourselves the difference
between a Plan and a Schedule.
The Plan tells us where we are going –
what Done looks like.
The schedule tells us how we are going
to get there. What work activities are
needed along the way to done, what
resources do we need, what risks are
we going to encounter that need to be
handled and most importantly how are
we going to measure progress to Plan
using the schedule and the units that
define


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
Ok, enough theory let’s go build
something.
This thing looks interesting. But you
can visualize anything that works for
you.
I personally like things that are shiny
and make lots of noise.
Software things are difficult and if
you’re in the software business, this
approach to building the perfect
schedule is even more important. For
this approach to work, we must
identify tangible evidence of progress
to plan. In the turbo–compressor
picture here that’s easy. In an ERP
system not so much. Which is why is
critically important in the ERP system
to have similar tangible evidence of
progress to plan.
Otherwise we can’t answer the
questions we’re going to ask about
progress to plan. In the absence of
tangible evidence, the only thing let is
soft, fuzzy, opinions. And we all have
experience of where that will take us.
Not a good place.
This is a core failure mode for IT
projects. Without tangible evidence of
progress to plan, IT projects drift into
measures progress by the passage of
time and consumption of resources.


Time: 00 :00
Total: 00:00
When we hear the word WBS we
usually wince. It’s one of those boring,
arcane terms that are applied to
formal project processes.
We don’t need no stink’in WBS.
Well the WBS is one of those critical
success factors for any project.
It’s the description of what DONE looks
like.
It’s the framework for the packages of
work contained in the schedule.


Time: 00 :00
Total: 00:00
At this point in the session, I’m going to let
you in on a secret. There are materials out
there that well guide you on how to build
not only the perfect schedule, but a
perfect WBS, the perfect Earned Value
Management Baseline and most of
everything else you need for project
success.
I apologize for taking so long to get to this
point. But if I told you this in the first slide,
you would not have stayed for the punch
line.
That punch line is there is nothing new
under the sun. This information has been
around for along time. It’s been updated,
but it’s still the same core principles.
What we’re here for today is to see how
to connect the dots between all this
guidance.
But please go to the web of download
these documents. If you’re PMI member
you can get you personal copy. If you’re
not a PMI member, this is one reason to
join.
These documents are:
• The MIL–STD–881C Work Breakdown
Structure Standard.
• The PMI Practice Guide for building a
WBS which does a good job except
when it falls in the functional
decomposition of the project. This
approach is not allowed in the 881C
guide.
• The PMI Risk Management Practice
Guide.
• The PMI Earned Value Management
Practice Guide.
• All of these should be on your desk.
Dog eared, marked up, and with sticky
notes.


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.


Time: 00 :00
Total: 00:00
We’ve talked about the Plan and we
talked about the Schedule.
Here’s the topology of how to put
them together.
Why is this a perfect topology?
Because it shows what is being
delivered, what are the
accomplishments needed to complete
the delivery, and what are the criteria
for each of these accomplishments.
Only then can we start to construct the
schedule needed to complete those
accomplishments according to the
criteria.
If we start with the schedule, we’ll not
have the units of measure needed to
show what DONE looks like. We’ll have
a list of the work. But not a description
of DONE.
With our Plan, the only way to
measure progress is by the passage of
time and the consumption of
resources.
What we want is a set of measures
that show how the product or service
is increasing in its maturity in units of
measure meaningful to the decision
makers.


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
Let’s have a process check. We’ve looked
at several components of the perfect
schedule.
 We need a description of what we’re
going to build. The Work Breakdown
Structure tells us that. The WBS is not
really about the work that is broken
down. It’s about the products and
services produced by the project. This
is described in MIL–STD–881C.
 The packages of work that implement
these products and services are derived
from WBS. This is straight forward. At
the terminal nodes of the WBS a Work
Package is where the tasks exists that
produce the outcomes.
 These outcomes are defined with their
associated Technical Performance
Measures. These measures assess the
increasing maturity of an outcome, the
completeness of an outcome, or some
other measure of Physical Percent
Complete. These measures confirm
that requirements are being met,
capabilities are being provided, the
Measures of Effectiveness are being
fulfilled.
 The last activity is the put these Work
Packages in the proper sequence to
optimize the assignment of resources
and most importantly optimize the
production of value in an increasing
quantity to match the planned business
case.


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
Increasing Maturity is probably a new
term.
In the diagram a few pages ago, was a
value flow chart. Incremental pieces of
the project’s outcomes were
sequenced through the Integrated
Master Plan.
These pieces are arranged in an order
that marched the available resources,
the planned value creation.
These words speak to the increasing
maturity of the projects outcomes.
This maturity has two measures:
 Measures of Effectiveness – does
the project provide the needed
capabilities?
 Measures of Performance – does
the project meet the technical and
operational requirements?
The notion here is that every Work
Package produces a single Outcome.
This outcome has Technical
Performance Measures.
The Technical Performance Measure is
an attribute that determines how well
a system or system element is
satisfying or expected to satisfy a
technical requirement or goal.
Technical Performance Measures,
assesses design progress, Defines
compliance to performance
requirements, identifies technical risk,
and is limited to critical thresholds.


Time: 00 :00
Total: 00:00
So now we’re back to the numbers.
The measures of effectiveness,
measures of performance, technical
performance measures, and the
Earned Value numbers are all installed
in the Integrated Master Schedule.
These numbers are the raw material
for calculating the Probability of
Project Success (PoPS).
This probability uses past performance
to forecast future performance.
Measures of Effectiveness are defined
by the customer
Measures of Performance are
responses to the Measures of
Effectiveness in terms of project
solutions.
Technical Performance Measures are
the attributes of the project solutions
that must be met to be accepted by
the customer.


Time: 00 :00
Total: 00:00
When we say tangible evidence of
progress to plan, we mean something
that can be measured, demonstrated,
assessed.
This of course is the foundation of agile
software development. It is also the
foundation of Systems Engineering and
the US DoD Integrated Master Plan
paradigm. This is not unique to agile.
Working products is the basis of any
successful project. So our perfect
schedule must show how we are going
to produce something that works at
periods sufficiently fie grained to
measure physical percent complete.
This brings us back to the core
question – How long are you willing to
wait before you find out you are late?
The production of a tangible,
measurable outcome should be
shorter than that time period. If you
find this out too late, you have lost the
opportunity to take corrective action.
When you find out you are late, there
is no way to not be late. And since you
are late and didn’t know it, you are
probably also over budget.
When this happens you’re probably
also not providing the planned
technical performance. So now you are
late, over budget, and the thing you
are building doesn’t work.
Not a good place to be if you are the
project manager.

28/38

Time: 00 :00
Total: 00:00
These measures are related in the
following way.
Each needs to be present in the perfect
schedule.
Without these, it is difficult to assess
the performance of the project in any
way meaningful to the decision
makers.
All we can then do is measure cost and
schedule adherence. Which is
important but does not speak to the
value of the products or services
produced by the project.
This approach is guided by the
Integrated Master Plan / Integrated
Master Schedule.
When these measures are assigned to
the Work Packages, Accomplishment
Criteria, Significant Accomplishments,
and the Milestones or Events, we then
have a language to speak about the
performance of the project.


Time: 00 :00
Total: 00:00
If we don’t have these measures we’re
not going to be able to call our
schedule perfect.
We won’t be able to know much other
than we’re over budget and behind
schedule.
But that information isn’t very useful
for staying on schedule and on budget.
It’s also not very useful for determining
if the products or services produced by
the project are of any value to the
customer.
We must have the schedule speak to
these directly.
 Are we meeting the measures of
effectiveness for the customer?
 Are we producing products and
services that are technically and
operationally compliant with these
measures of effectiveness?
 Are we keeping inside the technical
performance bands of the
developed products?
 Are we utilizing our resources at a
rate that will allow the project to
complete on time and on budget –
this is the capacity for work
measure that is the other side of
the productivity measures.


Time: 00 :00
Total: 00:00
This is the final goal of the perfect
schedule.
We have a near perfect understanding
of what happened in the past. It’s
already happened and if we kept some
kind of record, then we’ve got the data
we need.
This is driving in the rear view mirror.
That’s easy. How about forecasting
what’s going to happen in the future.
Of course the future has uncertainties,
but these are handled in another
session – project risk management.
But with the measures we’ve installed
in the IMS, we can forecast compliance
with the upper and lower limits and
use that information to adjust the cost,
schedule, and technical activities
needed to stay GREEN.
This approach turns the management
of the schedule from recoding data to
developing forecasts of future
performance.
This performance analysis is a weekly
process in most domains. In the
government domain a monthly report
of past performance and future
performance is submitted.
This is a good time to introduce the
concept of
How long are you willing to wait before
you find out you are late?

Time: 00 :00
Total: 00:00
In the end our schedule must be the
guide to the success of the project. It
has to be a narrative of all the actions
that answer those 6 trusted friends of a
successful project.
1. Who
2. What
3. When
4. Where
5. How
6. Why


Time: 00 :00
Total: 00:00
Here is the conclusion of todays talk.
There are 8 steps to building a credible
schedule
1. 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.
2. 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.
3. 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.
4. 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.
5. The Work Packages say their name.
They are Packages of Work that
produce a single outcome.
6. 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.
7. Resource load the Work Packages,
assign all costs, and define risk
handling strategies
8. Update the schedule in the presence
of risk, uncertainty, and past
performance.

Time: 00 :00
Total: 00:00
So how much effort do we need to put
into building the Perfect Schedule?
The answer is how well do you need to
manage the project in the presence of
uncertainty?
This isn’t much help, but it starts the
conversation around what is good
enough.
The answer to that is what do you
need to keep control of the project over
some planning horizon?
The Perfect Schedule provides a
management process for the
immediate set of activities and at the
same time provides boundaries for
managing work in the future.
This is the Rolling Wave paradigm.
Definitive plans for the current Rolling
Wave. Planning Packages for future
work.
We don’t have enough time here today
to dive into this structure, but this is
the way large complex projects work.
It has some properties of agile and all
the properties of an end–to–end
schedule with a critical path, definitive
outcomes, and all the attributes we
seen today.
You can have your cake and eat it too.
Short term fine grained management,
longer range planning and adaptation
to the outcomes from the short term.

Time: 00 :00
Total: 00:00
When you start developing a schedule,
5 critical elements of a successful
project must be in place.
In the absence of any one of these 5
areas, the schedule itself will be
suspect. It will not be credible.
These 5 principles are immutable and
deserve repeating
1. Do you know what DONE looks
like?
2. Do you know how to get there –
this is the schedule?
3. Do you have enough resources to
get there – you need – must have
actually – a resource loaded
schedule?
4. Do you know what impediments
will be encounter along the way?
5. Are you measuring progress as
physical percent complete against
planned expenditures.


Time: 00 :00
Total: 00:00
Here is a short list of materials needed
for building a schedule. Much of
material here is guided by external
sources that may or not actually
manage projects and programs.
The challenge here is to separate this
guidance from the actual practices of
building and executing schedules.
The first document, the PASEG,
http://bit.ly/lBXKGN is the best starting
point, since it was built by people who
actually develop and manage
Integrated Master Schedules.


Time: 00 :00
Total: 00:00
So we’ve arrived at the end of our
short time here. What did we learn?
There are 5 irreducible 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 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 build the terminal guidance
control software for an autonomous
Mars Lander


Time: 00 :00
Total: 00:00
If you’ll leave me your card, I’ll send
the reading list for this presentation as
well as a PDF of the slides with the
narrative of my talk, so you can hear it
again in writing.
OK, let’s start with questions.


Building the perfect schedule (v5)(notes)

Recommended

Recommended

More Related Content

Similar to Building the perfect schedule (v5)(notes)

Similar to Building the perfect schedule (v5)(notes) (20)

More from Glen Alleman

More from Glen Alleman (20)

Recently uploaded

Recently uploaded (20)

Building the perfect schedule (v5)(notes)