Working with portfolios

Evgeny, thank you for noticing the problem with new versions. I will look at this.case 

Portfolio objects shall be synchronized by applying corporate standards, in particular reference-books. Project planners shall not create resources, they shall select required resources in the corporate reference-books. In Spider access rights there is an option when new objects may be taken from the reference-books but could not be created manually. In other case everything shall be checked and this will take too much time.

But cost centers at different projects may be different and the problem with different cost centers with the same codes we met at one of our customers. So we added this analysis when projects are consolidated.

To create new items you insert a line on the group it shall belong and automatically it is assigned. If job name is changed then the table shall be adjusted with new name and unique code recalculated. 

It looks like Spider Portfolios cannot differentiate if object [resources/materials/calendars ...] belong to a job or to whole portfolio. A separate field for these purposes is not there. A field whose value can be automatically determined. A field that could be used to generate/manage the unique codes. A field that could be used as to control how objects are distributed.

At some point this debate shall end so I am calling it quit on my part, guess we can agree to disagree.

Best Regards,

Rafael

If all project resources will be considered as project specific then in the portfolio you will find tens or hundreds project specific materials and resources that actually are the same.

• Yes, in my world contractors use crane resources on each of their jobs and its pool is project specific. One job might have 1 crane other might have 3 cranes other none. For a Government Agency portfolio project counts can be in the hundreds, jobs by different contractors that use whatever codes they want.

More than that, portfolio may consist of several subportfolios that share resources between projects that belong to them but not with others. The structure may be complicated.

• Agree.

Just imagine two models created by two contractors that build different objects. Their construction resources are project specific but materials are the same. 

• A job might have materials that are available for distribution to any portfolio member.  Say at company warehouse we have available grease for the machines of all jobs.
• A job might have materials that are available for distribution to a selected list of portfolio members. Say at local warehouse we have available grease for the machines at a specific region.
• A job might have materials that are only available for distribution to that job. Say at the jobsite we have available grease for the machines at the job.
• All materials might be same grease but represent different sources and different jobs.

Besides design for both projects is prepared by the same design company. So designers are not project specific and quality control is made by the same company, etc.

• Both project might have different designers, in this case project specific.
• Quality control can be done by different geographical divisions so the availability is different.

Another example - project portfolio consists of the projects that are performed by the same company. Some projects are done at the same location, others are at remote locations. Projects at the same location use common resources, but resources at remote locations are project specific.

• Of course this is one possibility.
• Funding can be common for all projects portfolio.

Evgeny,

This option may help project managers understand if they have some reserves (analogue of free float) between portfolio updates. Project schedule is still calculated at portfolio level taking into account portfolio constraints and project priorities. If urgent changes shall be made and scheduling that considers portfolio does not provide satisfactory results they shall apply to portfolio managers for the solution.

Best Regards,

Vladimir

Evgeny,

one of our clients is one of the largest Russian construction company that consists of many regional branches.

All of them calculate costs using the same cost component and cost center structure but with different formulas at their local portfolios levels.

Creating company portfolio we met the problem that the cost centers cannot be recalculated at portfolio level. We can only summarise costs of different projects in the portfolio. So local cost components and cost centers became local portfolio specific and cost centers of local cost centers were created in the company portfolio.

You are right that such verification is useful but it really will take a lot of time. I think that we shall create it but run not automatically but by request. It may be useful first time and when new objects were added but I expect that people will not happy if it will be always necessary to wait several minutes when Spider will check and compare data for many thousands objects when most of them are created by applying reference-books.

Regards,

Vladimir

Rafael,

when resources are created (or transfered from the reference-book) in some project it is not clear if the project belongs to some portfolio and which resources are shared and which are not. If all project resources will be considered as project specific then in the portfolio you will find tens or hundreds project specific materials and resources that actually are the same. This is the situation that shall be avoided. More than that, portfolio may consist of several subportfolios that share resources between projects that belong to them but not with others. The structure may be complicated.

