Baseline vs Scheduled

[EmilH]

Hi.

Can anybody explain me what's the deifference between for example baseline
cost and scheduled cost? If saving baseline takes a snapshot of the status
then I can assume that baseline is planned cost... as scheduled cost is.
What's the point?

Thanks.
Emil.

 

[Dave]

Hi.

Can anybody explain me what's the deifference between for example baseline
cost and scheduled cost? If saving baseline takes a snapshot of the status
then I can assume that baseline is planned cost... as scheduled cost is.
What's the point?

Thanks.
Emil.

The baseline is a snapshot of the project at the time you take the
baseline - normally day 0 effectively. At that point the basline cost
will match the scheduled cost.

However as the project proceeds, it is likely that things will not
precisely follow the plan. Some things will cost more than was
origainlly planned and some things will cost less. Consequently, at any
moment in time, the scheduled cost at that moment in time will almost
certainly vary from the baseline cost.

 

[Steve House]

Adding a bit to Dave's comment ... a schedule is a dynamic thing - you
create the initial schedule based on the best inofrmation you have available
at the time but as time passes and things evolve, the schedule continuously
changes to reflect new realities. The first task took a week longer than we
had thought it would so the second task has to be rescheduled to start a
week later, that sort of thing. So the scheduled dates, durations, costs,
etc is our best guesses of what will happen based on the information we now
have. The baseline preserves the original estimates so we always have a
constant reference point for measuring actual and forecast against budget.
I like to think of the baseline as planned while the schedule becomes
forecast once work begins.

Saving a baseline, IMHO, is something that should be done only once in the
project's life cycle, as Dave said, typically at Day 0. The only time it
should be re-baselined is when tasks are added or removed so that what
remains of the original plan becomes essentially a new project. Changes in
duration, costs, etc caused by actuals deviated from original estimates
should not give rise to rebaselining. The multiple baselines feature in
Project is an advantage in giving you an audit trail of last minute changes
as the plan is finalized before starting work on the one hand or changes in
the project framework introduced after work begins.

 

[EmilH]

Thanks, guys! It's clear now.
Emil.

Adding a bit to Dave's comment ... a schedule is a dynamic thing - you
create the initial schedule based on the best inofrmation you have
available at the time but as time passes and things evolve, the schedule
continuously changes to reflect new realities. The first task took a week
longer than we had thought it would so the second task has to be
rescheduled to start a week later, that sort of thing. So the scheduled
dates, durations, costs, etc is our best guesses of what will happen based
on the information we now have. The baseline preserves the original
estimates so we always have a constant reference point for measuring
actual and forecast against budget. I like to think of the baseline as
planned while the schedule becomes forecast once work begins.

Saving a baseline, IMHO, is something that should be done only once in the
project's life cycle, as Dave said, typically at Day 0. The only time it
should be re-baselined is when tasks are added or removed so that what
remains of the original plan becomes essentially a new project. Changes
in duration, costs, etc caused by actuals deviated from original estimates
should not give rise to rebaselining. The multiple baselines feature in
Project is an advantage in giving you an audit trail of last minute
changes as the plan is finalized before starting work on the one hand or
changes in the project framework introduced after work begins.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Hi.

Can anybody explain me what's the deifference between for example
baseline cost and scheduled cost? If saving baseline takes a snapshot of
the status then I can assume that baseline is planned cost... as
scheduled cost is. What's the point?

Thanks.
Emil.

 

[davegb]

Adding a bit to Dave's comment ... a schedule is a dynamic thing - you
create the initial schedule based on the best inofrmation you have available
at the time but as time passes and things evolve, the schedule continuously
changes to reflect new realities. The first task took a week longer than we
had thought it would so the second task has to be rescheduled to start a
week later, that sort of thing. So the scheduled dates, durations, costs,
etc is our best guesses of what will happen based on the information we now
have. The baseline preserves the original estimates so we always have a
constant reference point for measuring actual and forecast against budget.
I like to think of the baseline as planned while the schedule becomes
forecast once work begins.

Saving a baseline, IMHO, is something that should be done only once in the
project's life cycle, as Dave said, typically at Day 0. The only time it
should be re-baselined is when tasks are added or removed so that what
remains of the original plan becomes essentially a new project. Changes in
duration, costs, etc caused by actuals deviated from original estimates
should not give rise to rebaselining. The multiple baselines feature in
Project is an advantage in giving you an audit trail of last minute changes
as the plan is finalized before starting work on the one hand or changes in
the project framework introduced after work begins.

