Benefits of one project per file

[Conrad Santiago]

I manage a consolidated schedule with six files. The six files come from our six project managers. Each of them has one file where they manage their projects under summary tasks. In all, there are about 80 projects

This works well because I only have to load 6 files as opposed to 80

Are there benefits I'm missing out on by not having one file per project

Thanks in advance
--Conrad Santiago

 

[Rob Schneider]

I guess it all depends on how the PM's handle their own portfolio of a
dozen projects and whether they prefer consolidation or segregation of
files.

You ---+-- PM1
| +--------+--- Project 1
+ +--- Project 2
+ +--- Project 3
+ +--- Etc
+-- PM2
+ +--------+--- Project 13
| +--- Project 14
| +--- Etc.
+-- Etc.

I would think that each PM would find their own benefits of using
individual files for individual projects ... all depends on how many
tasks for each file. Everyone has their own preference. I personally
like (for many reasons--some logical and others just opinion/experience)
to see no more than 100-300 tasks per file. If these projects are
modeled by 10 tasks, then consolidation probably easier. If projects
more than this, then even having multiple files per project is not out
of the question.

The good news is that Project can handle all these roll ups like this
relatively easily. It's all helped by using shared resource files which
I hope you are using.

Hope this is useful to you. Let us know.

rms

 

[Conrad Santiago]

Thanks for the input, Rob
Now, you have me wondering. Our PM files range from 200 to 1000 tasks. Each project ranges from 20 tasks to 75 tasks. I'm surprised I'm not having more problems. I'd be interested to hear your experiences that led you to these guidelines

Are there other benefits? With one project on one file, can I do things with it that I can't do when there are multiple projects in one file?
One example (which I couldn't figure out how to do anyway) was to give the task bars of a project a different color, so that I can distinguish them in a balance view. Can you give settings to a project if it is in one file that will show up in other views


----- Rob Schneider wrote: ----

I guess it all depends on how the PM's handle their own portfolio of a
dozen projects and whether they prefer consolidation or segregation of
files

You ---+-- PM
| +--------+--- Project
+ +--- Project
+ +--- Project
+ +--- Et
+-- PM
+ +--------+--- Project 1
| +--- Project 1
| +--- Etc
+-- Etc

I would think that each PM would find their own benefits of using
individual files for individual projects ... all depends on how many
tasks for each file. Everyone has their own preference. I personally
like (for many reasons--some logical and others just opinion/experience)
to see no more than 100-300 tasks per file. If these projects are
modeled by 10 tasks, then consolidation probably easier. If projects
more than this, then even having multiple files per project is not out
of the question

The good news is that Project can handle all these roll ups like this
relatively easily. It's all helped by using shared resource files which
I hope you are using

Hope this is useful to you. Let us know

rm




Conrad Santiago wrote

 

[Rob Schneider]

Well, as I said, it's just my opinion/view ... not hard and fast rules
.... I'll elaborate:

1. File Size: when files get too big, hard to email and handle, take
longer to open and close and (heaven forbid) when they get corrupted or
otherwise fail less is lost that requires fixing (backups essential).
2. File Complexity: too much data (tasks) in a project file make it
hard for user to use, especially when unconnected/unrelated information
is clogging up things. Smaller files helps with people who are reluctant
or don't want to use Project (for whatever reason) by keeping the data
need focused on things they *do* or *should* care about (given their
project responsibilities).
3. Organsiation: splitting up files to match the organisation allows me
to "divvy-up" the project files in line with how the work is allocated.
People can work on their own piece of the project without interfering
other pieces, either on line via the network, or remotely and
collaborate by exchanging project files via email.

Re "with one project in one file, can I do things with it that I can't
do when there are multiple files" ... can't think of anything really
since even with many individual files, you can put them any or all of
them into a master file and from that perspective they are one and the same.

No matter whether you have fewer big files, or more smaller files, you
still have to watch versioning and insure old files don't over-write new
files (if that how you are exchanging). A process or method to check
in/out files helps a lot.

Hope this is useful to you. Let us know.

rms

 

[Steve House]

One advantage from having the individual projects resident and managed in
their individual files with a consolidation file displaying the "big
picture" is it makes indentification and managment of each project's
critical path easier. A "project" is defined as the set of activities that
produce a unique product or result. When I look at a project's file, I like
to see the activities that go into that result and that result only - no
other projects, no "overhead", no administrative activities thyat do not
contribute directly to the project deliverable.

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

Thanks for the input, Rob.
Now, you have me wondering. Our PM files range from 200 to 1000 tasks.

Each project ranges from 20 tasks to 75 tasks. I'm surprised I'm not having
more problems. I'd be interested to hear your experiences that led you to
these guidelines.

Are there other benefits? With one project on one file, can I do things

with it that I can't do when there are multiple projects in one file?

One example (which I couldn't figure out how to do anyway) was to give the

task bars of a project a different color, so that I can distinguish them in
a balance view. Can you give settings to a project if it is in one file
that will show up in other views?

----- Rob Schneider wrote: -----

I guess it all depends on how the PM's handle their own portfolio of a
dozen projects and whether they prefer consolidation or segregation of
files.

You ---+-- PM1
| +--------+--- Project 1
+ +--- Project 2
+ +--- Project 3
+ +--- Etc
+-- PM2
+ +--------+--- Project 13
| +--- Project 14
| +--- Etc.
+-- Etc.

I would think that each PM would find their own benefits of using
individual files for individual projects ... all depends on how many
tasks for each file. Everyone has their own preference. I personally
like (for many reasons--some logical and others just opinion/experience)
to see no more than 100-300 tasks per file. If these projects are
modeled by 10 tasks, then consolidation probably easier. If projects
more than this, then even having multiple files per project is not out
of the question.

The good news is that Project can handle all these roll ups like this
relatively easily. It's all helped by using shared resource files which
I hope you are using.

Hope this is useful to you. Let us know.

rms

come from our six project managers. Each of them has one file where they
manage their projects under summary tasks. In all, there are about 80
projects.