Sensible limits for subprojects?

[matthills10]

Hi,

I'm (still!) using Project 2000 and have a project file that breaks
down into around 30 distinct 'work packages'.

I need to devolve ownership of these work packages to individual
project managers, so splitting the single project file into a master
and subprojects seems to be the way to go. This will allow the work
packages to be managed as seperate files and will show each project
manager the dependencies they have within the overall project but
external to their own work package.

Each subproject will be relatively small (probably around 100
activities) and there will be a shared resource pool of approximately
80 resources.

My question is: Is this a reasonable way to proceed, or am I likely to
hit problems with this many subprojects and/or resources shared across
them? Any advice or comments from experience most welcome.

Thanks,

Matt

 

[Jim Aksel]

This is not unreasonable, you can have one .mpp file per work package and
assign the work package to one Control Account Manager. If you have the same
CAM for multiple work packages, you can group the packages into a single file
with sections, although that architecture might get tricky.

I recommend the following, based on a lot of experience.

1. Keep the files in a single folder. Do not let the CAMs run amok with the
updates, you will do better having a scheduler do the updates. Since there
will be interproject (file) dependencies you could easily pollute the links
between the files if the CAMs are not very careful. Number one problem will
be a CAM will pull a copy of his file out onto his desktop and then open it.
If they save it to their desk top, or use Save As... the links get corrupted
(duplicate links are created). Once you create your schedules, never ever
use "Save As..."

Create a folder with the schedules in it. The schedule then becomes the
entire folder, never an individual file. If you want to move (copy) the
scheulde you need to take the entire folder.

2. In each of the 30 files establish Giver/Receiver milestones at the top of
the file. Each CAM has "What I need from others" and "what I give to
others." By definition, that is a work package inputs/outputs. Only link
into or out of the work package file from those milestones. It makes it
easier to trace problems. We even put master milestones into the master.mpp
file and link that way too.

Giver Milestones exit the file. They have predecessors that are internal
links and successors that are external links. No exceptions.

Receiver Milestones enter the file. They have external predecessors that
drive internal links that are successors. No exceptions.

All other tasks have predecessors that link only internal to the single work
package file. No exceptions.

3. Name your milestones and tasks carefully. When you go looking to see who
is drivng the schedule to make it late you will find some task "Unit Test"
and you will have 30 of them of which two will be late. The trouble is to
know which file "Unit Test" came from. Easier if you name the task: "Print
Function Unit Test Complete"

If you are familiar with Integrated Master Plan (IMP/IMS) I strongly suggest
it. I have mor info on that, it is just a numbering scheme.

That is just a start, I live this every day with up to 90 files. If you
would like more input, feel free to post back. I am going to go out on a
limb here as well... if you dig into the link below you will eventually find
some good contact information for me. I would entertain your contact. FYI.
I am in Los Angeles.
--
If this post was helpful, please consider rating it.

Jim

Check out my new blog for more information:
http://www.msprojectblog.com

 

[matthills10]

Jim,

Many thanks - I'm greatly reassured that this works for you. Your
conventions on dependencies between work packages also sound like
something we should consider.

My secondary concern is that I may have problems using a shared
resource pool across this many project files - is this something you
have experience of and does it work ok for you?

Thanks again

Matt

 

[Jim Aksel]

We have 56 resources in a shared pool. Works fine for over 100 files for us.
Again, keep Resource.mpp in the same folder with all its friends.

One thing to consider. If Resource.mpp is used for many projects (we are
describing one project in this chain), it is best to keep it in its own
separate and sacred location. At that point we are verging on a Project
Server implementation. If you keep Resource.mpp dedicated to the one
project, I see no problems at all. We occassaionally do checks into the
Project.mpp files to make sure someone doesn't sneak in a local resource.
Other than that, enjoy.
--
If this post was helpful, please consider rating it.

Jim

Check out my new blog for more information:
http://www.msprojectblog.com