Working with portfolios
- Created
- 53
- 7
Dear all,
I have a couple of questions regarding working with Portfolio
Q1: I still don’t understand what exactly the action "Update Portfolio" does. I tried to invoke it when the schedule of the project included in portfolio has changed, but it did not have any effect, portfolio was still showing old version after I did Update Portfolio =>New version.
Note: Consolidate/Distribute seems to be working as expected.
Q2: When performing resource constant scheduling of an individual project, only Standard Method is available if an option “Consider Portfolio Schedule”, is selected. Why is that?
Q3: When performing resource constant scheduling of an individual project and option “Consider Portfolio Schedule” is selected, then the following behavior is observed:
Resource leveling takes into account portfolio resources, without considering, that this project itself is already a part of ths portfolio, so it “double counts resources”. Example: when one has a portfolio of 2 projects, each consisting of Activity 1 with Resource A, when portfolio scheduling will be done, then in one of the projects Activity 1 will be correctly delayed by resource leveling.
If I now go to any of the projects and perform resource constrained scheduling, with the option “Consider Portfolio Schedule”, then I will see, that the Activity 1 will be delayed yet again, even though it is not needed, because it is already a part of the portfolio, hence total resources of the portfolio already take into account this project.
Did I miss something here?
53 replies
Oldest first- 0Vladimir Liberzon ·
Evgeny, thank you for
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.
- 0Evgeny Z. ·
Vladimir,I think there could
Vladimir,
I think there could be a couple of reasons to introduce such check
- In my experience if any mistake can be done by human, it will be done. And if one avoids any possibility of mistake, they still will be done, but less frequently. In case of Spider I can imagine it may be quite difficult to debug the problem if on one project of portfolio they just happen to use different objects with the same code. In this case after portfolio run project will receive project file back, but this object will be changed, which may be difficult to spot.
- There can be a reverse situation, when people will happen to use the same code for what is never meant to be the same object (e.g. code A for 2 totally different resources). This is because, as previously discussed, Spider does not add project specific prefix or suffix to its objects.
Regards.
Evgeny
Log in or join to reply
ProjectControls.com is free to join. Members can post questions, reply, vote and follow discussions.
Existing members: your original username and password still work. Forgot password?