Huge File Size/Master Project

[frankod]

Hi All,
I am assisting a collegue who is reporting on a program of work in a single
schedule using MSP 2003.

At this stage the file is about 5 meg in size and has almost 2000 tasks. It
also has custom earned value calculations being preformed in custom task
fields and for this to occur baseline data has been saved.

My questions are:

Is this file size appropriate for such a project?

If we break this master project into sub project and then link them into a new master project will the size be similiar/larger?

The biggest issue is that the file takes a long time to open/save/close and expand summary tasks. The file is on a network drive (which may be contributing to the speed) but even when copied to my harddrive it is just as slow (my desktop has over a gig of ram etc so should be ok). Any suggestions?

Many Thanks
Franko

 

[John D.]

I have a couple more that are around 2,000 lines with no baseline yet that
are around 2 megs. Once baselined they will grow a lot. If resources are
added they grow a good bit more even.

The subprojects should be smaller, yes. The master project in my experience
is not proportionally smaller. Meaning if the sub has 500 lines and the
master has 500 lines I would expect the master to be slightly bigger.

I would divide the projects only if they are logically divisble of course.
It'll drive you nuts to have one project spread across two files for no other
reason than file size. In my opinion.

The network is usually the killer. I would save it local, update / edit it,
save it back to the network drive when done. But your locally saved speed is
still bad? Hmmm.

So, what we have done in the past to clean up / speed up the files is to
save out to .XML. Warning, the .XML file is gianormous. Then open the .XML
and save to a new file. The new .MPP should be smaller if it indeed needed a
good scrubbing.

This can help clean out some stuff. If this was 2003 you could do the same
with an .MPD file. I've tried .MPX but that does not seem to be as good but I
can't recall what the issue was exactly.

Having said that, I assume the data you are using would survive the .XML. So
be sure to check.

Final note, clean out anything you don't need. Notes, extra baselines, spare
dates you've saved along the way, unnecessary logic links, formatting, etc.
It's all bits.

Hope that helps.

John

 

[frankod]

Thanks John - very helpful tips.

I have a couple more that are around 2,000 lines with no baseline yet that
are around 2 megs. Once baselined they will grow a lot. If resources are
added they grow a good bit more even.


The subprojects should be smaller, yes. The master project in my experience
is not proportionally smaller. Meaning if the sub has 500 lines and the
master has 500 lines I would expect the master to be slightly bigger.

I would divide the projects only if they are logically divisble of course.
It'll drive you nuts to have one project spread across two files for no other
reason than file size. In my opinion.


The network is usually the killer. I would save it local, update / edit it,
save it back to the network drive when done. But your locally saved speed is
still bad? Hmmm.

So, what we have done in the past to clean up / speed up the files is to
save out to .XML. Warning, the .XML file is gianormous. Then open the .XML
and save to a new file. The new .MPP should be smaller if it indeed needed a
good scrubbing.

This can help clean out some stuff. If this was 2003 you could do the same
with an .MPD file. I've tried .MPX but that does not seem to be as good but I
can't recall what the issue was exactly.

Having said that, I assume the data you are using would survive the .XML. So
be sure to check.

Final note, clean out anything you don't need. Notes, extra baselines, spare
dates you've saved along the way, unnecessary logic links, formatting, etc.
It's all bits.

Hope that helps.

John