Baseline date stamp changes

[Andrew K]

In Baseline0 I have a baseline dated 9/7/05. When I copy Baseline0 to
Baseline1, how can I make the copy keep the original date stamp?

 

[Rick Roszko]

Sorry, but it will always time stamp the current date of your PC...

 

[Sue]

I had the same problem, and came up with this workaround:

When I save the first baseline, I save it twice, (or copy it right after I
save one)once to Baseline, once to Baseline1. Both then have the first
baseline date (say 5/1)
Then when I save the next baseline, I can save it to Baseline and Baseline2.
Both of these will have the new baseline date (say 6/15). I repeat that for
each baseline I save, so that Baseline then always has my most current
version and it has its clone with the same date, so it would look something
like:

Baseline (saved 8/2)
Baseline1 (saved 5/1)
Baseline2 (saved 6/15)
Baseline3 (saved 8/2)

- Sue

 

[Andrew K]

Thanks, Sue. I'll try it.

I had the same problem, and came up with this workaround:

When I save the first baseline, I save it twice, (or copy it right after I
save one)once to Baseline, once to Baseline1. Both then have the first
baseline date (say 5/1)
Then when I save the next baseline, I can save it to Baseline and Baseline2.
Both of these will have the new baseline date (say 6/15). I repeat that for
each baseline I save, so that Baseline then always has my most current
version and it has its clone with the same date, so it would look something
like:

Baseline (saved 8/2)
Baseline1 (saved 5/1)
Baseline2 (saved 6/15)
Baseline3 (saved 8/2)

- Sue

 

[Steve House]

Why do you keep saving and overwriting baselines? The baseline represents
the plan you intend to work. It should not be overwritten as the project
progresses EXCEPT when new tasks are added and/or tasks deleted because the
desired outcome has changed and so it essentially becomes a new, different,
project. The fact that a plan does not progress exactly as originally
scheduled does not mean the baseline would change - you should always be
tracking progress against your original plan. IMHO, the ability to save
multiple baselines in mainly of use to retain an audit trail of the last
series of changes to the plan as it's polished prior to beginning work or to
provide for the possiblity that a project may have several possible outcomes
and which one it will go for hasn't been decided prior to work commencing
(ie, perhaps the first major phase is a feasibility study and at its
conclusion you decide which product goes into production).

 

[Andrew K]

We have projects that last 12-18 months (yes, shorter projects are
preferable). Precision of estimates for downstream tasks improves, tasks are
added and dropped, etc. Projects change substantially, so we re-baseline
every 5-7 months.

Why do you keep saving and overwriting baselines? The baseline represents
the plan you intend to work. It should not be overwritten as the project
progresses EXCEPT when new tasks are added and/or tasks deleted because the
desired outcome has changed and so it essentially becomes a new, different,
project. The fact that a plan does not progress exactly as originally
scheduled does not mean the baseline would change - you should always be
tracking progress against your original plan. IMHO, the ability to save
multiple baselines in mainly of use to retain an audit trail of the last
series of changes to the plan as it's polished prior to beginning work or to
provide for the possiblity that a project may have several possible outcomes
and which one it will go for hasn't been decided prior to work commencing
(ie, perhaps the first major phase is a feasibility study and at its
conclusion you decide which product goes into production).
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

I had the same problem, and came up with this workaround:

When I save the first baseline, I save it twice, (or copy it right after I
save one)once to Baseline, once to Baseline1. Both then have the first
baseline date (say 5/1)
Then when I save the next baseline, I can save it to Baseline and
Baseline2.
Both of these will have the new baseline date (say 6/15). I repeat that
for
each baseline I save, so that Baseline then always has my most current
version and it has its clone with the same date, so it would look
something
like:

Baseline (saved 8/2)
Baseline1 (saved 5/1)
Baseline2 (saved 6/15)
Baseline3 (saved 8/2)

- Sue

 

[Steve House]

There's nothing wrong with the length of the projects and I can't think of
any reason why shorter would be preferrable - even longer projects are far
from uncommon. 12 to 18 month long individual TASKS, on the other hand,
would be another story.

