Portfolio Manager walkthrough

This is a walkthrough of most of all of the important functions of Portfolio Manager.

All the data can be found in the eaTeamWorks Example Model, under the ‘Portfolio Manager’ model root.

Setting-up the walkthrough

Portfolio Manager is designed to co-ordinate the modeling of lots of people, all working in the same parts of a model, so it’s quite a complicated product, and takes a bit of setting-up.

Walkthrough Overview

The walkthrough is split into a few parts, each one showing what happens at different stages of a project. To keep it manageable, rather than follow a single project through all the stages, the walkthrough looks at several different project, each a different stage. The projects can be seen under the ‘Portfolios and Project’ package, organized by Portfolio.

Project ‘Grasshopper’ – branching

1. Login as user ‘G1’ – no password.
2. Notice what is un-locked to you – just your own project area. All the ‘as is’ models are locked, as you might expct.
3. Find the solution overview diagram. Get some elements (as links) from the ‘as is’ model
4. Try to create a branch of a single element: the ‘Technology Service D’
5. Not very exciting:
   1. Element in the diagram seems to change color. In fact, it’s a different element: see in the Project, there’s a copy of ‘Technology Service D’ called ‘Technology Service D*’ (with asterisk. By default, branched elements get one of these added, just to help identify them)
   2. The ‘as is’ element in the diagram has been replaced with this one
   3. The connector from ‘Application Component A’ is now blue, because it connects an ‘as is’ element to a branched one
   4. If you are curious, right-click on the ‘Technology Service D*’ and chose PM / Add baseline element. This will show that PM also created a link from the new element back to it’s parent in the ‘as-is’ model.
6. This wasn’t very exciting, as there don’t seem to be any other branched or planned versions of Technology Service D.
7. More realistic is to branch a whole load of elements.
8. Select all the other elements from the diagram, and choose PM / create branch
9. In this case, there are all kinds of implications to branching all these elements. The ‘Impact’ column shows what the impact of branching each element would be
   1. Some elements have no impact
   2. A few have impact = 4. This means that another project has also branched that element.
      This might not be a problem, but maybe it might be worth talking to the project(s) which are thinking about changing these elements. They may have just branched a whole load of stuff, and not really be seriously considering changing anything, but it’s also possible they might. Worth talking to them.
   3. Technology Service B has an impact of 7, because Project B1 is ‘branched to retire’ by another project. So if our  project needs to change it, that’s probably not a good idea. Probably best to un-check this.
   4. Application Component A has an impact of 10, and ‘create branch’ is not checked. This is because there is planned change from another project, so if we branched the ‘as is’ version, it will soon bear replaced with the one from project BB2. In this case, you  have the option to ‘replace with newest planned’. Choose this option, and Application Component A is replaced by ‘AC_A V2 – new for 2023’, which has no impacts.
10. Choose ‘branch’ to branch all the elements which are checked in the list. As before, you will then get lots of copies of these elements under your project, ready for you to make changes to them.

Project ‘Rosebud’ – planning

This project has been running for a while, as has been branching all kinds of things.

It’s now at the state where the project is planning to go ahead and make all the the changes which until now, it’s just been thinking about.

1. Login as user ‘R1’ – no password
2. As before, only your project is un-locked
3. Find the diagram called ‘outline solution’. Lets assume this has all the bits of our solution which we want to build. Remember though, we’re just planning to change all these elements, and not everything which is planned to be changed actually gets changed. But our plans are firm enough for other projects to build on what we’re planning to do, by branching our changes.
4. Select all the elements in the diagram which you want to make ‘planned’ (by ‘promoting’ them) and choose PM / Promote
5. PM will show you another impact list. So you can see the impact of make all these elements ‘planned’.
6. Choose ‘promote’ to promote all these items.
   Note that they get moved now into another package – to which user R1 does have access, bu PM assumes that someone else will then move those element on into a package which R1 user does not have access to.
   This is a kind of ‘staging’ area for planned changes.
   This is important. Project rosebud has just said that its going to implement these changes, and that it’s OK for other projects to make their plans assuming this will happen. For Project rosebud to make any more changes may have an impact on other projects. If they do need to make changes, then they will have to create branches, assess the impacts, talk to affect projects, just as if they were making a change to the ‘as is’.
   This is consistent with the change control processes which a project will probably have anyway: this just adds a bit more to those processes.
7. PM assumes that, once PM has moved the planned elements to the ‘staging’ area, they will then be moved on into another staging area, to which projects teams do not have write access. This should be part of the model governance process, and should involve other quality checks, made by the model admins before content can be accepted for potential use by other teams.

Project Bluebird – Implementing

When a project finally completes, and the changes it planned to make have been deployed, then the changes it previously had as ‘planned‘ become ‘implemented.

This part of the Portfolio Manager lifecycle will probably be done not by the project team – which have probably moved on to other things – but by model administrators.

This part is critical: we absolutely want the ‘as is’ model to be kept up-to-date with the latest changes, otherwise it will be useless. In fact, worse than useless, because it will look as if it reflects the real world, but won’t.

1. Login as Admin (no password). This is needed because higher security is needed to make changes to the ‘as is’ model, which is what this part will do
2. Look inside the ‘Bluebird’ project package – nothing! That’s because all the ‘planned’ changes are now in a locked part of the model
3. Right-click the project package, and choose PM / Implement
4. This will do yet another impact analysis, to show the impact making each element part ofthe ‘as is’ model.

Managing a PM Model

The above shows how projects, at different stages of their lifecycles, will use PM.

As they do this, they will create lots of really useful information, which can benefit your organisation in lots of other ways.