Just imagine two models created by two contractors that build different objects. Their construction resources are project specific but materials are the same. Besides design for both projects is prepared by the same design company. So designers are not project specific and quality control is made by the same company, etc.

Another example - project portfolio consists of the projects that are performed by the same company. Sone projects are done at the same location, others are at remote locations. Projects at the same location use common resources, but resources at remote locations are project specific.

Regards,

Vladimir

Vladimir,

Now there is a question - if this resource is project specific or portfolio resource that may be used at jobs of different projects. Usually, it depends on location. If there are different projects that are executed at different locations then resource A is project specific.

• Agree and there shall be no issue if created at the project level or if created at the portfolio level as long as transfer of data considers the prefix as per the previously submitted rules.

If the jobs of resource A happen in the same location then A is portfolio resource.

• Agree I see no issue with this, I understood you talked about resource A happening on all jobs but it might still be that is happens only on some and it is still a portfolio resource. 

I don't see an easy way to determine this except setting some manual indicator as prefix to resource code or some symbol (yes or no) in specific field.

• Here I respectfully disagree, any resource created at project level is project specific, any resource created at the portfolio level can be a portfolio resource if when creating resources you add new resource under the group of portfolio resources and a project specific resource if under the desired project resource group it is inserted.

For the same project some resources may be project specific, others - portfolio resources (cranes are project specific, estimators may belong to portfolio).

• Of course; if on a portfolio the resource group will identify if portfolio or project specific, if on a job the portfolio prefix will identify from what portfolio it was transferred.

So decision if some resource (material, etc.) is project or portfolio object is based on the information that is not available in the project model.

• If created at a job level it belongs to that job, if created from within a portfolio it belongs to a specific job if created under the project resources group and belongs to the portfolio if created within the group of portfolio resources.
• To transfer portfolio resources from one portfolio to other this shall be done by transferring to appropriate resource groups. Different portfolios can share same projects and same resources. I believe it shall be easy using Reference Books.

Please be tolerant with me, if I have a few errors this is not easy for me and realize there are few things that are still pending, such as when transferring a resource other objects will also have to be transferred that might be or not project/portfolio specific. Anyway I am as error prone as any human being and therefore my constant quest to look for ways to reduce human error. A single resource/object code error can invalidate the whole portfolio. 

I do not recall how resources are created on a P6 portfolio, nor have an idea on how this issue is handled by Asta PP but I believe they use some resource structure to organize them in groups, Spider structure might be different.

Best Regards,

Rafael

In Spider Project portfolio may be created by adding any projects. These projects may be linked with different or common reference-books. Let's suppose that some resource parameters were taken from the same reference-book to two projects. Both use some resource with code A and the same properties like productivity and costs.

Now there is a question - if this resource is project specific or portfolio resource that may be used at jobs of different projects. Usually, it depends on location. If there are different projects that are executed at different locations then resource A is project specific. If the jobs of resource A happen in the same location then A is portfolio resource. I don't see an easy way to determine this except setting some manual indicator as prefix to resource code or some symbol (yes or no) in specific field. For the same project some resources may be project specific, others - portfolio resources (cranes are project specific, estimators may belong to portfolio).

So decision if some resource (material, etc.) is project or portfolio object is based on the information that is not available in the project model.

Bodgan,

Whenever a new object is created at a project level then it is a project object. Those created at the portfolio level can be defined as project or portfolio objects. This means some rules shall be established, it might be:

1. At project level - only project objects can be created or edited.

2. At portfolio level - project objects as well as portfolio objects can be created or edited.

3. When transferring file from project to portfolio the project prefix is added only to the objects that belong to the project to be transferred. The prefix will not be added to portfolio objects.

4. When transferring from portfolio to project the project codes will be deleted from those objects on the portfolio identified as belonging to the target project. Job objects will only be transferred to their respective jobs. Portfolio objects will only be transferred to the jobs that use them. 

It works for P6 with the restriction that all objects at job level must be job specific. These rules are less restrictive and allow transferring back and forth of portfolio resources without confusion, all automatic.  I see no reason not to automate it, though I know my idea is not going to the batting cage.