It depends on whether the project schedule is changing or the project itself
is changing. IMHO, actual progress always be compared to the original
schedule even if the estimated schedule has changed in the meantime. Task A
may have been estimated at 30 days so B would have started 01 Sep but now it
appears that A will take 45 days and the schedule has changed with B now
starting on 21 Sep - that sort of change should not prompt a new baseline.
Only if the project scope itself is changing - new features added or
features dropped on a program in development, for example - should it be
rebaselined. But if the changes are simply that the estimates of duration,
required work, etc have changed or are more precise or there have been
changes in resource availability should not trigger a new baseline. In
fact, tracking against your original estimates gives you good historical
data so you can refine your estimating processes for the next project.

Just one opinion, YMMV


--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

We have projects that last 12-18 months (yes, shorter projects are
preferable). Precision of estimates for downstream tasks improves, tasks
are
added and dropped, etc. Projects change substantially, so we re-baseline
every 5-7 months.

Why do you keep saving and overwriting baselines? The baseline
represents
the plan you intend to work. It should not be overwritten as the project
progresses EXCEPT when new tasks are added and/or tasks deleted because
the
desired outcome has changed and so it essentially becomes a new,
different,
project. The fact that a plan does not progress exactly as originally
scheduled does not mean the baseline would change - you should always be
tracking progress against your original plan. IMHO, the ability to save
multiple baselines in mainly of use to retain an audit trail of the last
series of changes to the plan as it's polished prior to beginning work or
to
provide for the possiblity that a project may have several possible
outcomes
and which one it will go for hasn't been decided prior to work commencing
(ie, perhaps the first major phase is a feasibility study and at its
conclusion you decide which product goes into production).
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

I had the same problem, and came up with this workaround:

When I save the first baseline, I save it twice, (or copy it right
after I
save one)once to Baseline, once to Baseline1. Both then have the first
baseline date (say 5/1)
Then when I save the next baseline, I can save it to Baseline and
Baseline2.
Both of these will have the new baseline date (say 6/15). I repeat
that
for
each baseline I save, so that Baseline then always has my most current
version and it has its clone with the same date, so it would look
something
like:

Baseline (saved 8/2)
Baseline1 (saved 5/1)
Baseline2 (saved 6/15)
Baseline3 (saved 8/2)

- Sue

:

In Baseline0 I have a baseline dated 9/7/05. When I copy Baseline0 to
Baseline1, how can I make the copy keep the original date stamp?

 

[Andrew K]

Thank you for this thread. Everything you say makes perfect sense.

Actually, I've been comparing Finish variances for successive interim plans
(not baselines), to see if the variances are decreasing with time. My
assumption: if variances decrease it's because estimating is improving, and
I'll have good effort factors for the next project. In fact, the Finish
variances are not decreasing, so I know to use this historical data with
caution. What do you think of this logic?

There's nothing wrong with the length of the projects and I can't think of
any reason why shorter would be preferrable - even longer projects are far
from uncommon. 12 to 18 month long individual TASKS, on the other hand,
would be another story.

It depends on whether the project schedule is changing or the project itself
is changing. IMHO, actual progress always be compared to the original
schedule even if the estimated schedule has changed in the meantime. Task A
may have been estimated at 30 days so B would have started 01 Sep but now it
appears that A will take 45 days and the schedule has changed with B now
starting on 21 Sep - that sort of change should not prompt a new baseline.
Only if the project scope itself is changing - new features added or
features dropped on a program in development, for example - should it be
rebaselined. But if the changes are simply that the estimates of duration,
required work, etc have changed or are more precise or there have been
changes in resource availability should not trigger a new baseline. In
fact, tracking against your original estimates gives you good historical
data so you can refine your estimating processes for the next project.

Just one opinion, YMMV


--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

We have projects that last 12-18 months (yes, shorter projects are
preferable). Precision of estimates for downstream tasks improves, tasks
are
added and dropped, etc. Projects change substantially, so we re-baseline
every 5-7 months.

Why do you keep saving and overwriting baselines? The baseline
represents
the plan you intend to work. It should not be overwritten as the project
progresses EXCEPT when new tasks are added and/or tasks deleted because
the
desired outcome has changed and so it essentially becomes a new,
different,
project. The fact that a plan does not progress exactly as originally
scheduled does not mean the baseline would change - you should always be
tracking progress against your original plan. IMHO, the ability to save
multiple baselines in mainly of use to retain an audit trail of the last
series of changes to the plan as it's polished prior to beginning work or
to
provide for the possiblity that a project may have several possible
outcomes
and which one it will go for hasn't been decided prior to work commencing
(ie, perhaps the first major phase is a feasibility study and at its
conclusion you decide which product goes into production).
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


