MS Project Server 2003 - Multiple Projects

[Gil Grissom]

I have 4 separate project managers reporting to me, each on a different
product line. They manage from start to finish the building of their
respective products. Each product requires time in manufacturing (the
shop) which is budgeted into the schedule.

I would like to install Project Server in an attempt to have some sort
of over-view of the respective projects, even though they aren't
directly related; i.e. the only thing they have in common is that they
use the same shop. I also want the PMs to make changes to their
projects in a centralized repository which offers login capability and
rights management so that many people can login and see the project but
based on their permissions, can only modify certain parts of the
project; e.g. marking their own areas with updated status.

The overview should show ALL the projects combined on one schedule or
have the ability to show just certain phases of each project on one
master schedule. This way, my manager of operations for the shop can
see what work is coming down the line, Engineering can see all the
projects coming down the line and currently in progress, I can see how
the production cycle of all the various products inter-relate as far as
resource consumption, etc.


Does Project Server have this capability?

 

[Gary L. Chefetz [MVP]]

Best answer is yes and maybe. To the degree that we can generalize using you
high-level requirements, it would seem that Project Server can do what you
want provided you have the expertise to configure it and apply it correctly.
Project and Project Server are ideal for product development projects.
They're also useful for controlling custom and semi-custom manufacturing
processes all the way to the shop floor level if weekly management cycle
times are reasonable. Without regard to manufacturing cycle times, you can
certainly measure demand at the level you described given just about any
scenario.

 

[John Sitka]

even though they aren't
They use the same shop thus they are intimately related. They have to share the shop
and each resource(s) contained there. Thus you need to define just what are the boundary's
of your resources. Are they work cells, individual machines, the whole shop at once.

Then model how you are going to get those resource definitions to report, How often? by who?

Now consider the dynamics for the Project Managers. They will be constantly constrained by
this conflict for competeing resources. Thus their schedule must be reactive to the goings on of
the resources. Obviously they want to have the resources when they want them but it will not
happen. In other words they are totally subordinate to the shop and competeing projects.
Many will deny this and be convinced they are in fact constrained by "dates". This is not true.

As a first step build a project called shop that does nothing but handle the single shop resource.
That "shop" takes on project tasks. Someone logs into PWA as "shop" and submits
actuals to the current tasks. A project manager could log into the shop project as well and add a task which would go to a
"shop" scheduler. This scheduler would add tasks to the shop project and let project set the dates for them. Then each Project
manager
adds an external link from their project plans to the their task in the shop project schedule. The shop project
is constantly updated and leveled so it is never overallocated and thus will not give incorrect or unachievable results to
the project managers.
See a shop scheduler may have it set up like this.....

PM1 task
PM2 task
PM3 task
PM4 task

at the end of the day PM1 may have accomplished 6 hours work. But the shop itself may be an
extremely complex entity under the covers. There may be a huge group of individuals and resources contributing
to that 6 hours. But on the whole the shop scheduler decides that 6 hours 100% shop time was gained
on that project task today. He also noticed that in his complex world a work cell got a jump on PM4 task.
He records 2 hours 100% shop time progress on this task even though it is not even the current task and it wasn't
on the radar, that is part of the reality of how things go. The shop scheduler made a decision to allow work to be done on PM4
once he realized that PM1 could not get 8 hours of work done on it. For whatever reason. That is his expertise at
viewing a complex system. This is an abstraction of what actually goes on but it is still extremely valuable at the project manager
level because he is getting daily evaluations as to progress. Not just wishfull thinking that what was said
last week still holds true. The hard part is defining the level of assignment detail that works for you, and how many links
a project manager needs to get a good idea of what is going on. Each resouce needs a dedicated scheduler
to create to do lists (one scheduler can handle many resources), 4 competeing project managers
(unless they sit in committee everyday and act as one voice) will probably not be in agreement as to
when their tasks get done.

Now a single "shop" resource may not be near enough detail for any practical purpose so each resource
definition may need to be more specific. The same technique applies, maybe the "shop" project is the tracking
point for 4 distinct resources, maybe 100?. The point is you are enabling dynamic constraints to be applied to the
project manager projects without them confounding each others efforts
by making them responsible for the levelling of the resources. Which they probably have quite a disconnect from.
If they all understand each others projects as well as their own, and come to agreement about each strategic move
across all projects you could level resources from those projects directly. But it would be near impossible to get that
agreement I would think.