Manage Learn to apply best practices and optimize your operations.

Differences between Agile and conventional portfolio management

In this tip, Kay Diller spells out ten differences between Agile portfolio management and conventional portfolio management.

Transitioning from conventional software development to Agile application lifecycle management (ALM) can be challenging...

for a portfolio manager, as the same rules do not apply to Agile and conventional project portfolios.

This article discusses 10 differences between Agile and conventional project portfolios, something all portfolio managers need to be aware of. 

1. Ownership of portfolio

Under conventional portfolio management, there is usually one portfolio manager who owns the portfolio and works with the various project managers to collect and update information regarding the projects that are located in the portfolio. Under Agile, the team is more involved with managing the portfolio. The team analyzes resources, the value for each project, and how to best balance the portfolio. The Agile portfolio manager still owns documenting the progress of the portfolio and what projects are in the portfolio, but the team really “owns” the portfolio and its overall success.

2. Business case

The business case, or justification for the project, is identified at the beginning of a conventional project and are usually not revisited after the project is initiated. Under Agile, business cases are challenged and analyzed after each iteration and are used in the continuous Go/No-Go analysis, which can impact what projects are placed or remain in the Agile project portfolio.

3. Risks and Rewards

The risks and rewards of a conventional project are identified at the beginning of a project, most likely in the project plan and are evaluated throughout a project by the project manager. With Agile, risks and rewards are evaluated by the team after each iteration. The portfolio manager updates the portfolio with this information, noting which projects have higher risks and rewards.

4. Value of project

The value of conventional software is created and documented by the project manager in the project plan, which is created many times before the team is fully identified and operational. Agile projects are being constantly measured by the value they add to the overall portfolio, which occurs at the end of each iteration.

5. Canceling portfolio project

Canceling a project mid-stream is often considered a failure with conventional software projects. However, under Agile, canceling projects that no longer add value is deemed an integral part of portfolio management as the overall portfolio is only weakened by projects that no longer add value.

6. Allocation of resources

Generally, conventional software teams are dedicated and directly funded to their projects for the length of the project, which can be months or years, with little ability to move resources based on the needs of other projects in the portfolio.  Agile projects are similar to conventional projects as team members generally do not move to other projects during an iteration, but due to the short time frames of iterations, resources can be easily re-allocated after an iteration, allowing for a better balance of resources to all of the projects in the portfolio.

7. Balancing a portfolio

Conventional portfolios generally do not have the ability to change the balance of projects in a portfolio once projects are added. This means that there will be projects in the portfolio that consume more resources than the benefit or value of the project because resources were funded for the full duration of the project. Agile offers the ability to balance a portfolio at the end of each iteration, moving resources and funding to the projects with the greatest value.

8. Acceleration or fast Tracking

Once a conventional project is funded, fully resourced, requirements identified, and the coding has begun, it is difficult to add newly identified requirements mid-stream, even if mandated as critical by customers. Many times when this happens, conventional developers have to stop their current coding and re-architect their entire project, impacting established deadlines and milestones. The project portfolio is impacted with these delays as funding and resources will no longer be available for other projects that were to begin in the future. Agile allows for the flexibility of changing requirements during and between iterations and since funding and resources are allocated to projects that add the most value, there is no negative, long term hit to future projects waiting for those resources and funding.

9. Project dates

Under conventional software releases, project dates are determined by the project plan at the beginning of the project. This means that major milestones and completion dates of the various projects in a portfolio have no relationship to each other. With Agile, portfolio managers and teams have the ability to begin and end iterations on the same date.  This allows for a robust analysis of projects in the portfolio at the end of each iteration where decisions can be made on portfolio value, balancing, resources, funding, and Go/No-Go decisions. 

10. Conventional and Agile project mix in project portfolios

Both conventional and Agile projects normally need to be kept in separate portfolios due to the differences mentioned above. This means when an organization has conventional and Agile projects being developed in parallel, unless they're using a PPM solution that will handle both, the portfolio manager will need to keep a separate portfolio for the conventional projects and apply conventional portfolio management to those projects, along with a separate portfolio for the Agile projects, where Agile portfolio management is applied. 

As mentioned at the beginning of this article, transitioning to an Agile environment can be challenging to a portfolio manager, but due to all of the benefits found in the Agile methodology, it is well worth the extra effort.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.