I had the same problem, and came up with this workaround:

When I save the first baseline, I save it twice, (or copy it right
after I
save one)once to Baseline, once to Baseline1. Both then have the first
baseline date (say 5/1)
Then when I save the next baseline, I can save it to Baseline and
Baseline2.
Both of these will have the new baseline date (say 6/15). I repeat
that
for
each baseline I save, so that Baseline then always has my most current
version and it has its clone with the same date, so it would look
something
like:

Baseline (saved 8/2)
Baseline1 (saved 5/1)
Baseline2 (saved 6/15)
Baseline3 (saved 8/2)

- Sue

:

In Baseline0 I have a baseline dated 9/7/05. When I copy Baseline0 to
Baseline1, how can I make the copy keep the original date stamp?

 

[Steve House]

I'd certainly say your actuals recorded for this project should be given
relatively high weight in estimating similar tasks in the next one. I'm not
sure I understand the logic you're using in comparing finish variances of
various interim plans - just what are your recording and comparing?


--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Thank you for this thread. Everything you say makes perfect sense.

Actually, I've been comparing Finish variances for successive interim
plans
(not baselines), to see if the variances are decreasing with time. My
assumption: if variances decrease it's because estimating is improving,
and
I'll have good effort factors for the next project. In fact, the Finish
variances are not decreasing, so I know to use this historical data with
caution. What do you think of this logic?

There's nothing wrong with the length of the projects and I can't think
of
any reason why shorter would be preferrable - even longer projects are
far
from uncommon. 12 to 18 month long individual TASKS, on the other hand,
would be another story.

It depends on whether the project schedule is changing or the project
itself
is changing. IMHO, actual progress always be compared to the original
schedule even if the estimated schedule has changed in the meantime.
Task A
may have been estimated at 30 days so B would have started 01 Sep but now
it
appears that A will take 45 days and the schedule has changed with B now
starting on 21 Sep - that sort of change should not prompt a new
baseline.
Only if the project scope itself is changing - new features added or
features dropped on a program in development, for example - should it be
rebaselined. But if the changes are simply that the estimates of
duration,
required work, etc have changed or are more precise or there have been
changes in resource availability should not trigger a new baseline. In
fact, tracking against your original estimates gives you good historical
data so you can refine your estimating processes for the next project.

Just one opinion, YMMV


--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

We have projects that last 12-18 months (yes, shorter projects are
preferable). Precision of estimates for downstream tasks improves,
tasks
are
added and dropped, etc. Projects change substantially, so we
re-baseline
every 5-7 months.

:

Why do you keep saving and overwriting baselines? The baseline
represents
the plan you intend to work. It should not be overwritten as the
project
progresses EXCEPT when new tasks are added and/or tasks deleted
because
the
desired outcome has changed and so it essentially becomes a new,
different,
project. The fact that a plan does not progress exactly as originally
scheduled does not mean the baseline would change - you should always
be
tracking progress against your original plan. IMHO, the ability to
save
multiple baselines in mainly of use to retain an audit trail of the
last
series of changes to the plan as it's polished prior to beginning work
or
to
provide for the possiblity that a project may have several possible
outcomes
and which one it will go for hasn't been decided prior to work
commencing
(ie, perhaps the first major phase is a feasibility study and at its
conclusion you decide which product goes into production).
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


I had the same problem, and came up with this workaround:

When I save the first baseline, I save it twice, (or copy it right
after I
save one)once to Baseline, once to Baseline1. Both then have the
first
baseline date (say 5/1)
Then when I save the next baseline, I can save it to Baseline and
Baseline2.
Both of these will have the new baseline date (say 6/15). I repeat
that
for
each baseline I save, so that Baseline then always has my most
current
version and it has its clone with the same date, so it would look
something
like:

Baseline (saved 8/2)
Baseline1 (saved 5/1)
Baseline2 (saved 6/15)
Baseline3 (saved 8/2)

- Sue

:

In Baseline0 I have a baseline dated 9/7/05. When I copy Baseline0
to
Baseline1, how can I make the copy keep the original date stamp?

 

[Sue]

Excellent question about why to have multiple baselines. I use multiple
baselines precisely in the circumsances you stated:

Only if the project scope itself is changing - new features added or
features dropped on a program in development, for example - should it be
rebaselined.

