none
Sub-Projects - "Break it down Man" RRS feed

  • Question

  • As a fairly new P.M., I have been working on a rather large office move project (i.e. planning/scheduling the move of 300+ staff as well as the tenant improvements at the new location), and have come to a point in the planning phase where I think I should be breaking the project (i.e. scheduling) down into sub-projects (i.e. right now there are too many tasks (work packages), some tasks will take weeks/months to complete, too long and convuluted network diagram, too long Gantt chart etc.).

    So my question is, when you have to break down a single large project into sub-projects - how do you do this while still tieing the overall project together? I plan to make separate schedules (i.e. Gantt charts etc.) for each sub-project, yet still maintain a single projcet charter. But how do I tie all the separate sub-project schedules (I estimate there will be 5 or 6 sub-projects) together in a single place (document) to see/track the progress of the overall project?

    I am using a single copy of MS Project 2007 Standard.

    Any sites/documents/books/.pdfs you can recommend on this issue would be appreciated.

    Thanks in Advance for your assistance/advice

    Friday, August 12, 2011 5:49 PM

Answers

  • Zvonk,

    You're welcome and thanks for the feedback.

    To address Andrew's comment about not renaming or moving files, file linking in Project is rather fragile and prone to corruption if the user doesn't follow very rigorous file management techniques. In an ideal Master/Subproject structure all files are in the same folder and are located on the user's local hard drive. If one or more of the files in that structure is moved to another directory the link information can get lost or partially compromised. Similarly if the user decides to start renaming files, the link information can also get lost or be compromised. If the user periodically "saves off" a copy of one of the files it can duplicate the link to that file and again, compromise the link structure. Any one of those actions can be the start of link structure corruption. It may show up as total structure failure or it may be more subtle and start causing weird things to happen with the files.

    Be safe out there.

    John

    Friday, August 26, 2011 3:07 PM

