Project Lifecycles and Portfolio Manager

You probably already have a project lifecycle with standard milestones and activities. And you want to know how Portfolio Manager will fit in.   

The good news is that this approach can be built into whatever development methodology you use: ‘waterfall’, agile or hybrid. You decide what makes sense for your team. Here’s how.

Creating a Portfolio/Creating a Project

Portfolios

If you’ve got a large number of projects, you probably already gather them into Programs or Portfolios. Portfolio Manager just has projects and portfolios – and you can group EA projects into portfolios however you want. 

Portfolio Manager generates views which show whats happening across all the projects in a portfolio. So just group your projects into portfolios to match your organizational structure. They could be based on projects that share a senior stakeholder. Or on a sequence of projects that combine into an integrated program of work. Whatever works for you.

Projects

To make your project visible to other projects, e.g. in impact assessments, all your modeling – branches and new elements – must be within a Portfolio Manager project package. So create your project first. If you don’t have any portfolios that’s no problem. The Portfolio Manager views will all still generate, but the portfolio views will not be useful.

Note Portfolio Manager doesn’t support the idea of a project within a project – the only way to collect several projects together is into a portfolio.

Branching

When you take a branch of the baseline in your project package, and other projects are also working on those elements, the modelers in those projects will see it when they do an impact analysis.

Portfolio Manager gives the status <branched> to all branched elements. That means your project is thinking about changing them. If your project will be retiring some baseline elements, you should branch those elements, then change their status to ‘branched to retire’.

You can create lots of branches from various parts of the baseline – maybe even branch the same baseline elements two or three times if you are thinking about different options. Once your trade-off study is complete then just delete the modeling you aren’t going to use.

At the point the project was created, you set a likely implementation date. Every element in your project also inherits this date, but you can edit it to give individual elements different dates if go-live will be happening in stages. 

Other projects will see if your project has branched the same elements as them when they run impact assessments, but any dates you have entered will be hidden until your modeling is promoted to <planned>.

Promoting

In Portfolio Manager terms, moving EA project elements from branched to planned is a significant step. It is the point at which the solution goes from ‘we’re just thinking about it’ to ‘this is probably going to happen’.

Promoting to planned can be done for a complete project, or for individual elements. When elements are promoted to planned they are moved from the project package into the model staging package. Elements that were ‘branched to retire’ will also be moved into staging, and be promoted to ‘planned to retire’.

Impact on your project

When elements are promoted to planned, then you are confirming that modeling of these elements is complete. We think that is a good time to put them under change control.

Change control means that any future changes you need to make to these elements will be modeled in a new, ‘change’ project, with it’s own project package and new branches taken from your planned elements. The ‘change’ project will then progress through the complete Portfolio Manager lifecycle. This is our recommended approach.

However, if instead you move these planned elements out of staging and back into your project to continue changing them, you may cause problems for other projects – particularly if they were prompted to branch from your planned change – see below. Chaos may well ensue. You have been warned!

Impact on other projects

When your project changes become planned then all other projects that have branched the same baseline elements that you are changing will see that they are now working on out-of-date information. They will be advised to use your planned elements instead of the baseline elements that will be replaced.

The go-live (implementation) date for planned elements is shown in generated Portfolio Manager views. Element roadmaps and time machine diagrams are based on this date information and show how your project changes will impact the model at future dates.

Implementing

Once the ‘real world’ changes have gone live, your model will need to be updated to reflect the new baseline. This is the point at which planned changes are moved from the staging package and replace their equivalents in the baseline.

Implementing elements can only be done by an EA model manager with access to both the staging package and the baseline. 

Project Closedown

Once a project has completed, and all the model changes have been implemented, then the project folder can be deleted or archived, as per your usual process.

The project changes are all now in the baseline, but they retain the connection with the project that delivered them, so you can keep track of what and why your model looks like it does..

See Also

Structure, Locking and the Portfolio Manager State Model