When we initially sign a contract, we establish our original baseline
information. When a client puts a project on hold, or signs a change order,
we revise the timeline and/or work and move forward, comparing to the new
baseline. This way we can track both to our original plan AND to our most
recent committment.

I use Baseline1 to be my baseline from the original scope of work, and the
others if needed to track approved changes. Baseline always contains my most
current approved baseline information, so I can use it consistently on views
etc regardless of whether there has been an approved change to the original
baseline. (so initially, Baseline and Baseline1 are identical.)

Sue

Thank you for this thread. Everything you say makes perfect sense.

Actually, I've been comparing Finish variances for successive interim plans
(not baselines), to see if the variances are decreasing with time. My
assumption: if variances decrease it's because estimating is improving, and
I'll have good effort factors for the next project. In fact, the Finish
variances are not decreasing, so I know to use this historical data with
caution. What do you think of this logic?

There's nothing wrong with the length of the projects and I can't think of
any reason why shorter would be preferrable - even longer projects are far
from uncommon. 12 to 18 month long individual TASKS, on the other hand,
would be another story.

It depends on whether the project schedule is changing or the project itself
is changing. IMHO, actual progress always be compared to the original
schedule even if the estimated schedule has changed in the meantime. Task A
may have been estimated at 30 days so B would have started 01 Sep but now it
appears that A will take 45 days and the schedule has changed with B now
starting on 21 Sep - that sort of change should not prompt a new baseline.
Only if the project scope itself is changing - new features added or
features dropped on a program in development, for example - should it be
rebaselined. But if the changes are simply that the estimates of duration,
required work, etc have changed or are more precise or there have been
changes in resource availability should not trigger a new baseline. In
fact, tracking against your original estimates gives you good historical
data so you can refine your estimating processes for the next project.

Just one opinion, YMMV


--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

We have projects that last 12-18 months (yes, shorter projects are
preferable). Precision of estimates for downstream tasks improves, tasks
are
added and dropped, etc. Projects change substantially, so we re-baseline
every 5-7 months.

:

Why do you keep saving and overwriting baselines? The baseline
represents
the plan you intend to work. It should not be overwritten as the project
progresses EXCEPT when new tasks are added and/or tasks deleted because
the
desired outcome has changed and so it essentially becomes a new,
different,
project. The fact that a plan does not progress exactly as originally
scheduled does not mean the baseline would change - you should always be
tracking progress against your original plan. IMHO, the ability to save
multiple baselines in mainly of use to retain an audit trail of the last
series of changes to the plan as it's polished prior to beginning work or
to
provide for the possiblity that a project may have several possible
outcomes
and which one it will go for hasn't been decided prior to work commencing
(ie, perhaps the first major phase is a feasibility study and at its
conclusion you decide which product goes into production).
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


I had the same problem, and came up with this workaround:

When I save the first baseline, I save it twice, (or copy it right
after I
save one)once to Baseline, once to Baseline1. Both then have the first
baseline date (say 5/1)
Then when I save the next baseline, I can save it to Baseline and
Baseline2.
Both of these will have the new baseline date (say 6/15). I repeat
that
for
each baseline I save, so that Baseline then always has my most current
version and it has its clone with the same date, so it would look
something
like:

Baseline (saved 8/2)
Baseline1 (saved 5/1)
Baseline2 (saved 6/15)
Baseline3 (saved 8/2)

- Sue

:

In Baseline0 I have a baseline dated 9/7/05. When I copy Baseline0 to
Baseline1, how can I make the copy keep the original date stamp?

 

[Andrew K]

Steve, good question. I'm measuring the differences between finish dates in
successive interim plans -- e.g., datediff("d",[Finish3],[Finish4]) and
seeing trends in finish dates pushed out vs pulled forward. Am I in a land
of make-believe?

Excellent question about why to have multiple baselines. I use multiple
baselines precisely in the circumsances you stated:

Only if the project scope itself is changing - new features added or
features dropped on a program in development, for example - should it be
rebaselined.

When we initially sign a contract, we establish our original baseline
information. When a client puts a project on hold, or signs a change order,
we revise the timeline and/or work and move forward, comparing to the new
baseline. This way we can track both to our original plan AND to our most
recent committment.

I use Baseline1 to be my baseline from the original scope of work, and the
others if needed to track approved changes. Baseline always contains my most
current approved baseline information, so I can use it consistently on views
etc regardless of whether there has been an approved change to the original
baseline. (so initially, Baseline and Baseline1 are identical.)