All replies

  • You probably want a master project.  Create a new project, then (and I can't
    remember where it is in 2007) insert the subprojects, which in this case
    would be your individual MPP files.
     
    Save it and you're fine as long as you don't move the files or change their
    names.
     
     

    Andrew Lavinsky [MVP] Blog: http://azlav.umtblog.com Twitter: @alavinsky
    • Proposed as answer by HFprojects Wednesday, January 20, 2016 3:44 PM
    Friday, August 12, 2011 6:07 PM
    Moderator
  • Hi Zvonk,
     
    Welcome to this Microsoft Project newsgroup :)
     
    You might like to have a look at my free series for beginners on Microsoft Project in the TechTrax ezine, particularly #17 & 18 on multiple projects, at this site: http://tinyurl.com/2xbhc  or this: http://pubs.logicalexpressions.com/Pub0009/LPMFrame.asp?CMD=ArticleSearch&AUTH=23
    (Perhaps you'd care to rate the articles before leaving the site, :)  Thanks.)
     
    FAQs, companion products and other useful Project information can be seen at this web address: <http://www.mvps.org/project/>
     
    Hope this helps - please let us know how you get on :)
     
    Mike Glen
    MS Project MVP
    Friday, August 12, 2011 6:49 PM
    Moderator
  • Zvonk,

    Andrew gave you the last step in your process but your first step is to take the existing large file and break it into manageable parts.

    It is fairly easy to break apart one large file but existing task links complicate the process. You will have to create cross project links (i.e. external predecessors/successors) to replace normal predecessors/successors that now exist in your large file. I'm making the assumption that your large file is lone large linked network. I would do the following:

    1. Decide exactly where the most logical break points exist. Try to pick break points that will result in the least number of cross-project links.

    2. Once the break points are determined, add two extra text fields to your view. These will be used to hold cross-project link data as an aid in setting them up after the breakup. One extra field will contain an identifer of the link source. The easiest approach is to fill the field with consecutive numbers. The second field will contain an identifer of the link destination (e.g. the number or numbers from the first field if there are multiple successors).

    3. Save the prepped file. Then re-open it and Save As to as many new filenames as you need for subprojects (you indicate 5 or 6). Before you save each new file under its new name, delete all those tasks that will not be in that particular file.

    4. Now you are ready to establish your cross-project links. The easiest way to do that is by creating a new blank master and inserting all your subprojects. Also open each of the subprojects. Using the link data you saved in the text fields, in the master locate cross-project tasks to be linked and then either drag a link line or use the link icon. I recommend you save both the source and detination subproject files after each link operation but you could do a few, save and then do a few more.

    Now you have a dynamic master/subproject file structure. Do no rename, move or periodically save off copies or you will risk corruption.

    There, how's that for a fun Friday afternoon activity.

    John

    Friday, August 12, 2011 7:12 PM
  • Hey Zvonk,

     

    The previous answers, probably explained enough how to (technically) handle with master and sub projects.

    But I think this was not you question! Your question was: "So my question is, when you have to break down a single large project into sub-projects"

    I assume we are at the point where you desided that your file became too big...

    I decide about the breakpoint based on the fact that tasks belong in some way together (Kind of managable work packages).
    As such my main criterion to split, is manageability.

    If you don't need to manage all the information from the original file together all the time, than split the information in smaller files and keep information together where you want to manage it together (Pfff hope you understand what I mean).

    Desiding the split on technical basis seems not OK to me: In case you go for the breaks with minimal cross-project links (see above), you will end up with tasks for the same work context, residing in different files?!? And since you cannot insert files in more than one master project, you will not be happy ;)

    Of course, your question did not ask for a "binary" (Black/White) answer, but I recommend considering Manageability as criterion to split! As always, probably the truth is somewhere in the middle...

     

    Regards
    Wim

     


    Thursday, August 25, 2011 6:16 PM
  • Thank You Wim (sorry for the late reply).

    Your advice is welcomed and helpful - much apprciated.

    Friday, August 26, 2011 2:29 PM
  • HI John, and Thank You (sorry for the late reply).

    Your detailed advice is helpful and appreciated. I will be trying this and will follow-up if I have further issues.

    Friday, August 26, 2011 2:33 PM
  • Hi Mike,

    Thank you - I have downloaded the files and I am in the process of reviewing this information. I can see from first glance that there is a lot of helpful information there - much appreciated. I will follow-up if I have any further questions/issues.

    Friday, August 26, 2011 2:36 PM
  • Thank You Andrew for the advice. Not sure what you mean by "you're fine as long as you don't move the files or change their names"? - What happens if you do?
    Friday, August 26, 2011 2:38 PM
  • You're welcome Zvonk!!

    Can you click the "Mark as answer" button to close this thread?
    And if you want, you can mark answers with "Vote as Helpfull...

     

    Regards
    Wim

    Friday, August 26, 2011 2:56 PM
  • Zvonk,

    You're welcome and thanks for the feedback.

    To address Andrew's comment about not renaming or moving files, file linking in Project is rather fragile and prone to corruption if the user doesn't follow very rigorous file management techniques. In an ideal Master/Subproject structure all files are in the same folder and are located on the user's local hard drive. If one or more of the files in that structure is moved to another directory the link information can get lost or partially compromised. Similarly if the user decides to start renaming files, the link information can also get lost or be compromised. If the user periodically "saves off" a copy of one of the files it can duplicate the link to that file and again, compromise the link structure. Any one of those actions can be the start of link structure corruption. It may show up as total structure failure or it may be more subtle and start causing weird things to happen with the files.

    Be safe out there.

    John

    Friday, August 26, 2011 3:07 PM
  • You're welcome, Zvonk :-)

    Mike Glen
    MS Project MVP
    See  http://tinyurl.com/2xbhc for my free Project Tutorials

    "Zvonk" wrote in message news:2e2cd14b-19d6-4f5c-a3d8-0dbf85a630ee@communitybridge.codeplex.com...
    Hi Mike,

    Thank you - I have downloaded the files and I am in the process of  reviewing this information. I can see from first glance that there is a lot of  helpful information there - much appreciated. I will follow-up if I have any  further questions/issues.

    Friday, August 26, 2011 4:05 PM
    Moderator