Evgeny,

Spider does not have a file comparison tool similar to Primavera Digger, we have a field comparison tool that requires you manually set it up in order to be able to see field comparisons, cell by cell. I rarely use it but at times is handy and better than a Digger style comparison, both are good ideas, they complement each other, we have only one.

Best Regards,

Rafael

Evgeny,

The data from reference books will can be set up to be always set for portfolio use by having the "Only for Project" option set to "No".

As for checking Spider would have to check all editable fields in order to be able to tell if there is a difference between objects consider this scenario: what if I use the following name for a resorce "Bogdan Leonte" and you change the name accidently to "Bogdan  Leonte" (Two spaces or any other accidental character) if you have tens of projects with hunderd of objects this would take long and may give tens or hundred items in a "Error report". This might be time consumig to sort through, perhaps I'm wrong.

Anyway, we are getting ahead of our selfs, let's see what Vladimir has to say.

Regards,

Bogdan

• Rafael, it is easy to indicate if some object is project specific or not just adding prefix to object code, or entering some synbol in user defined field. But this shall be done by people, not the machine.

There might be an easier way of creating project specific objects rather than using a formula.

If I may suggest, perhaphs a new column "Only for Project" with an "Yes", "No" option, plus a new project property "Object Prefix", "Object Postfix" and a checkable option "New objects belong only to this project".

If "Only for Project" = "Yes" then Object Prefix/Postfix would be written in the code column, else removed.

If "New objects belong only to this project" is checked then all newly created objects (except activities and excluding objects transfered from reference-books) would automatically get the Object Prefix/Postfix.

I belive that if this can be implemented, or something similar, then this would provide a middle ground solution between the way things are done now and how Rafael and Evgeny would like them to be.

Best Regards,

Bogdan

Rafael, it is easy to indicate if some object is project specific or not just adding prefix to object code, or entering some synbol in user defined field. But this shall be done by people, not the machine.

Vladimir,

I do not like the idea on the formulas for this task, many objects to remember to add a prefix . Not all codes will require adding the prefix on every update from external contractor using job distribution/consolidation, difficult to manage using additional fields that might not be correctly populated by our subcontractors.  As I see it only good for a one time transfer of codes or for when all users have access to the same CRB and portfolio file. 

I will abstain from using portfolios and the distribution/consolidation of jobs as much as I can. Too complicated for me and my clients the formula option on every transfer of files, it is not about formula creation, it is after it.  Anyway in my actual practice I have never used portfolios, I have never distributed any job for updating but use Excel to get updating data.

Now I am aware Spider will most likely never have a functionality similar to P6 to optionally define the objects using the project-specific option something we can handle, but P6 is not nor will be our choice. 

Best Regards,

Rafael

Evgeny, yes, you are correct.

The data from the corporate reference books may be transfered into projects without opening them. Different projects may be linked with different corporate reference-books. But if you don't want some information to be rewritten then just change activity (resource, material, etc.) type. The link of this specific activity with the reference-book will be lost.

Rafael, it is easy to modify codes using formulas. Some resources may be project specific, but others may be common. Some materials may be project specific but most of them are the same. It is easier to apply formula and add prefix to all project resource codes than to answer multiple questions when portfoliois are created. You know that in Spider Project you can create nultiple portfolios just selecting and adding projects to the portfolio. So if the project objects are unique run the script that adds project prefix to the object codes. When we start to implement PM system in any company the first thing we do is creating certain rules for project objects coding.

The decision shall be made at object creation; 

• if created within a Job outside a portfolio it belongs to the specific job,
• if created within a Portfolio then it either belong to the portfolio or to a specific job as decided by the creator.

Code creation and transfer of codes are rules that can be enforced automatically based on where the object was created.