Sue

Thank you for this thread. Everything you say makes perfect sense.

Actually, I've been comparing Finish variances for successive interim plans
(not baselines), to see if the variances are decreasing with time. My
assumption: if variances decrease it's because estimating is improving, and
I'll have good effort factors for the next project. In fact, the Finish
variances are not decreasing, so I know to use this historical data with
caution. What do you think of this logic?

There's nothing wrong with the length of the projects and I can't think of
any reason why shorter would be preferrable - even longer projects are far
from uncommon. 12 to 18 month long individual TASKS, on the other hand,
would be another story.

It depends on whether the project schedule is changing or the project itself
is changing. IMHO, actual progress always be compared to the original
schedule even if the estimated schedule has changed in the meantime. Task A
may have been estimated at 30 days so B would have started 01 Sep but now it
appears that A will take 45 days and the schedule has changed with B now
starting on 21 Sep - that sort of change should not prompt a new baseline.
Only if the project scope itself is changing - new features added or
features dropped on a program in development, for example - should it be
rebaselined. But if the changes are simply that the estimates of duration,
required work, etc have changed or are more precise or there have been
changes in resource availability should not trigger a new baseline. In
fact, tracking against your original estimates gives you good historical
data so you can refine your estimating processes for the next project.

Just one opinion, YMMV


--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


We have projects that last 12-18 months (yes, shorter projects are
preferable). Precision of estimates for downstream tasks improves, tasks
are
added and dropped, etc. Projects change substantially, so we re-baseline
every 5-7 months.

:

Why do you keep saving and overwriting baselines? The baseline
represents
the plan you intend to work. It should not be overwritten as the project
progresses EXCEPT when new tasks are added and/or tasks deleted because
the
desired outcome has changed and so it essentially becomes a new,
different,
project. The fact that a plan does not progress exactly as originally
scheduled does not mean the baseline would change - you should always be
tracking progress against your original plan. IMHO, the ability to save
multiple baselines in mainly of use to retain an audit trail of the last
series of changes to the plan as it's polished prior to beginning work or
to
provide for the possiblity that a project may have several possible
outcomes
and which one it will go for hasn't been decided prior to work commencing
(ie, perhaps the first major phase is a feasibility study and at its
conclusion you decide which product goes into production).
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


I had the same problem, and came up with this workaround:

When I save the first baseline, I save it twice, (or copy it right
after I
save one)once to Baseline, once to Baseline1. Both then have the first
baseline date (say 5/1)
Then when I save the next baseline, I can save it to Baseline and
Baseline2.
Both of these will have the new baseline date (say 6/15). I repeat
that
for
each baseline I save, so that Baseline then always has my most current
version and it has its clone with the same date, so it would look
something
like:

Baseline (saved 8/2)
Baseline1 (saved 5/1)
Baseline2 (saved 6/15)
Baseline3 (saved 8/2)

- Sue

:

In Baseline0 I have a baseline dated 9/7/05. When I copy Baseline0 to
Baseline1, how can I make the copy keep the original date stamp?

 

[Steve House]

Certainly you are right in the importance of monitoring current progress
against your current commitments. This is, I think, one of the reason
interim plans have been retained though there's no reason you can't use
baselines to do it as well.

Just want to make clear, though. A change of committed delivery dates, a
project being placed on hold or restarted, or revised estimates as to the
amount of work that is required to achieve the deliverables is not what I
mean by "a change in project scope." "Project Scope" deals with the changes
to the deliverables themselves - your original project was to build a
conventional oil refinery but the client has decided he'd also like to have
the capability to produce ethanol blends as well, thus requiring new
equipment be added to the plant therefore increasing the number of tasks to
be done and changing some of their fundamental natures, that sort of thing.

