building the perfect schedule (v5)(notes)

1

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.

Time: 00 :22 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 :18 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.


Time: 00 :00 Total: 00:00

building the perfect schedule (v5)(notes)

Technology

perfect schedule

schedule right

real schedule

project work

work packages result

tangible evidence thatthe

good schedules

pmi mile high symposium