Standard Reference books are a beauty to anyone using Spider, I just love them, Corporate Reference Books are a beauty for those limited to work within a single enterprise, but as soon as there is transfer of files to other enterprises it can become useless because there will be two Corporate Reference Books competing against each other. Do not miss my point about transferring project files and resources among different enterprises. In my case I and my Subcontractors create all jobs and resources as if each one belong to a different enterprise, as 100% stand along projects all might have Resource A but to be interpreted as different if merged into a single portfolio for funding purposes or even for reporting only. In no way I am ruling out CRB, I believe will still be as useful and compatible if code creation and transfer of codes are rules are enforced via some automation. 

Best Regards,

Rafael

We recommend to use reference-books but it is not mandatory.

If somebody creates two projects and sets the same codes for Concrete then by default we suppose that is the same material even if the names are different. In more complicated case the cost may be also different (if projects are at different locations) and in this case we suggest to use different codes and create material center Concrete to provide necessary reports.

Some machine may be shared between different projects or different machines of the same type are used in different projects. In the first case the code is the same, in second case codes shall be different and resource leveling will know that these machines are different and will not jump from one project to another.

This informtion shall be entered by people. Even if the machine properties were taken from the corporate reference-book its code shall be modified if it belongs to specific project.

When portfolio is consolidated and some errors were discovered it is not hard to make changes and repeat consolidation. Answering hundreds of questions on resources, materials, calendars and other objects codes may become time consuming and boring. Deciding if resource is common or project specific is human responsibility and I don't see the way to automate this decision.

Hope this makes sense, if there can be a manual algorithm I believe a computer shall be able to automate it.

Best Regards,

Rafael

Vladimir,

of the top of my head why not create a more detailed transfer options for transfering objets from projects to portfolios and vice-versa.

Portfolio to Projects:

[[wysiwyg_imageupload:1955:]]

And for transfering from projects to portfolio perhaps this can be set up from the User Access Rights?

This would require more timp to set up, but I think it would give better control to the data/objets that are transfered.

What do you think?

Yes, there is a problem when different planners use the same code for different cost centers, calendars, resources, etc.

But there is another problem if people use the same calendars, the same resources, the same materials and the same cost centers but the software considers them as different. If there are hundreds projects in the portfolio we'll get hundreds resources instead of one and leveling will not work.

So usually companies create some rules for creating codes for project specific objects, like adding certain prefixes that are added automatically when activities are merging. I don't see how this process can be automated because the software cannot distinguish between portfolio and project specific objects before the portfolio is even created. But the problem still remains. Just imagine that at different projects indirect costs are calculated using different formulas. In this case we cannot recalculate it in the portfolio. The same with cost centers that in different projects may consist of different cost components. At the moment we suggest to make cost center calculations at the project level and in portfolio use the results. But still there are the ways for improvement like importing and using project specific formulas. We are thinking about the best ways to deal with these problems and any proposal is most welcomed.

Best Regards,

Vladimir

I do not believe creation of resources, calendars and activity codes [implemented in Spider via user defined fields] are frozen in time, they are alive and continuously changing, so in order for it to work flawlessly in sync with Corporate Reference Books they shall be updated on real time and everyone shall be connected to the Reference Books.

In my world every contractor and subcontractor usually create their schedule detached from a common server. Imagine such requirement when the common server is to accept different software. The mere idea of limiting myself to create my own schedules within a government agency computer as to avoid conflicts is disgusting. 

All my sample jobs have a resource named A, some also have a resource named B, what a mess, Spider should create new resources using a name never before used. At home there are over 20 Rafael Davila on the phone book and over 200 Jose Hernandez, if using first name only it grows exponentially. 

Either I am missing something or in my world the Reference Books methodology will not make it. Project-specific activity/calendar codes option available in P6 looks better than the Corporate Reference Books methodology to prevent duplicate codes, and I was hoping for something superior. 

Best Regards,

Rafael

Hi, I am sorry for the absence for quite a long time.

I saw that a lot of portfolio management features were discussed.

I will describe some rules that shall be followed working with the project portfolio.

1. Activity and phase codes may be project specific, Spider understands that activities belonging to different projects may have the same codes and adds prefix automatically when portfolio is consolidated.

