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.
There are seven critical process factors to consider:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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).
Related Process Blades
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.