none
Sub projects or Not RRS feed

  • Question

  • I came part way into a project and was handed a project plan with multiple workstreams most of which are going in parallel. They are all lumped into a single plan. Issue is business would prefer to see the milestone lists/timeline etc separately for each which makes it cumbersome to derive every time. My question is 2 part..

    1. How can an existing plan be divided into multiple plans - Cut/Paste? Feels like there should be a better way. I have seen many forums on vice-versa.

    2. How have you handled multiple workstreams or modules for a project in the past - same plan or multiples? Pros and Cons appreciated.

    Tia

    Thursday, October 16, 2014 5:12 PM

All replies

  • Hi Tia,

    First question: can you confirm that you're working with MS Project Standard and not Profesionnal, as I can assume from the forum you posted in? My advice below is assuming so.

    1. You could make as many "save-as" as the number of sub-projects required. Then for each one, simply delete the rows that are not part of the sub-project's scope.

    2. The pros and cons are quite a big topic..

    Cons:

    • If you're using standard version and if you need to link tasks between sub-projects, you'll have to create physical links between sub-projects which could increase the complexity.
    • If you have to many sub-projects, you could have performance issues, even corruption.
    • It could trigger that you'll too much detail in each sub-project, making the project tracking much more complex.
    • ...

    Pros:

    • On the contrary, the scope might be better managed if splitted into sub-projects and assign to project managers.
    • The roles and accountabilities might be clearer.
    • If this is a program rather than a project, using sub-projects and a master plan will reflect the program governance.
    • ...

    Hope this helps,


    Guillaume Rouyre, MBA, MVP, MCP |

    Thursday, October 16, 2014 6:01 PM
    Moderator
  • Tia,

    Guillaume summed it up pretty good but let me add a few more comments.

    How large is the plan (i.e. number of tasks and resources). If it is a few hundred to a couple thousand tasks you might be better off leaving it as is and using filters or grouping to create separate list reports. However if the current plan is several thousand tasks, then yes, it could be more manageable to break it into separate plans.

    However, if you do break the large plan into several individual plans there is a safe way and not-so-safe way to recombine them for reporting purposes. if you use the Project/Insert subproject method, by default Project will create a dynamic master, meaning that you will have a linked structure and that's where the not-so-safe comes in. Linked structures in Project are very susceptible to corruption. You must never move, rename, overwrite, or save off any of the files in the structure. If you need to combine all the plans together for reporting/analysis, you can create a static master by unchecking the "link to project" option in the lower right corner of the Insert Project window. That effectively creates a snapshot in time of all the plans in a new single file.

    If you have dependency links between tasks in various workstreams, then you will need to re-create those as external predecessors and successors between each of the individual subprojects. Doing so increases the complexity of the linked structure and unfortunately also the possibility for corruption. In addition, you will no longer be able to simply create a static master because the cross-project links will not be preserved however a macro can address that issue.

    In direct answer to your second question, I've done it both ways. Individual plans are generally easier to maintain but a general caution is that if you intend to have multiple individuals involved in managing those plans, a good set of groundrules and training are essential. On the other hand, a single large plan can be more difficult to manage but there are ways to minimize the extra bulk.

    Obviously, there are many things to consider.

    John

    Thursday, October 16, 2014 7:17 PM
  • I always recommend a schedule stays in one file until either it is too cumbersome or two or more people need to work on different parts of it.

    I regular schedule projects with multiple streams. I simply insert a Text field such as Text1, rename it Stream and setup a lookup table of the stream names. I then enter the stream name against all tasks and filter by stream for reporting purposes. Easy!


    Rod Gill
    Author of the one and only Project VBA Book
    www.project-systems.co.nz

    Friday, October 17, 2014 4:21 AM
    Moderator