Heresy - how to prevent Project from calculating/changing dates

[dgmoore]

I have a requirement to maintain a schedule (or, more accurately, a
calendar...) using MSProject. It is necessary that this Project file
maintain all dates as entered and not change data through
recalculation. It is also required that dependencies be displayed.

Basically, in this application, Project is used merely as a data
repository and Gantt chart generator. Although this is not how Project
is intended to be used, I have no other option in this instance.

I want to take advantage of such features as summaries, rolled up
progress, and the like that Project calculates automatically, so I
would like to use Start/Finish but ensure that those dates do not get
recalculated. To that end I have set calculation to manual, new tasks
start on current date, and tasks honor constraint dates = no.

Can anybody suggest anything else I need to allow for in this file?
Thanks
Dave

 

[JackD]

Turning off calculation should be sufficient. Your schedule might not make
any sense, but at least it will look the same.
You could also set it to read only. Or better yet. Just do a screen capture
when you have it the way you want.

 

[Steve House [MVP]]

If you need to track progress etc you really have to have calculation set
on. But how could you possibly enter actual data without changing the plan?
A task was scheduled to start on 15 January. It actually started on 20
January. How can you record the actual data you need to track, in this case
the date it began, without changing the start date?

You also said you need to show dependencies. Taking for discussion the
default FS link, dependencies mean, by the very definition of the word, that
the start time of the successor task is dependent on the finish time of the
predecessor task. There is something in the second task that uses something
produced by the first and until that something exists it is physically
impossible for the 2nd task to start. But in your question you seem to be
saying you want to ignore that scheduling fact, that you want task 2 to be
scheduled on some arbitrary date and stay there even if it means that the
people who will do the work are going to show up and sit around twiddling
their thumbs, waiting and wasting your money doing nothing, for the required
parts or whatever to show up so they can start work. No offense intended,
but this makes absolutely no business sense at all.

If it is required you know what the original plan was, so that you can
compare performance against plan, that is another story all together. After
you create your plan and before starting to post in actuals, you save a
baseline. The baseline is a snapshot of the plan and in the baseline all
the original values of start and finish etc are locked in and preserved even
if different values are subsequently entered in the plan or posted as
actuals later on. Once you have the baseline, it is an easy task to create
a Gantt chart and task table that uses the baseline values rather than the
normal one that uses the scheduled values. As you enter actuals, the
schedule will change but the Gantt chart you're showing isn't using those
values but the locked-down baseline values instead and so will always show
the static plan as originally conceived. How this has any use as a
management tool is beyond me, but you certainly can do it technically.

And the best advice I can give is to keep a second copy of the plan
maintained as it really should be so when the boss who's requiring you to do
this is fired for s****ing up the project and throwing away so many
resources, you can show HIS boss how you would have done it properly and
earn yourself a promotion <grin>.

 

[jsl]

I am in the same boat...

I am maintaining a "schedule" (more like wallpaper with dates on it)
but the schedule doesn't appear to be used as anything more than a
presentation tool--not to actually manage the project.

The customer has no interest in tracking use of resources, so we
regularly end up manually adjusting start/finish dates (mostly finish
dates). I finally convinced them that there should be some sort of
"baseline" and we are working to manually research and type in data
from the oldest versions of the schedule we can locate. Not, in my
mind, the best way to track baseline and progress, but it's how they
want to do things.

 

[Steve House [MVP]]

You probably already know this, but the baseline is not what you did in
previous projects, it's what you think you can do in this one. You're
correct in one aspect - the estimates for this project should be based, in
part, on the actual performance you achieved in previous projects. But
that's not the same thing as the baseline - last time you did something like
this you may have had more or less manpower available to do the work, for
example, so you take that into account when you estimate the schedule for
this project. Then once you have what you feel is a workable plan for the
current project, you save that as a baseline so you have something to track
your actual progress against, a constant to see if you're proceeding
on-track or are falling behind or spending more than your budget allows,
etc.

Management and clients that think they have a better way can account in part
for the fact that well ofer 50% of all projects end up as "failures" in that
they fail to achieve all the deliverables, are abandoned before completion,
run over schedule or budget.

 

[jsl]

I agree 100%. However, no baseline was established at the beginning of
this project about 3 years ago. Now, they want to establish a
"baseline" presumably using historical data from earlier in the project
(for example data from the version of the schedule I was originally
given 8 months ago when I started providing schedule maintenance
support).

IMO, some sort of baseline should be established, to hopefully provide
management a clearer picture of slippage. Although, in reality,
establishing a baseline after the fact based on old data is not
necessarily the best approach... especially since there's new slippage
every week or so.

 

[Steve House [MVP]]

A constantly changing baseline - what a concept!!!! ROFL

 

[jsl]

If in doubt and you're running behind schedule, re-baseline. Presto...
no more late tasks.

Unfortunately... par for the course.