Andrew,

we uaually include reporting requirements in the contracts. In most projects actual data is collected weekly.

Project interdependencies can include logical dependencies between activities of different projects, common resources, common financial constraints and common space constraints. Project schedules that ignore these constraints and dependencies are not feasible. It is necessary to calculate the schedule of the portfolio for obtaining reliable schedules of all projects that belong to this portfolio.

With different data dates the portfolio schedule must be calculated from the earliest data date. For projects with later data dates the schedule will be correct only if the projects with earlier data dates will be done exactly as planned at the periods from one data date to another. This assumption is very brave.

Vladimir,

It’s absolutely normal to have interproject relationships and yet re-schedule each Sub-Project to its own data date with all interdependency respected.

You can even enable/disable interdependency when re-calculating.

The only limitation when scheduling the portfolio is to how to define Criticality and the float Calculation – based on an individual project or on all projects:

I agreed that in an ideal world you would prefer having the same data date for the portfolio but in many cases, the sub-project is owned by different parties which usually have a different procedure regarding how the schedule is updated (for instance in Ontario it’s common for Subs to close the progress 1 week before the month ends, but Contract calls for Gen Contractor to report on the last cal day of the month).

v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} Normal 0 false false false false EN-CA X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin-top:0cm; mso-para-margin-right:0cm; mso-para-margin-bottom:8.0pt; mso-para-margin-left:0cm; line-height:107%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri",sans-serif; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:EN-US;}

Like what I have mentioned, depending on the project requirement and setup. A good example is the mega project that we are managing where the design are done in Thailand, Fabrication and manufacturing are done in different countries such as Germany, China, France and Philippines, the actual project is in West Africa, the PCM in Australia and stakeholders are in Abu Dhabi. I have a different projects setup in one portfolio where data date are difference from each other. Some activity dependencies are from different projects. Due to pandemic, resources are limited to each country. Each project are being update on different location and manage in Australia. In P6 release 20, there's an option that can shedule the portfolio project's with a different data date.

One of the reasons to have multiple projects in the portfolio is when each sub-project has different requirements with regards to update. Let's say Design/Procurement is updating monthly and construction is bi-weekly.

In the portfolio, each project can have its own Data Date.

Also, each project can be analyzed separately (critical path can be defined per each project (based on TF or LP).

Easier to manage privileges too. In order to overcome external relationship constraints - the portfolio should be exported as one package (XER/XML).

John, some random un-ordered musings about your questions:

Using Multiple Projects

1. If you organise them by WBS, each project ID will the top level of the organisation hierarchy so you'll never see the projects grouped together
2. You'll need to maintain each datadate to be aligned if you want a single report
3. There is the risk the risk that inter-project relationships will drag across multiple versions of schedules
4. To have a common grouping you should use Global and/or EPS level activity codes rather than project level activity codes
5. If you want to use project level calendars acorss projects, you'll need to create/maintain multiple versions of these, or just use Global calendars to avoid this.
6. Activity ID's may get duplicated across multiple projects - this can create problems if you're reporting externally. The simple solutions is to prefix the activity ID's to identify which project they belong to
7. May be more useful if you have multiple schedulers using the data

Using Single Project

1. Easier to open and work with one single schedule
2. No issues about inter-project relationships
3. No chance of duplicate ID's
4. Can create problems if multiple users are required to access the data
5. Might make the schedule large - which might end up requiring additional filtering/grouping/sorting etc.

Me personally would always go with one single schedule, and ensure I had sufficient flexability using Activity Codes to produce the outputs as required.