Home / Learn / Insights / Project Lifecycles and Portfolio Manager

Project Lifecycles and Portfolio Manager

How to integrate the Portfolio Manager lifecycle with waterfall and agile development methodologies

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.

Impact Assessments work anyway

Each project can only be in one portfolio, but Portfolio Manager impact assessments are generated at element level, so are independent of the portfolio in which your project is located.

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.

Waterfall Projects We suggest making “creation of an EA project” a task in your project initiation phase.
Agile Developments You might want to create a project for each user story, or for a collection of stories or an epic. Just make sure you create the project before you start modeling. 

NB: if your project contains more than one user story, then you can set different implementation dates for elements being developed and deployed in different sprints. 

The Portfolio Manager impact analysis does not highlight clashes or dependencies between items within a project, but only between projects. So for maximum visibility of changes across the whole model it may be best to create a large number of smaller projects.

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>.

Waterfall Projects Branch and create new elements as soon as the design work starts. Additional branches can be added into your project at any time.
Agile Developments As soon as an item has been accepted onto the backlog as a potential Sprint candidate, start branching and creating new elements. 

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.

Once elements are planned they can be branched by other projects, so the staging package should be change controlled. Should projects have access to staging, or just the model managers?

Waterfall Projects You could promote to planned at the milestone where the design has been approved and the solution moves into build and test. That’s probably when you’ll have a project plan with a confirmed go-live date, or dates for different releases.
Agile Developments When the Sprint planning meeting has confirmed which Sprint you’re in, you’ll have a better idea of the implementation date. Assuming you’ve completed design work by then, that could be a good time to promote your model to planned.

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. 

Waterfall Projects Model changes can be implemented at any time  – but probably after project (or project release) go-live. You could coordinate with a  project milestone when the design/test work has completed, or when the solution has started roll-out, or when the full solution is live.
Agile Developments You may choose to put the model changes live as soon as the Sprint is complete, or delay until the ‘real-world’ solution is live. 

A little bit of magic.

For completely new elements and connections, implementing them by writing into the baseline is straightforward.

Where elements are being updated then each new element version replaces the original baseline element. But the new version takes on the original element GUID – which means that every element related to that original element keeps exactly the same relationship to the new version. The ‘old’ version is then retired and moved into an archive package, with all its connectors removed.

New project work won't be delayed if you wait a little while before implementing changes into the baseline, because projects can branch from planned elements. BUT planned changes in staging will show up on portfolio and model manager heatmap views - so maybe add 'implement into baseline' into a project closedown checklist. 

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, so they don’t keep any connection with the project that delivered them.

 

See Also

Structure, Locking and the Portfolio Manager State Model

More Insights

What AND why

8 November 2022

Making maximum use of our EA information, to show not just what the world looks like now, but why as well.

Learn More

Solution Architecture using Enterprise Architect

6 October 2022

Ian's presentation to the EA Global Summit on September 15th 2022

Learn More

Branching and Impact Analysis

15 June 2022

How to start your project in EA by copying from the as-is model - with Portfolio Manager

Learn More

Introduction to Portfolio Manager

14 June 2022

A new approach to delivering a single version of the truth across many projects all working in the same Sparx EA model repository.

Learn More

Structure, Locking and the Portfolio Manager State Model

9 June 2022

Portfolio Manager basics: Package structures, model locking and element state model

Learn More

Inside Portfolio Manager

19 May 2022

some text

Learn More

Why Portfolio Manager?

12 May 2022

Portfolio Manager was created to answer the question, "why can't I see what other projects are doing?"

Learn More

Pricing and features

Find out what’s included…

Check out Pricing

Download Portfolio Manager

Take a free, no obligation, 30-day trial today. Discover for yourself the difference that Portfolio Manager real-time impact analysis will make to your EA modelling.

Download