The Portfolio Management process blade addresses how an IT organization goes about identifying, prioritizing, organizing, and governing their various IT endeavors. Disciplined Agile Portfolio Management seeks to do this in a lightweight and streamlined manner that maximizes the creation of business value in a long-term sustainable manner. IT endeavors typically include solution delivery initiatives/projects, stable product development teams, business experiments (along the lines of a lean startup strategy), and the operation of existing IT-based solutions.
This article is organized into the following topics:
Being agile, having an agile mindset, is foundational to working in an agile manner. The Disciplined Agile Manifesto and the principles of lean software development provide an important start at this mindset. In this blog we explore similar agile philosophies that are specific to successful portfolio management. These philosophies are:
- Keep it simple. Keep your portfolio management activities as streamlined and lightweight as can be. Your goal should be to focus on making good decisions and providing guidance to people, not on maintaining extensive documentation or reviewing documentation. You still may choose to maintain artifacts such as a portfolio roadmap and portfolio budget, but those too should be as lightweight and concise as possible.
- Focus on value over cost. Shifting your mindset from “what is this going to cost?” to “what value will this generate?” is critical to your success because it helps you to focus making better IT investments. You want to invest in IT endeavors that enhance your organization’s ability to produce value for your customers. This in turn provides the profits required for further investment.
- Reduce the cost of delay. One of the strategies for maximizing stakeholder value is to invest in developing functionality that will provide value to the organization soonest. For example, if you delay developing functionality that will generate annual revenue of $10 million for six months you have an effective cost of delay of $5 million because you missed out on half a year of revenue. Disciplined agile portfolio managers consider the cost of developing a solution, the cost of delay that results from putting off said development, and the revenue generated (or cost savings) when calculating the overall value of a solution.
- Invest in streamlining the creation of value. Not only do we want to produce value for our customers, we also want to be good at doing so. The implication is that we sometimes need to invest in ourselves through process or environment improvements.
- Prefer stable teams over project teams. Although portfolio management is often believed to be the oversight of project teams, it really is more about the coordination and oversight of teams in general. In Disciplined Agile we recognize that an initiative is seldom finished at the end of a “project”. There are usually subsequent changes required over time requiring future releases of the solution. The agile community has discovered that long-lived stable teams, whose membership evolves over time, have significant advantages over short-lived project teams. A significant productivity improvement occurs when IT organizations shift away from the project mindset of bringing people to the work and instead decide to bring work to the people (the stable teams).
- Align teams to value streams. These stable teams should be aligned long-term to value streams or lines of business (LOBs). High performing agile teams reliably deliver value frequently to their business stakeholders. As a result the business learns to trust the teams aligned to their areas. This positive feedback cycle maximizes the effectiveness of your agile teams. Additionally, over time they learn more about the business adding to their effectiveness.
- Enable diversity. Every person, every team, and every organization is unique. Every team faces a unique situation that evolves over time. The implication is that teams must be allowed to organize themselves and to tailor their process to meet the context of the situation that they face. This is why the Disciplined Agile (DA) toolkit focuses on providing, and comparing and contrasting, a wealth of process choices. The implication for portfolio managers is that they need to be flexible in their approach. They will work differently with each team because each team works differently, yet they must still provide good guidance to these teams and monitor the effectiveness of each team appropriately.
- Trust but verify. Effective governance is based on enabling and then trusting your teams to do the right thing. However, effective teams monitor themselves through the use of automated dashboard technology and close collaboration, and the metrics that teams collect should be made visible to senior management and other stakeholders so that they may monitor what is happening.
- Govern by risk not by artifacts. Traditional governance often focuses on the review of common artifacts such as requirement documents, architecture models, and test results. Because it is relatively easy for teams to create the documentation that you want to see, in practice there is very little governance value in reviewing these artifacts. Agile governance instead focuses on addressing common risks such as ensuring there is an agree to vision for what the team should accomplish, that the architectural strategy has been proven to be viable early in the lifecycle, and that the team has produced sufficient business value for their stakeholders.
- Rolling wave over annual planning. Annual planning often begins in earnest mid-year which means that prioritized initiatives may not be actually delivered for up to 18 months in the following year. This is not business agility. Make your planning a continuous “rolling wave” activity year round with more detail devoted to planning initiatives no longer than 6 months out. Initiatives planned beyond 6 months should be described at a very high level.
- Prefer small initiatives over large initiatives. It is a proven fact that the larger the initiative the greater the chance of failure. Smaller initiatives are easier to plan and are lower risk to execute. Keep your initiatives small to allow for more frequent delivery of value with less investment in work in progress (WIP).
- Invest in quality. Ensuring that IT delivery teams produce new business value for your organization is clearly important. But so is ensuring that you will still be able to continue doing so a few years from now. To ensure the long-term sustainability of your IT teams you must allow them to make investments in quality. These investments include building high quality assets in the first place but also fixing low quality assets, what agilists refer to as paying down technical debt, as well.
- Optimize the whole. Disciplined agilists are enterprise aware. We choose to optimize the whole instead of locally optimizing a single activity. The implication is that you cannot consider portfolio management on its own but instead must consider it in the context of the other parts of your organization that it affects. A strategy that may make things easier to manage your portfolio, such as having a single way to fund IT delivery teams, may make it easier for your portfolio management efforts but could inflict undue costs and bureaucracy on the teams that you’re funding. For example, does it really make sense for a team asking for $50,000 in funding to go through the same level of rigor as a team asking for $5,000,000? Likely not. Context counts.
Our experience is that the philosophies describe above enable portfolio managers to be more effective in practice.
The following diagram overviews the potential activities associated with disciplined agile portfolio management.
There are nine 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.
- 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.
- 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.
- Finance endeavors. IT endeavors need to be funded. This includes both the initial funding for new project/product teams for their Inception efforts as well as ongoing funding for Construction, Transition, and of course operation of solutions once they’ve been deployed. Additionally, how the funding is applied will be monitored regularly to ensure that it is being spent wisely.
- 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.