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.
Member for
20 years 11 months
Member for20 years11 months
Submitted by Andrew Podolny on Wed, 2022-01-19 16:37
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).
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).
it can be done only if to assume that after their data dates projects are performed in strict accordance with their plans that is not realistic.
It is the same as calculating project schedule not from the data date but from some date in the future.
The schedules created this way are not reliable.
For projects with the earlier data dates the software calculates their planned actual performance. Is it usual that the projects are done exactly as planned?
It is necessary to minimize the differences between data dates.
In your example each project used its own resources. In most cases projects that belong to the portfolios share limited resources, have common financial constraints and cannot be scheduled separately ignoring interdependencies.
Member for
19 years
Member for19 years
Submitted by Rodel Marasigan on Wed, 2022-01-19 00:48
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.
Member for
24 years 8 months
Member for24 years9 months
Submitted by Vladimir Liberzon on Tue, 2022-01-18 22:33
you wrote: In the portfolio, each project can have its own Data Date.
Activities of portfolio projects can be linked with each other, portfolio resources can be limited and there can be othe reasons why projects that belong to the portfolio cannot be scheduled separately ignoring their interdepencies.
So there is a need to schedule the whole portfolio for getting the schedules of all projects that belong to the portfolio.
It can be done only if all of them have the same data date.
Member for
20 years 11 months
Member for20 years11 months
Submitted by Andrew Podolny on Tue, 2022-01-18 20:56
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).
Member for
16 years 3 months
Member for16 years3 months
Submitted by Zoltan Palffy on Tue, 2022-01-18 14:09
the project id is what makes every project unique. If you copy one project into the other the project being copied will have the prefix of the project iid that it is being copied into. This is very evident in the wbs,
Member for
20 years 6 months
Member for20 years6 months
Submitted by Santosh Bhat on Mon, 2022-01-17 01:18
John, some random un-ordered musings about your questions:
Using Multiple Projects
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
You'll need to maintain each datadate to be aligned if you want a single report
There is the risk the risk that inter-project relationships will drag across multiple versions of schedules
To have a common grouping you should use Global and/or EPS level activity codes rather than project level activity codes
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.
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
May be more useful if you have multiple schedulers using the data
Using Single Project
Easier to open and work with one single schedule
No issues about inter-project relationships
No chance of duplicate ID's
Can create problems if multiple users are required to access the data
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.
Member for
19 years
Member for19 years
Submitted by Rodel Marasigan on Sun, 2022-01-16 23:17
Depending on the setup and project requirement. If setup using P6 portfolio or eps and project (subproject) you have to be aware that you can use same activity id, wbs, activity code, project code but you cannot use same layout on each project showing each activity code. It needs to define as Global activity code or EPS activity code and not per project. There are pros and cons using combine project vs eps and project (subproject).
Member for
24 years 8 monthsAndrew,we uaually include
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.
Member for
20 years 11 monthsVladimir,It’s absolutely
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;}
Member for
20 years 11 monthsVladimir,It’s absolutely
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;}
Member for
24 years 8 monthsRodel,it can be done only if
Rodel,
it can be done only if to assume that after their data dates projects are performed in strict accordance with their plans that is not realistic.
It is the same as calculating project schedule not from the data date but from some date in the future.
The schedules created this way are not reliable.
For projects with the earlier data dates the software calculates their planned actual performance. Is it usual that the projects are done exactly as planned?
It is necessary to minimize the differences between data dates.
In your example each project used its own resources. In most cases projects that belong to the portfolios share limited resources, have common financial constraints and cannot be scheduled separately ignoring interdependencies.
Member for
19 yearsLike what I have mentioned,
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.
Member for
24 years 8 monthsAndrew,you wrote: In the
Andrew,
you wrote: In the portfolio, each project can have its own Data Date.
Activities of portfolio projects can be linked with each other, portfolio resources can be limited and there can be othe reasons why projects that belong to the portfolio cannot be scheduled separately ignoring their interdepencies.
So there is a need to schedule the whole portfolio for getting the schedules of all projects that belong to the portfolio.
It can be done only if all of them have the same data date.
Member for
20 years 11 monthsOne of the reasons to have
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).
Member for
16 years 3 monthsthe project id is what makes
the project id is what makes every project unique. If you copy one project into the other the project being copied will have the prefix of the project iid that it is being copied into. This is very evident in the wbs,
Member for
20 years 6 monthsJohn, some random un-ordered
John, some random un-ordered musings about your questions:
Using Multiple Projects
Using Single Project
Me personally would always go with one single schedule, and ensure I had sufficient flexability using Activity Codes to produce the outputs as required.
Member for
19 yearsDepending on the setup and
Depending on the setup and project requirement. If setup using P6 portfolio or eps and project (subproject) you have to be aware that you can use same activity id, wbs, activity code, project code but you cannot use same layout on each project showing each activity code. It needs to define as Global activity code or EPS activity code and not per project. There are pros and cons using combine project vs eps and project (subproject).