Tips on using this forum..

(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?

(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.

Resolving conflicts, when working with portfolios

5 replies [Last post]
Evgeny Z.
User offline. Last seen 11 weeks 5 days ago. Offline
Joined: 13 Jan 2008
Posts: 405
Groups: None

Dear all,

I am checking the work with portfolios.

As far as I understand, the mechanism is as follows

  • When you add project to portfolio and then consolidate projects, Spider considers all object except activities to be the same in different projects as long as they have the same code (resources, skills, multi-resources, materials, material sets, cost components etc.). So far activities is the only object I have found, which Spider would prefix with the project code when consolidating and then would remove this prefix when distributing  back.
  • Spider does not do any verification on whether objects, which have the same code are actually exactly the same.  
  • As far as I can see, the objects of the project, which is added first to portfolio take precedence (e.g. if ResA in Project1 has a Calendar 2 and ResA on Project2 has a Calendar 1, then when consolidating projects, if Project1 is added the first one to the Portfolio, then ResA will have Calendar2 both in Project1 and Project2, once the projects are distributed back).

I think therefore, that there must be some extremely strict discipline imposed in practice to insure, that such conflicts would not happen. So logic says, that there should be only single place, where it would be allowed to change parameters of the objects, which can be shared between projects (calendars, resources, etc).

Question:

  • Without central server, how does it work on practice? How is this disciplene imposed?

Regards.

Evgeny

Replies

Evgeny,

yes, resources, materials, cost components and calendars shall be certainly managed centally to avoid duplicates and errors.

Other data that we suggest to manage centrally include activity types, resource skills, complects of materials, actually any data that shall be the same in all projects belonging to the same portfolio or the same organization.

Resource and activity types are used for connecting to corporate reference-books. It is necessary to use the same type code for activities and resources with the same properties.

Best Regards,

Vladimir

Evgeny Z.
User offline. Last seen 11 weeks 5 days ago. Offline
Joined: 13 Jan 2008
Posts: 405
Groups: None

Vladimir,

coming back to the question of the reference books, access rights and portfolios. 

I can see, that access rights are very flexible. One can define different access rights to 14 different object types. For each of these objects one can have 4 levels of access:

  • Full rights
  • Edit existing rows only
  • Only from corporate reference books
  • View only

This gives us about quarter of a million of different combinations in total. But do you have a sort of recommended setup for portfolio type of environment or at least a list of minimum things, which must be managed centrally (from corporate reference books) in order to maintain data integrity and portfolio logic?

In previous topic you have written about 

  • resources, 
  • materials, 
  • cost components, 
  • calendars (I assume also weeks and exceptions here)
 

Is it all, which MUST be managed centrally for portfolio?

 

Regards.

Evgeny

Yes, you are right.

Corporate reference-books are managed by PMO and project schedules shall be regularly updated.

It is easy and does not require opening reference-books. Just select all in the corporate reference-books table and select Transfer data in the pop-up menu.

Of course actual data will not be changed (this is MS Project problem).

Regards,

Vladimir

Evgeny Z.
User offline. Last seen 11 weeks 5 days ago. Offline
Joined: 13 Jan 2008
Posts: 405
Groups: None

Vladimir, 

thanks. Understood.

Access rights and reference books are still in my to-do list to learn.

But is my assumption corect, that in your example the corporate reference books should also be constantly updated (e.g. to accomodate changes in hourly rates, new resources, new planned vacations for existing resources etc) and planners are therfore also obliged to periodically refresh already imported information in their projects from corporate reference books? 

Regards.

Evgeny

Evgeny,

in large companies with many projects strict order is necessary.

When you will look at the access rights that may be assigned to different users notice that some of them can add objects only from the corporate reference-books. It means that a planner is not authorize to add new resource (for exampe) but only add to his project those resources that exist in the corporate reference-book. The same with other objects. Some of them shall be managed centrally (on the PMO) like resources, materials, cost components, etc. So when reources in different projects have the same code then they are the same.

In Spider Project corporate resource pool is stored in Resource Reference-book.

But Spider can manage many portfolios with different reference-books. In your project you may define what reference-books are yours.

In some organizations PMO creates project templates that already have these links and access rights, and suggests to start the schedule development using the template.

Projects belonging to the same portfolio are certainly using the same resources, materials, cost components, calendars.

Best Regards,

Vladimir