Portfolio Management

Disciplined Agile Portfolio Management

The Portfolio Management process blade describes how a disciplined agile IT organization goes about identifying, organizing, and governing their various IT endeavors.  IT endeavors include solution delivery projects, product development teams, business experiments (along the lines of a lean startup strategy), and even the operations of existing IT-based solutions.  This article is organized into the following topics:



The following diagram overviews the potential activities associated with disciplined agile portfolio management.

Disciplined Agile Portfolio Management

There are seven critical process factors to consider:

  1. Identify potential value.  Working closely with your product management team (if you have one), your portfolio management team will identify potential new ideas and products to develop.  You will do this through monitoring the business environment to see what your competitors are doing, through obtaining feedback from your existing customers, and by envisioning the future needs of your customers through agile modeling and brainstorming sessions.
  2. Explore potential endeavors.  The portfolio management team will invest time in understanding a potential endeavor.  They may choose to consider the business case for the endeavor, perhaps creating high-level guesses at the potential market potential or return on investment (ROI) of the endeavor.  The team may also consider alternative approaches to the endeavor and may even choose to run a focus group or small experiment to better understand it.
  3. Prioritize potential endeavors.  Because few organizations have unlimited budgets to work from you will need to prioritize potential endeavors and then invest in the ones that are most important to you.  There are several factors to consider when prioritizing, including: business value (disciplined agile IT departments strive to maximize the value that they provide to the overall organization); business risk (risk and value often go hand-in-hand, although sometimes you`ll find some endeavors are too risky to consider right now); due date (some endeavors are driven by government regulation or by promises made to important customers); and dependency.
  4. Manage portfolio budget. Your IT portfolio budget needs to be managed.  Traditional firms tend to follow an annual budgeting process which tends to inject significant overhead and risk into their IT efforts.  More effective strategies are to move away from project-based financing to funding stable teams and to take a rolling wave approach to planning the budget that evolves as your needs and means evolve.
  5. Initiate endeavors. New products may be developed by either a product team or a project team.  In the case of products that are radically new to your organization you may decide to first take an exploratory (lean startup) approach where you first validate the market potential of the product via a series of learning experiments.
  6. Plan IT capability.  Your IT department must have the resources, both in terms of finance and people, to fulfill its responsibilities.  You must have the right people, with the right skills, at the right time, to do the work and this takes a bit of coordination.
  7. Manage vendors.  An important aspect of portfolio management is vendor management (also called supplier management), particularly when it comes to IT service vendors providing contractors, consultants, or outsourced development services.  Vendor management includes the awarding (procurement) of contracts, identifying potential vendors, monitoring in-progress contracts, and eventually ending or closing a contract.
  8. Govern the portfolio.  Someone will govern the overall IT portfolio, including in-progress development endeavors as well as operational solutions.  IT portfolio governance is a subset of your overall IT governance strategy.


Work Flow With Other IT Teams

The following diagram overviews the high-level Portfolio Management workflow.  The diagram shows how the Portfolio Management efforts gets inputs from Enterprise Architecture and Product Management (feedback is assumed even though the arrows are depicted as uni-directional).  The diagram also shows how Portfolio Management provides initial team funding, an initial vision, and guidance to Build efforts, including small(ish) agile, lean, exploratory and continuous delivery teams as well as larger programs.  The Portfolio Management efforts receive development intelligence (metrics) from the build efforts and operational intelligence (metrics) from the run efforts.  These metrics will be used by the people performing portfolio management to make better, more informed decisions.  Your IT Governance effort will provide guidance for Portfolio Management, and your Continuous Improvement effort will provide improvement suggestions for Portfolio Management (and potentially receive suggestions back).

Disciplined Agile Portfolio Management


As you can see from the work flow diagram above, there are several process blades related to portfolio management:

  • Enterprise Architecture.  Addresses strategies for supporting stakeholders; supporting delivery teams; evolving the enterprise architecture; capturing the enterprise architecture; and governing the enterprise architecture efforts.
  • IT Governance.  Addresses strategies for consolidating various governance views; defining metrics; taking measurements; monitoring and reporting on measurements; develop and capture guidance; defining roles and responsibilities; sharing knowledge within your organization; managing IT risk; and governing the various governance efforts.
  • Product Management.  Addresses strategies for managing a product, including allocating features to a product, evolving the business vision for a product, managing functional dependencies, and marketing the product line.
  • Program Management.  Addresses strategies for managing large product/project teams; allocating requirements between sub teams; managing dependencies between sub teams; coordinating the sub teams; and governing a program.
  • Release Management.  Addresses strategies for planning the IT release schedule; coordinating releases of solutions; managing the release infrastructure; supporting delivery teams; and governing the release management efforts.

The activities associated with these process blades are often very highly related. For example, in some organizations the activities associated with portfolio management and IT governance are fulfilled by a single group.  In other organizations some product management activities are performed by the portfolio management team and some by the enterprise architecture team.  Some organizations may choose to have a separate group for each process blade.  And of course the organizational structure will evolve over time as your various teams learn how to work with one another.

7 thoughts on “Portfolio Management

  1. Pingback: Disciplined Agile Portfolio Management | Disciplined Agile Delivery

  2. Erich Meier

    Hi Scott,

    Very interesting breakdown of a topic that is way too often neglected.

    The term “process blade” immediately caught my eye. Could you elaborate a bit more what you mean by this? Is this similar to “process area”, but stresses more the collaboration aspect with other blades?

    Thanks for your insight!

    1. Scott Ambler Post author

      Thanks. We’ve recently updated it based on our current work on program management,

      Process blade is similar to process area in concept. We’re trying to get across the idea that these concepts are all interrelated and should be performed in a collaborative, evolutionary manner.

      Too many organizations address process areas alone. They will try to adopt “best practices” for enterprise architecture (say TOGAF), for portfolio management (say PMI), for IT Governance (say CoBIT), for analysis (say IIBA) and so on. Alone these strategies have their strengths and weaknesses, but together they don’t fit well. The organization has locally optimized individual process areas but still have a mess on their hands. With Disciplined Agile 2.0 we’re showing how it all fits together in a holistic, non-prescriptive manner.

  3. Daniel Gagnon

    I have a recommendation for a choice to add to “Prioritize Potential Endaevours”. To wit, Economic prioritization, also sometimes referred to as Cost of Delay, or in the work of Don Reinertsen, “Weighted Shortest Job First” (Don’s work has received some well-deserved exposure from SAFe).

    For Don’s book : https://www.amazon.ca/Principles-Product-Development-Flow-Generation-ebook/dp/B007TKU0O0/ref=sr_1_1?s=books&ie=UTF8&qid=1468079728&sr=1-1&keywords=flow+second+g

    For a great series of articles on Cost of Delay in general : http://blackswanfarming.com/category/wsjf/

  4. Daniel Gagnon

    More thoughts on this process blade : There may be room for a nod to Lean Startup at Scale here. For example, “Finance Endeavours” could use a choice called Innovation Accounting (whereby teams receive modest increments of funding which they can only continue receiving if they prove that they are continuing to learn about the market and about their customers with the release of each small experiment)


Leave a Reply

Your email address will not be published. Required fields are marked *