With all due respect to Steve, baselining a project is often done
multiple times. At the beginning, of course. But also as the project
progresses and things change, the original baseline often becomes more
a painful reminder of what you once hoped than an incentive to
succeed. At this point, it's perfectly acceptable to re-baseline,
after getting agreement from management, client, etc. No point beating
the team up with now impossible goals. Better to reset and start
afresh! Others may disagree, but on large, long projects, this is most
often the case.

 

[Steve House]

Of course you're right, Dave. Baselines are indeed often redone. But the
burning question remains whether they should be and if so, what should
trigger it. IMHO, a "baseline" represents the plan that you thought you
could achieve, the plan you submitted to senior management as your
intentions, and that you received the signed cheque with the annotation "Do
it!" in response to. If you're honest with yourself and the folks who sign
the cheques, the only time the baseline changes is if what you intend to do
also changes. Changing business priorities has mandated you change horses
in midstream and that's perfectly legit. But rebaselining due to variances
in actual performance versus planned performance simply means you're
covering up the fact that your original plan was faulty and/or incomplete.
Plans are often made on incomplete data and indeed that's probably the norm
rather than the exception. But rebaselining only covers up the fact and
doesn't help you do the next project plan better because when you do, you
lose all the data about where you went wrong in planning this one.

 

[davegb]

Of course you're right, Dave. Baselines are indeed often redone. But the
burning question remains whether they should be and if so, what should
trigger it. IMHO, a "baseline" represents the plan that you thought you
could achieve, the plan you submitted to senior management as your
intentions, and that you received the signed cheque with the annotation "Do
it!" in response to. If you're honest with yourself and the folks who sign
the cheques, the only time the baseline changes is if what you intend to do
also changes. Changing business priorities has mandated you change horses
in midstream and that's perfectly legit. But rebaselining due to variances
in actual performance versus planned performance simply means you're
covering up the fact that your original plan was faulty and/or incomplete.
Plans are often made on incomplete data and indeed that's probably the norm
rather than the exception. But rebaselining only covers up the fact and
doesn't help you do the next project plan better because when you do, you
lose all the data about where you went wrong in planning this one.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visithttp://www.mvps.org/project/faqs.htmfor the FAQs

Adding a bit to Dave's comment ... a schedule is a dynamic thing - you
create the initial schedule based on the best inofrmation you have
available
at the time but as time passes and things evolve, the schedule
continuously
changes to reflect new realities. The first task took a week longer than
we
had thought it would so the second task has to be rescheduled to start a
week later, that sort of thing. So the scheduled dates, durations,
costs,
etc is our best guesses of what will happen based on the information we
now
have. The baseline preserves the original estimates so we always have a
constant reference point for measuring actual and forecast against
budget.
I like to think of the baseline as planned while the schedule becomes
forecast once work begins.
Saving a baseline, IMHO, is something that should be done only once in
the
project's life cycle, as Dave said, typically at Day 0. The only time it
should be re-baselined is when tasks are added or removed so that what
remains of the original plan becomes essentially a new project. Changes
in
duration, costs, etc caused by actuals deviated from original estimates
should not give rise to rebaselining. The multiple baselines feature in
Project is an advantage in giving you an audit trail of last minute
changes
as the plan is finalized before starting work on the one hand or changes
in
the project framework introduced after work begins.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visithttp://www.mvps.org/project/faqs.htmforthe FAQs
news:[email protected]...

With all due respect to Steve, baselining a project is often done
multiple times. At the beginning, of course. But also as the project
progresses and things change, the original baseline often becomes more
a painful reminder of what you once hoped than an incentive to
succeed. At this point, it's perfectly acceptable to re-baseline,
after getting agreement from management, client, etc. No point beating
the team up with now impossible goals. Better to reset and start
afresh! Others may disagree, but on large, long projects, this is most
often the case.

- Show quoted text -

One of the purposes of a baseline is to give a realistic, achiveable
goal for the project team to shoot for. At the beginning of a long
project, say 2 yrs or more, a 3 yr schedule may be a valid target. A
year or two later, it may no longer be so. As a practical PM, I don't
see any value at that point in beating up everyone on the team,
defeating one of the primary purposes of having the plan in the first
place, by continually remindind us all that it didn't happen. Whether
it was because of poor planning or execution, at that point, is moot.
(It's not moot when you're doing the post mortem). Working daily using
the Tracking Gantt where none of the baseline bars are anywhere in
sight of the currently scheduled task bar is ridiculous! And counter-
productive.

I understand that a purist like yourself probably doesn't agree with
this, but it's just my, and others, POV. Short of homicde, I'll do
whatever I need to to get the project done on time.

Different approaches work for different people in different
situations. If yours is working for you, then keep on truckin'! Mine
works great for me.