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.

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

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

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

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.

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

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 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. 

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.

porfolio_project_gantt_increase_version.jpg

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.