Hi, I have been tasked with creating a top-level project schedule (which I will maintain) and linking it to several seperate ““child”” schedules (that others will maintain). In the past, I have been attempting to fold in everyone’s elses schedules into mine which ends up being too complicated and error prone (and always out of sync with the child schedules since they are changing daily). Can anyone recommend a good solid approach to doing this? Is there any MSProject companion software out there that might assist me? The ultimate goal is to be able to view everything that is going on among these multiple schedules in ONE easy to generate view. Thank you much and Happy Holidays.
Thats correct palford,
You can either create tasks or milestones in the links schedule that the other schedules link into.
From: ms-project-l@Groups.ITtoolbox.comTo: colin_standen@hotmail.comDate: Tue, 5 Feb 2008 16:50:13 +0000Subject: RE:[ms-project-l] Linking MSProject Schedules Together
Colin Am I right in thinking that you create a task in the links schedule, that you link to and from in the individual plans? If so I am not sure how a change in date won’t affect the latter plan? Thanks
Colin
Am I right in thinking that you create a task in the links schedule, that you link to and from in the individual plans? If so I am not sure how a change in date won’t affect the latter plan?
Thanks
Regarding Task ID numbers getting screwy. I agree, they do. I rely on the “UniqueID” field instead, which never changes.
Friar
Colin:
Very interesting idea. I like the idea of your links file as a dashboard.
- I’ll definitely try it out.
Paul
I have exactly the same org structure.
I have several PMs that are responsible for their separate schedules, but need to create a master interlinked schedule without removing the PMs responsibility or control of their schedules. To do this i have the following solution.
i have created yet another schedule that i have called my Links schedule. It sits between any links i create between schedules. ie for a interproject dependency project A is linked to the Links schedule and then from the Links schedule to Project B. Tasks in the Links schedule are all deadlined. So if a PM changes a date so it affects another PM the links schedule displays a red diamond in the indicators field showing that this task has changed and affected anothers. This stops a PM saying that they no longer have control over their schedule and yet keeps them in Sync. The tasks are not straight dependencies but contrained so that one schedule doesn’t affect anothers. The Links schedule effectively acts as a warning dashboard. Also the functionality within project allows you to view all the links to other projects from the Links schedule. meaning you can monitor duplicate links to projects with different file names all in one place.
For archiving you can copy the folder that all the projects sit in without duplicating the links.
Hope that helps.
Colin.
Date: Wed, 19 Dec 2007 16:25:40 -0500From: ms-project-l@Groups.ITtoolbox.comTo: colin_standen@hotmail.comSubject: Re: [ms-project-l] Linking MSProject Schedules Together
Exercise this method with caution: line numbers get screwy, linking tasks between subordinate-to-master or subordinate-to-subordinate projects (a job itself) will generate dynamic links making version control difficult to maintain. Line numbers: The embedded schedule will show its own line numbers, not those of the master schedule. If you are teleconferencing and using line numbers to refer to tasks for discussion you have to orient the participants to the subordinate schedule. Linking Tasks: There is no good reason to put all the tasks together unless there are dependencies of deliverables, milestones, what-have-you. The only way i’ve found to link tasks across subordinate-to-master or subordinate-to-subordinate projects is to graphically click-and-drag from a predecessor task to the successor. This will establish a dynamic link between tasks. Once you created the dependency, open either successor or predecessor task and look at the pred or suc (respectively). You’ll see that the pathname/filename format with the line number at the end. If the path/filename lenght is long you won’t be able to edit it in the text field - in these cases I haven’t found a convenient work-around if you need to change dependencies. Version Control: To maintain proper version control many people (myself included) use a date identifier in the filename, which gets updated whenever the schedule is changed. Links between the various schedules such will generate external references that you will need to maintain. One way to simplify this headache: have your team leaders/PMs update their MS project schedules and then you copy their new files into your master directory using the original filenames. If you keep the same subordinate filename then there won’t be a problem with links to the master and you can maintain version control by creating a new folder for every version of subordinate and master files. If you want to maintain version control in the same folder and the change the subordinate filename, you will need to update the link either by editing the link directly (which won’t work if the filepath is long) or by opening the master file and subordinate files and saving the subordinates with new names to dynamically update the links. Note that the taskname of the subordinate file will NOT change in the Master file so you will need to update that text field manually (if you want to know to which version this subordinate refers). Occassionally you will find stray links to earlier versions in far off folders. You can delete those links. Just be careful! Not easy, not convenient, but ensures that depdencies between schedules are maintained. Good luck. Paul
Exercise this method with caution: line numbers get screwy, linking tasks
between subordinate-to-master or subordinate-to-subordinate projects (a job
itself) will generate dynamic links making version control difficult to
maintain.
Line numbers: The embedded schedule will show its own line numbers, not
those of the master schedule. If you are teleconferencing and using line
numbers to refer to tasks for discussion you have to orient the participants
to the subordinate schedule.
Linking Tasks: There is no good reason to put all the tasks together unless
there are dependencies of deliverables, milestones, what-have-you. The only
way i’ve found to link tasks across subordinate-to-master or
subordinate-to-subordinate projects is to graphically click-and-drag from a
predecessor task to the successor. This will establish a dynamic link
between tasks. Once you created the dependency, open either successor or
predecessor task and look at the pred or suc (respectively). You’ll see
that the pathname/filename format with the line number at the end. If the
path/filename lenght is long you won’t be able to edit it in the text field
- in these cases I haven’t found a convenient work-around if you need to
change dependencies.
Version Control: To maintain proper version control many people (myself
included) use a date identifier in the filename, which gets updated whenever
the schedule is changed. Links between the various schedules such will
generate external references that you will need to maintain. One way to
simplify this headache: have your team leaders/PMs update their MS project
schedules and then you copy their new files into your master directory using
the original filenames. If you keep the same subordinate filename then
there won’t be a problem with links to the master and you can maintain
version control by creating a new folder for every version of subordinate
and master files.
If you want to maintain version control in the same folder and the change
the subordinate filename, you will need to update the link either by editing
the link directly (which won’t work if the filepath is long) or by opening
the master file and subordinate files and saving the subordinates with new
names to dynamically update the links. Note that the taskname of the
subordinate file will NOT change in the Master file so you will need to
update that text field manually (if you want to know to which version this
subordinate refers).
Occassionally you will find stray links to earlier versions in far off
folders. You can delete those links. Just be careful!
Not easy, not convenient, but ensures that depdencies between schedules are
maintained.
Good luck.
Paul
Works beautifully. Thank you!
You can combine project plans into one master plan, while still maintaining the other plans separately. With your own Project file open, choose Insert/Project and select another person’s project plan (assuming you can access it on a network folder). Do the same with each of the other files you need to monitor. All of those “sub-projects” will appear within your master file, without you having to re-enter anything. The other users can still makes edits to their individual plan, but you will see those changes every time you open your master plan that contains their plan. Hope that makes sense.
