Belated answer, however this is still a common issue for many. I thought I'd provide what I can to help anyone else coming across this with the same question.
So, I'll address the project organization question first since that's what the OP asked, below that are some technical factors that may help you work around the file size problem.
I have typically had development and support in different projects. That is my default. In fact, I usually don't treat support as a project. However, in this case I think you have a time management need and you are trying to minimize the number of 'tools'.
We tend to group work by specialty area and those would be different schedule files. These areas typically have some sort of a team lead person associated with them, that's pretty key. 'Course a lead could have accountability for several projects.
Lets assume you are producing content for a business school, maybe you could break it up like this:
Then there would be a support project for each. Can there be one support project? Maybe if there is one task per product that would be okay ...
Or ... as I look at that and consider the numbers of projects you are doing I think maybe you could keep the support projects in each departmental project.
Maybe you are working across multiple schools and the school is the basis for the project file.
Question - how does your team see themselves in terms of working groups? Maybe that's the way to go.
The best phrase I've heard on this is, "Sometime we have to torture things into these buckets". ;-)
Do you know about master projects and how to set up sub projects in a master project? What we use the master project for is:
- Setting links between projects
- Rationalizing critical path
- Reporting & XLSX exports for reporting
We don't routinely work out of the master project. We use it at report time and maybe once or twice a day to check thing. If it's set up as read write it locks the sub projects as soon as you expand them.
Key Point - The underlying data base has placeholders for every potential cell. That's the list of columns. It's huge. Once they get any data in them at all, it seems to me that it's quite impossible to recover the space unless the entire row is deleted. Formatting is data too. I've tried to programmatically clean things up too, difficult and not always effective.
Formatting - Keep it simple and dull. If you need special formatting put it in a view that has it's own table defined for it. Good practice anyway. Keep the base Gantt view and Entry table as default so you have something to go back to.
Inactive tasks - New feature in the past couple of versions. I find my PMs L-O-V-E to keep these things around. It leads to schedule bloat. If you need them for reference copy them off to another .mpp file.
Turn off auto sizing on the columns - eats a ton of CPU
In a pinch you can turn off auto-calc but this gets tricky cause people forget ... I've burned myself a lot on that one ... ;-(
Resources - If you can resource by type -vs- named person to minimize the resources. If you have costs assigned ask if you really need them. Costing can be done in Excel based on output from Project too. More steps, yes.
Bar Formatting - If the Gantt bars are default they use shading & gradients. Another CPU suck. Redefined them to be the old solid colors with no gradients. You can use special views for reporting so you don't have to work in the more user friendly views all the time.
Computed columns - If you have computed columns you want to at least challenge the need for them. Every time you change a cell they all have to be processed.
Okay, so the theme there is to trim the fat on anything that smells like it gets done on a cell change.
Um ... either delete or copy off closed projects or other cohesive "chunks" of work to keep the file size down as best you can.
File size - We find that anything north of 75MB is a challenge and anything north of 120MB tends to fail and self corrupt. Everything I've mentioned drives file size. Oh, you have to close & save twice to get it to recover available space.
File clean up -
Files under about 50MB can be exported to XML and reopened as new files. The biggest problem here will be links to external projects getting dropped. This can help reduce file size.
Saving back to the lowest version you can go with your current version and then reopening in the current version can strip out newer fields that you are hopefully not using. Obviously if you are using newer features this can be tricky or totally unworkable.
Hope that helps some ... running the scheduling engine is it's own project!