One of the things we need to be careful about is insuring we're not
comparing apples and oranges. When we look at progress in a project, there
are really three aspects to it. One is how things are going with respect to
our committed target dates, another is how things are going with respect to
the RATE of progress we should be making, and finally there's how we're
doing with respect to the budget. Depending on how you view it we could at
once be both right on schedule and terribly late <grin>. If our project was
expected to take 6 weeks and at the end of 3 weeks we've done precisely the
amount of work we had anticipated, we're right on schedule with respect to
the rate at which we are making progress. But that completely ignores
dates. If we started 3 weeks late, we are 3 weeks late when viewed from the
standpoint of our committed delivery date but on-time when viewed from how
long it will take us to finish. The classic measure of progress, Earned
Value, takes a consolidated view by comparing the progress we have made to
date with the plan we had expected to work when we first began the project
as reflected in the first baseline. That's one reason I suggest caution in
rebaselineing, simply because it so easy to lose vital tracking data. You
have to know where you started in order to know how far you have or have not
come.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Excellent question about why to have multiple baselines. I use multiple
baselines precisely in the circumsances you stated:

Only if the project scope itself is changing - new features added or
features dropped on a program in development, for example - should it be
rebaselined.

When we initially sign a contract, we establish our original baseline
information. When a client puts a project on hold, or signs a change
order,
we revise the timeline and/or work and move forward, comparing to the new
baseline. This way we can track both to our original plan AND to our most
recent committment.

I use Baseline1 to be my baseline from the original scope of work, and the
others if needed to track approved changes. Baseline always contains my
most
current approved baseline information, so I can use it consistently on
views
etc regardless of whether there has been an approved change to the
original
baseline. (so initially, Baseline and Baseline1 are identical.)

Sue

Thank you for this thread. Everything you say makes perfect sense.

Actually, I've been comparing Finish variances for successive interim
plans
(not baselines), to see if the variances are decreasing with time. My
assumption: if variances decrease it's because estimating is improving,
and
I'll have good effort factors for the next project. In fact, the Finish
variances are not decreasing, so I know to use this historical data with
caution. What do you think of this logic?

There's nothing wrong with the length of the projects and I can't think
of
any reason why shorter would be preferrable - even longer projects are
far
from uncommon. 12 to 18 month long individual TASKS, on the other
hand,
would be another story.

It depends on whether the project schedule is changing or the project
itself
is changing. IMHO, actual progress always be compared to the original
schedule even if the estimated schedule has changed in the meantime.
Task A
may have been estimated at 30 days so B would have started 01 Sep but
now it
appears that A will take 45 days and the schedule has changed with B
now
starting on 21 Sep - that sort of change should not prompt a new
baseline.
Only if the project scope itself is changing - new features added or
features dropped on a program in development, for example - should it
be
rebaselined. But if the changes are simply that the estimates of
duration,
required work, etc have changed or are more precise or there have been
changes in resource availability should not trigger a new baseline. In
fact, tracking against your original estimates gives you good
historical
data so you can refine your estimating processes for the next project.

Just one opinion, YMMV


--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


We have projects that last 12-18 months (yes, shorter projects are
preferable). Precision of estimates for downstream tasks improves,
tasks
are
added and dropped, etc. Projects change substantially, so we
re-baseline
every 5-7 months.

:

Why do you keep saving and overwriting baselines? The baseline
represents
the plan you intend to work. It should not be overwritten as the
project
progresses EXCEPT when new tasks are added and/or tasks deleted
because
the
desired outcome has changed and so it essentially becomes a new,
different,
project. The fact that a plan does not progress exactly as
originally
scheduled does not mean the baseline would change - you should
always be
tracking progress against your original plan. IMHO, the ability to
save
multiple baselines in mainly of use to retain an audit trail of the
last
series of changes to the plan as it's polished prior to beginning
work or
to
provide for the possiblity that a project may have several possible
outcomes
and which one it will go for hasn't been decided prior to work
commencing
(ie, perhaps the first major phase is a feasibility study and at its
conclusion you decide which product goes into production).
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


I had the same problem, and came up with this workaround:

When I save the first baseline, I save it twice, (or copy it right
after I
save one)once to Baseline, once to Baseline1. Both then have the
first
baseline date (say 5/1)
Then when I save the next baseline, I can save it to Baseline and
Baseline2.
Both of these will have the new baseline date (say 6/15). I
repeat
that
for
each baseline I save, so that Baseline then always has my most
current
version and it has its clone with the same date, so it would look
something
like:

Baseline (saved 8/2)
Baseline1 (saved 5/1)
Baseline2 (saved 6/15)
Baseline3 (saved 8/2)

- Sue

:

In Baseline0 I have a baseline dated 9/7/05. When I copy
Baseline0 to
Baseline1, how can I make the copy keep the original date stamp?

 

[Steve House]

