(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.
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?
Printer-friendly version
Send to friend
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.).
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.
Email: PPadmin@planningplanet.com
Replies