Guild of Project Controls: Compendium | Roles | Assessment | Certifications | Membership

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.

Managing project Portfolio in Spider

4 replies [Last post]
Evgeny Z.
User offline. Last seen 38 weeks 2 days ago. Offline
Joined: 13 Jan 2008
Posts: 442
Groups: None

Dear all, I just created this generic post about managing project portfolios, but I want to clarify some details on how Spider is designed to use it, as I think it is well thought through in Spider.

In my understanding that it the cycle is like this:

1) Individual project schedules are built

2) Project portfolio, which contains 2 or more projects is created

3) Individual projects are consolidated into portfolio

4) Dependencies are added between projects in portfolio

5) Portfolio is scheduled 

6) Portfolio is distributed to a new version of a projects

7) Individual schedulers start working with individual projects 

In this stage the scheduler can update progress etc, but also is able to re-schedule the project with the option  As a part of project portfolio In another words the scheduler can re-schedule the project as if other projects do not change (which is logical)

Question: is there any way at this stage for a scheduler of individual project to see what external dependencies drive his project? 

8) at cetrain moment a portfolio is consolidated again and the whole cycle repeats from the step 5. I guess at this stage someone like a program/portfolio manager assesses impact on the overall schedule as well as on the individual schedules, resolves the conflicts, take decisions on priorities and approves a new master schedule. 

 

Is this how it is meant to work in Spider?

Replies

Evgeny Z.
User offline. Last seen 38 weeks 2 days ago. Offline
Joined: 13 Jan 2008
Posts: 442
Groups: None

Vladimir, thanks. It sounds logical and reasonable.

In any software schedule updates must be done in certain predefined moments. In other case data dates of different projects and/or different parts of the project will be different and project/portfolio scheduling will provide wrong results.

At different levels of the management hierarchy (portfolio level, project level, site level) the need and reglaments of updates can be different. If some projects were updated and others don't it is impossible to recalculate project portfolio and get reliable information on resource availability and updated constraints. And so the portfolio can be updated and rescheduled when every project has the same data date. But some projects require faster updates (for example weekly instead of monthly, or daily instead of weekly), And so it is necessay to be able to update this project information without damaging portfolio model. That is why in Spider Project project models are sent to their managers for autonomous work between portfolio updates at predefined moments. From one moment to another project remembers portfolio constraints (external dependencies and resource availability) that existed at the start of the period. New constraints will become known when all projects will be consolidated and portfolio model rescheduled and not when somebody entered something.

This way it is possible to play what if without any restrictions because managers create versions of their projects without damaging portfolio model, use their own reglaments of project updates between the dates of portfolio updates, etc. Yes, an initial information on other projects can become outdated but in any case it can be correctly updated only as the results of portfolio rescheduling. It means that in case of large changes in some of the projects portfolio update can be done ahead of reglament date. It means that portfolio manager can require all project managers to enter their project status on specified date and reschedule project portfolio.

Making changes and entering data directly into portfolio model makes project management too complicated (I mean problems with using own reglaments of entering actual data and project rescheduling, playing what if scenarios, etc.).

Evgeny Z.
User offline. Last seen 38 weeks 2 days ago. Offline
Joined: 13 Jan 2008
Posts: 442
Groups: None
Vladimir, thanks!  I understand that extra needs to be done to allow portfolio management in Spider, than what I described. But I was more interested in a philosophical question: how one updates an individual schedule in a portfolio in the situation when from one side  schedules depend on each other, from the other side you want some stability and you do not want your environment to be constantly changing (e.g. if other project has changed). And the answer of Spider the way I understood is: you update your schedule with the assumption that the rest is stable and then when projects are consolidated in the portfolio only then conflicts between projects are resolved by someone with the higher authority. In Primavera it is different: as soon as one project is updated, the other one will immediately take it into account, when being scheduled.  Which I think is difficult to manage in practice. In MS Project this is a middle ground. One can choose to accept / not accept the change from another project.

There are certain things that must be done for organizing proper portfolio management.

These things include:

1) Creating corporate reference-books of cost components, calendars, resources, materials, multi-resources that must be used in all projects belonging to the same portfolio;

2) Creating corporate reference-books for different kinds of norms that must be applied to activities and assignments of the same types (resource productivity on typical assignments, unit costs, material requirements on volume units of typical activities, etc.);

3) Create certain requirements for activity coding common to all portfolio projects;

4) Create and use WBS templates.

It is necessary because if the same resources have different codes in different projects project portfolio will not recognize that it is the same resource. The same problem can exist with cost components, materials and other objects.

Calculating project portfolio schedule we take into account not only activity dependencies butt also resource and cost constraints. Financial restrictions usually exist on portfolio level.

Calculating project schedule as a part of project portfolio Spider Project takes into account not only external dependnecies but also resource availability.

External dependencies are not shown in projects but it is possible to permit project managers to open project portfolio for studying these dependencies. Dependencies can exist between activities of different projects (not between the projects).

The rest is right.