2. Activity types do not get prefixes. If activity types are the same Spider supposes that activity parameters are similar. Activity type is usually a connection field for the link with the reference-books. If activity shall not be modified by the data from the reference-book it is necessary to assign specific activity type that is not present in the reference-book.

3. When projects are consolidated Spider considers resources, materials and other objects (except activities) as the same if they have the same codes. That is why we suggest to use corporate reference-books creating objects in different projects. In other case different materials with the same code will be considered as one material, the same materials with different codes will be considered as different materials. The same with other objects. If it is not  true object code shall be modified.

4. To avoid confusion we suggest to use access rights to some objects that are called From the reference-books only. In this case the user cannot create new resources (materials, etc.) except transfering them from the corporate reference-books. Thus we may be sure that the same resources (materials, etc.) have the same codes.

5. We cannot consider objects from different projects as different. In this case a lot of new objects will be created though they are the same and there will be problems with scheduling and reporting (resource leveling in particular).

Thank you for founding an error in project leveling considering portfolio. It was fixed though testing is required.

I will look to other discussions that I missed.

Best Regards,

Vladimir

Evgeny,

Any way, I think we need to wait for Vladimir to look at this.

• I agree, as I understand it a prefix is always added ONLY to activity ID code and project name, it is a matter of adding this to other appropriate fields and 50% is done, the rest shall be on identifying calendars and other fields to be transferred when needed on a controlled way, and this mean either asking for what is to be transferred back/forth and via Access Rights.
• I am including a few extras such as the ability to create project specific values when working at the portfolio level while I believe when working at the job level user shall not be able to create new portfolio values. I am including the concept of projects sharing resources. In this way a user at the portfolio level can pull down portfolio resources as well as other project resources that will be identified as belonging to some other project. 
• I am/was looking for something better than project-specific activity/calendar codes option available in P6, even before I learned [today] of such option, I am not a fan of P6 but the reference can help me with communicating the idea.
• Not sure everything makes sense or if in conflict, this is main reason why Vladimir comments are welcomed. 

Best Regards,

Rafael

Rafael, Evgeny, you should take a look over the Access Rights and Users, which is quite extensive. You can configure access rights down to the column level.

• I know it very well and know rights are transferred with project file, something unique of Spider. Spider is way ahead of everything else, you ask Spider things way ahead of what others can do even when programming implications are not as easy as they look on the surface. Portfolio Management is not easy, any help from the software should be welcomed. 
• I have seen P6 specs by some US utilities that address the same issue, they requires strict discipline on these codes otherwise it would be a mess, they require some sort of prefix to the codes. I am looking [or was hoping] the software could get automatically over this issue.
  • https://www.dot.ny.gov/main/business-center/contractors/construction-division/construction-repository/CPM_Special_Spec_639_1022--01.pdf
  • The schedule file shall not contain any User Defined fields, all Calendars assigned to activities must be project level Calendars not Global or Resource Calendars, all Activity Codes shall be project level and not Global or EPS level Activity Codes, no Resources shall be assigned to activities, and no Project Codes shall be assigned.
  • Schedule Submission Method - The Contractor shall submit the schedule to the Engineer electronically for review and acceptance. The filename shall conform to the requirements of Table 1.
  • 
  • INSANE, probably based on older P6 versions and promoting brand name specifications something that might be illegal under government procurement rules.
  • Virginai DOT Specs looks better:
    • http://www.virginiadot.org/business/resources/const/ProgressScheduleSPForCategoryIVProjects.pdf
    • If Primavera (P6) or equivalent scheduling software with similar features is used to prepare the Progress Schedule, the Contractor shall define activity codes using the project-specific activity codes option.
      • Note in P6 activity codes are different to activity ID.
    • If Primavera (P6) or equivalent scheduling software with similar features is used to prepare the Progress Schedule, the Contractor shall define the project calendars using the project-specific option.