I wouldn't say make believe but I would suggest you also compare the most
recent plan against the original baseline that was saved before beginning
work. Knowing that as of this week our expected finish date is 1 week
earlier than we had expected last week still doesn't tell me if I'm going to
finish on time or not - it only tells me that the scheduled duration is
getting longer or shorter.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Steve, good question. I'm measuring the differences between finish dates
in
successive interim plans -- e.g., datediff("d",[Finish3],[Finish4]) and
seeing trends in finish dates pushed out vs pulled forward. Am I in a
land
of make-believe?

Excellent question about why to have multiple baselines. I use multiple
baselines precisely in the circumsances you stated:

Only if the project scope itself is changing - new features added or
features dropped on a program in development, for example - should it be
rebaselined.

When we initially sign a contract, we establish our original baseline
information. When a client puts a project on hold, or signs a change
order,
we revise the timeline and/or work and move forward, comparing to the new
baseline. This way we can track both to our original plan AND to our
most
recent committment.

I use Baseline1 to be my baseline from the original scope of work, and
the
others if needed to track approved changes. Baseline always contains my
most
current approved baseline information, so I can use it consistently on
views
etc regardless of whether there has been an approved change to the
original
baseline. (so initially, Baseline and Baseline1 are identical.)

Sue

Thank you for this thread. Everything you say makes perfect sense.

Actually, I've been comparing Finish variances for successive interim
plans
(not baselines), to see if the variances are decreasing with time. My
assumption: if variances decrease it's because estimating is
improving, and
I'll have good effort factors for the next project. In fact, the
Finish
variances are not decreasing, so I know to use this historical data
with
caution. What do you think of this logic?

:

There's nothing wrong with the length of the projects and I can't
think of
any reason why shorter would be preferrable - even longer projects
are far
from uncommon. 12 to 18 month long individual TASKS, on the other
hand,
would be another story.

It depends on whether the project schedule is changing or the project
itself
is changing. IMHO, actual progress always be compared to the
original
schedule even if the estimated schedule has changed in the meantime.
Task A
may have been estimated at 30 days so B would have started 01 Sep but
now it
appears that A will take 45 days and the schedule has changed with B
now
starting on 21 Sep - that sort of change should not prompt a new
baseline.
Only if the project scope itself is changing - new features added or
features dropped on a program in development, for example - should it
be
rebaselined. But if the changes are simply that the estimates of
duration,
required work, etc have changed or are more precise or there have
been
changes in resource availability should not trigger a new baseline.
In
fact, tracking against your original estimates gives you good
historical
data so you can refine your estimating processes for the next
project.

Just one opinion, YMMV


--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


We have projects that last 12-18 months (yes, shorter projects are
preferable). Precision of estimates for downstream tasks improves,
tasks
are
added and dropped, etc. Projects change substantially, so we
re-baseline
every 5-7 months.

:

Why do you keep saving and overwriting baselines? The baseline
represents
the plan you intend to work. It should not be overwritten as the
project
progresses EXCEPT when new tasks are added and/or tasks deleted
because
the
desired outcome has changed and so it essentially becomes a new,
different,
project. The fact that a plan does not progress exactly as
originally
scheduled does not mean the baseline would change - you should
always be
tracking progress against your original plan. IMHO, the ability
to save
multiple baselines in mainly of use to retain an audit trail of
the last
series of changes to the plan as it's polished prior to beginning
work or
to
provide for the possiblity that a project may have several
possible
outcomes
and which one it will go for hasn't been decided prior to work
commencing
(ie, perhaps the first major phase is a feasibility study and at
its
conclusion you decide which product goes into production).
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


I had the same problem, and came up with this workaround:

When I save the first baseline, I save it twice, (or copy it
right
after I
save one)once to Baseline, once to Baseline1. Both then have
the first
baseline date (say 5/1)
Then when I save the next baseline, I can save it to Baseline
and
Baseline2.
Both of these will have the new baseline date (say 6/15). I
repeat
that
for
each baseline I save, so that Baseline then always has my most
current
version and it has its clone with the same date, so it would
look
something
like:

Baseline (saved 8/2)
Baseline1 (saved 5/1)
Baseline2 (saved 6/15)
Baseline3 (saved 8/2)

- Sue

:

In Baseline0 I have a baseline dated 9/7/05. When I copy
Baseline0 to
Baseline1, how can I make the copy keep the original date
stamp?