Maintaining a Valid Baseline

[RTucker]

Hello all,

We had a VBA curruption issue that was resolved only by inserting the bad
file into a new blank file at Task line 1, then disabling the link to the bad
file. (everyone follow that?) An export/import of XML would not work,
either from possible bad logic in the XML file, or due to the XML filesize of
350MB. Even a four processor, 3GB RAM PC would not import the XML file.
Anyway...

After disabling the external link I was left with a new project file with
all my original data. I am left with the question of how does Project track
the baseline values on tasks and for the project overall.

Understandably, the date the last Baseline was performed no longer appears
in parenthesis, in Tools-Tracking. So, what do I do?

By baselining all tasks, I will lose all my variance, yes? I do not want to
rebaseline the entire project. I'm on a government project and the auditors
will not like that.

I rebaselined one task where the S/F dates matched the baseline dates, and
the (last baselined on) date is now showing. But does this validate all the
other baseline values for all the other tasks?

Project allows you to manually enter/edit baseline date values into task
records. What's up with that?!! Does MS Project track the baseline status
of each task, or only at the project level. I've reviewed the E/R diagram
from the Resource Kit, but don't see the answer.

Oh, one more, please...
In reviewing the baseline dates, I found a Milestone task with BLstart of
4/20/05 and a BLfinish of 4/16/05! How can that be?

 

[Rod Gill]

It sounds like your schedule had a good old dose of corruption. Saving the
original to .mpd format then opening it again from .mpd and saving back to
..mpp may help. Baseline SF for a milestone should be the same, but you can
nominate a normal task to be a baseline.

With your copy/paste if you selected the row numbers to select task data
then all baseline information will have been copied as well. If you only
copied the visible columns then your baseline data won't have copied.

It's good practice to at least once every couple of weeks for a heavily used
..mpp file to immediately after you open a .mpp file press Ctrl+S or select
File, Save. That is the only time house keeping is done on the file, space
no longer used after tasks etc have been deleted is cleared and more. No may
notice file sizes drop by doing this. This all happens as well every time a
file save as is done.

In Project 2002+ I always save the first baseline to Baseline1 and happily
reset the normal baseline every week so I can see weekly progress in the
Tracking Gantt view.

 

[Steve House [Project MVP]]

As food for thought, I like to think of the baseline as b eing a record of
the plan that you thought you were going to do, preserving your original
intention so you an later compare the plan as it is evolving when you
actually do the work so you can see how well you're doing against your
original projections. As such, I suggest that one only re-baseline a plan
in response to scope changes that make it effectively a substantially new
project and then only rebaselining the tasks that changed or were added in
response to the new requirements.

 

[RTucker]

Yes, Rod, the file was very corrupted. Saving to .mpd and back again
retained the VBA corruption. So did an Access .mdb out/in conversion. Only
a XML out/in would have saved all my data intact, assuming the data is
logically sound. And from the looks of it, it is not.

I learned about the "Perform an immediate CTL-S" trick a few weeks ago,
thanks to the tips found at this discussion group. That has helped to keep
the file size below 20MB, but did nothing for the VBA issues.

I'm disappounted that MS project allows a Finish date to be less than the
Start date, even if it is the Baseline S/F.

Conceptually, I understand how to save to Baseline1 versus Baseline. But I
thought that the Tracking Gantt displays Baseline to Actuals. If your real
baseline exists in Baseline1, how are you performing EVM reporting? Where is
your data coming from? I don't follow you.

 

[RTucker]

Yes, I totally agree and am attempting to do just that. use a legitimate
baseline. But my file corruption issues prevented me from continuing work
with a 5800 line schedule unless I performed the "project import and delink"
routine I described. This left me with a Baseline that is now questionable.
When I found the milestone with a BLfinish that was before it's BLstart, I
became very suspicious of MSP 2003's ability to calculate and maintain data.
I traced back through archived files and found the Finish<Start issue existed
long before I performed the conversion to correct the VBA issues.

Here's what I discovered since then...
MS Project does not protect the Baseline fields at all! You can manually
overwrite them. So, I can go through all the pains of establishing a
baseline, then someone can change the data in Baseline Start/Finish, etc. and
resave the file. The "Last saved on..." info is not affected. There is no
way to know if someone messes with the schedule data.

Microsoft need to put field-level security on this product. And they need
to add better error checking into the calculations functionality to prevent
time-warping milestones!