• I bet Spider team can do better with their small and efficient database engine within Spider than what others can do with their un-necessary huge [a super-sized huge] external database. So hard to maintain it requires learning about the intricacies of the database system while in Spider it is transparent to the user. One of these external database is notorious for frequently rejecting user connections, something they fix with much trouble just to find latter it will happen again and again. Multy valued fields shall be no challenge to them, I believe Activity Name is one of them, the control they have on their own database can give them a programming advantage. 
• I believe it is possible to combine single, multiple project and portfolio specific safe transfer of data making it superior to either project specific only or everything uncontrolled. 
• The automation I was expecting goes beyond basic file structure; it also refers to the transfer of multiple portfolio fields necessary for the project level to handle the resources, for example the transfer of portfolio resources will require the transfer of portfolio calendars tied to the resources being transferred.

I would say that to avoid such conflicts Spider needs to enforce the rule, that  everything, which is not taken from the corporate reference book, shall have a unique project prefix added to a code. What do you think?

• I very often create and use Standard Reference Books but I do not use Corporate Reference Books.
• From Evgeny Portfolio I cannot see any Corporate Reference Book [CRB] either. 
• Making mandatory enforcement via CRB will add unnecessary burden. Imagine when hundreds of independent schedules require their own resources or when an Utility imports schedules from independent contractors.

• I would say that to avoid such conflicts Spider needs to enforce the rule, that  everything, which is not taken from the corporate reference book, shall have a unique project prefix added to a code. What do you think?

Perhaps this is more of a programming question, but the problem to your suggestion is the capability to distinguish objects from a reference book from any other object. Reference books are essentially tab delimited text files and any Spider file can be decomposed into reference books or text files.

The definition of Users and Users Rights is very practical in distinguishing those objects that can be edited and those that cannot.

Rafael, Evgeny, you should take a look over the Access Rights and Users, which is quite extensive. You can configure access rights down to the column level.

Regards,

Bogdan

Evgeny,

Thanks but it does not answer my question in a direct way. If I create a new portfolio from two new jobs when they get consolidated, resources marked A with same code A on both jobs they get transferred with same code without any prefix so unless I am missing something then Spider does not distinguish between project specific and portfolio specific resources, and perhaps calendars, calendar exceptions ... 

I was expecting:

• For every job specific code for resources, calendars ... codes would have [invisibly] attached the job code as a prefix to the activity codes, calendar codes ... A multi valued field where first value would be inherited from the job code, invisible at the job view, visible at the portfolio view, not editable and the second value would be the editable visible part.
• For every portfolio specific code for resources, calendars ... codes would have [invisibly] attached the portfolio code as a prefix to the activity codes, calendar codes ... A multi valued field where first value would be inherited from the portfolio code, invisible at the portfolio view, visible at the job view, not editable and the second value would be the editable visible part.
• The resources, calendars ... you create at a job file are job specific and resources, calendars ... you create at the portfolio can be portfolio specific and can be defined as job specific.
• Maybe it makes sense to allow assignment of project specific resources, calendars ... to other projects while in portfolio, required calendars would be transferred.
• Otherwise coordinating codes could be a nightmare.
• All automatic using job and portfolio codes as a prefix. 

Or something else, I am still looking for the something else as it looks like what I was expecting is not there and maybe is implemented in a different way.

Best Regards,

Rafael

1. Project specific objects such as calendar exceptions, weeks, cost components, cost centers, resource etc. have to be assigned to each project through unique codes before portoflio consolidation otherwhise the values will  be overwritten by other objects with the same code.

2. When distributing projects you have the option of deletin unused objects (the above mentioned).

I am still wondering:

• In any case I wonder how Portfolios distinguish other field codes such as resources, calendars, weeks, exceptions, user defined fields, etc., that might have similar names but different at project level versus at portfolio level, the distinction between Portfolio and Project Specific codes that might be transferred both ways.

About keeping track of project versions it shall not be difficult to figure it out with user defined fields. Portfolio management requires discipline. 

When you have a portfolio of hundreds of jobs.

• Have all jobs started?
• Have all jobs finished?
• Are all jobs in progress?

When updating a portfolio I suppose you want to increase version in a controlled way.

• For not yet started jobs, under portfolio update, I suppose you do not want to make changes to baseline number.
• If during the updating some new job start, I suppose you want to keep baseline and update version number of this one.
• For an ongoing jobs, I suppose you want to increase version number.
• For finished jobs you want to keep history, I suppose you do not want to make changes and increase version number.

Version number represents something you must label as to distinguish what each number means. Each time you increase a version number you shall change the meaning of the version under project properties.

Or I am missing something?

About algorithm under Consider Portfolio Schedule I would speculate if not selected then any algorithm makes sense but if selected then somehow resource assignments on detached portfolio must be considered, how is the question. Perhaps assignment allocations to remaining jobs on referenced portfolio is assumed fixed or non available and then the software considers standard resource leveling on assumed availability, it can also be previous version where portfolio represents previous version. This is just speculating, Vladimir is the one that can really tell. 

You just have to get used to it.

When you use distribute->new version you have to keep in mind that Spider creates new versions of the projects but doesn't update the new version in the Project Gantt. You will have to update these values manually or by formula.

[[wysiwyg_imageupload:1951:]]

You could do this using a script.

Formula: (Code: IncVer) Version = Version + 1

Script Example:

Bogdan

In this case what is the purpose of the option “Consider Portfolio Schedule”?  

• I have not used portfolio functionality for very long time and some of the options seems like might be new, so I do not recognize/understand them all. I suppose the "Consider Portfolio Schedule" is intended mainly for those who are concerned with the individual schedule and have no need [or access] to open a portfolio of hundreds of jobs just to see their single job.  
• When others are updating individual jobs separate form the portfolio this functionality is handy as there is no need to create artificial Start NET constraints. They will see their individual job as if within the portfolio, valid before updating, then after entering their actual dates it shall be brought back to the portfolio for true portfolio scheduling. Because I always have access to the portfolio, in the few occasions I used them, I had no need to use the functionality.
  • In case they execute a resource leveling run they might see some conflicts with their resources but I would never trust this runs as final because the portfolio interaction with all updated jobs is missing. 
  • In order for it to work the user must have access to the portfolio link. Something subcontractors might not have.
  • I suppose there is some procedure for Subcontractor updates but I never had the need and perhaps will never have it as for subcontract work updating our  job PM/scheduler gets the updates via an Excel worksheet.
• It will consider Portfolio as-is and will bring down some missing links but will not update the portfolio nor will level the portfolios, the only way to get true portfolio resource leveling is by working within the portfolio.

With regard to project specific codes I had the understanding this is taken care automatically as Portfolio codes are unique to project codes, they are two separate fields as shown in following figure.

• 
• In any case I wonder how Portfolios distinguish other field codes such as resources, calendars, weeks, exceptions, user defined fields, etc., that might have similar names but different at project level versus at portfolio level, the distinction between Portfolio and Project Specific codes that might be transferred both ways.

Evgeny,

Try the following:

• 1- Delete all project versions 3 and greater if any.
• 2- Keep aligned project versions with portfolio versions, for purposes of this exercise. On live portfolios new jobs might be added while old might be deleted so you might have different jobs on same portfolio version each with a different project version number.

• 3- Distribute Projects to new version.
• 4- You shall get newer versions of each project. For Project 2 version 3 you shall get:

To me all makes sense, the data date is same on distributed projects as on portfolio.

• On portfolio projects are delayed by their relationships with other projects.
• Distributed projects are stand alone versions that will not be impacted by other jobs so if you execute a schedule run it might move unless you add some date constraints to make up for the missing links. A formula can be handy to set Start NET equal to Start before schedule run, you will loose track of original date constraints and here a user defined field can be used to keep them. You will get a Start NET constraint for every activity but remember it is not just about logic dependencies but also about resource dependencies.

After adding the prefix/postfix/changing the activity/phase codes in the projects you have to consolidate the projects into the portfolio in order for the new codes to be transfered.