Key Practices and Principles for the Matching Function of Portfolio Management

In previous installments of this series, jointly produced by Adaptivity and WorkBoard, we discussed high-level strategy realization processes and how implementing them with OKRs can dramatically increase success. The last installment focused on optimizing the demand side of portfolio management structures and processes. In the sixth installment, we’ll discuss practices and principles for achieving high-performance adaptive portfolio management, focusing on the third leg of the stool: the supply/demand matching function of portfolio management, which assigns finite capacity to infinite demand and provides overall governance of portfolio performance. 

Leverage OKRs to Achieve Breakthrough Portfolio and Investment Performance – Part 6

In our journey towards maturing an effective portfolio management process optimized to deliver strategic outcomes, we first focused on achieving strategic clarity through OKR-based goals and measures (installment 2 and installment 3).  

Next, we took steps to stabilize our supply and delivery functions so the organization’s capacity could be measured using empirical metrics from observed historical throughput (installment 4). We likely had to do some reorganizing and work in progress (WIP) reduction in the delivery organization to achieve transparency and measurability. At this point, we should also see meaningful improvements in the productivity and efficiency of the delivery organization.  

Once the capacity side of the portfolio equation was “in control” (in lean six-sigma parlance), we began work on the demand management side of the portfolio equation (installment 5). We  

• endeavored to define and shape our portfolios,  
• specified appropriate asset allocations to each of our business units and product lines,  
• created transparent rules for value assignment and prioritization (potentially leveraging investment sectors), and  
• trained our stakeholders to break down large initiatives and projects into smaller components that we stack-rank into a portfolio backlog or queue (a backlog is simply a queue that a stakeholder can change at will because it’s not committed and not WIP).  

Now that the capacity/delivery side of your organization is providing accurate measures of capacity and the demand side of your organization is assigning financial and strategic value accurately, we should mature the third leg of the portfolio management process, the matching function. 

The matching function oversees the processes by which the organization  

1. allocates finite capacity to infinite demand (essentially creating an efficient economy for competing consumers of a scarce good)  
2. measures and governs portfolio results and  
3. reallocates resources and capacity to realize higher performance  

We are optimizing the matching function to allocate funds and capacity in a manner that:  

1. maximizes financial returns and strategic impacts for the organization  
2. is adaptable and responsive to change  
3. increases accountability to deliver outcomes  
4. is perceived by all stakeholders as transparent and fair  
5. is efficient (quick, low conflict, low waste) 
6. embraces learning and continuous improvement  

We can define OKRs for each of these capabilities to drive maturity and improvement. One of the measures of a mature, high-functioning matching function is the speed and fidelity with which it can run many demand scenarios to evaluate and compare options. Those scenarios come directly from the demand queues where we compare various prioritization and sequencing combinations and then, ideally, decompose some larger initiatives into smaller components that can be blended with the highest value components of other initiatives. We continue decomposing, reprioritizing, and reevaluating increasingly more valuable scenarios until returns are maximized.  

In the installment focused on demand management, installment 5, we introduced some techniques for assigning value to initiatives – hard financial benefits and harder-to-quantify soft benefits like strategic impacts. In the multi-stage portfolio analysis process, we initially generate very rough estimates of cost, we let stakeholders reprioritize initiatives based on their “gut” sense of the value of their initiatives, then progressively increase the precision and accuracy of estimates (accumulating sunk costs) as the likelihood increases that a given initiative might actually make it to production.  

At this point, let us introduce a method we developed for fast and relatively inexpensive coarse portfolio level cost/benefit measurements for items in the portfolio queue, as well as to evaluate initiatives in process to inform stop/continue/pivot decisions. When we developed this measure, we were estimating products developed by teams, so we named the metric “Return on Team” (ROT). This method functions equally well for large delivery groups, work cells, fleets, and production lines, so you could use terms like “Return on Delivery Group” or “Return on Production Line” if that’s more appropriate to your setting.  

The math for ROT is simple: the divisor is the cost per period or cycle (week, iteration, or month) to sustain the delivery capacity. The numerator is benefit per that unit. Our default for software development organizations is the benefit per iteration (possibly being realized over a month or more) divided by the cost per iteration (usually two weeks). Ideally, we’re leveraging measures that acknowledge the time value of money on the cost side and awareness of the timing of benefits realization on the benefit side. Still, when introducing these measures, it’s best to keep it simple until the process matures, so don’t start with real options or other complex analytical models.  

Most investment opportunities have a cost of delay (COD) associated with them. COD is a lean product development concept that spawned metrics like weighted shortest job first (WSJF) and other variations. Larger initiatives often have inconsistent or lumpy flows of costs and benefits over time – so sequencing and timing of feature delivery matters. Your company’s Financial Planning and Analysis (FP&A) professionals are ideally suited to contribute to developing these metrics and have mastered analytical techniques and tools to model and compare financial scenarios efficiently, so request that FP&A be engaged with your portfolio management team.  

Costing metrics based on Return on Team are particularly impactful in IT organizations that have a history of treating workers as fungible widgets because it encourages us to see the team (not individuals) as the foundational factor of production. This maximizes team stability and focus and enables teams to become more effective by working collectively. Ask yourself why in any sport a mediocre team can always beat the “All-Star Game” team. Even though the All-Star Team is comprised of the best individual players in the league, they’ve not formed as a real team, so they are overmatched by lesser players who’ve mastered competing together as a unit.  

This decoupling of capacity from demand facilitates the portfolio managers’ ability to minimize friction when he chooses to reallocate some capacity to higher-value initiatives, portfolios, or product lines. Team-based capacity planning encourages organizations to fund the teams in the delivery group as assets to value and develop and discourages organizations from performing pathological “resource management” that assigns time-slices of fractional humans to multiple projects. 

For IT organizations with a history of traditional project-based resource management​—where people are assigned projects and tasks—shifting to a model that assigns work to teams can be a huge adjustment. However, individual resource assignment and time slicing invariably obfuscate organizational capacity and produce overload from excess WIP, with all the consequent waste, delays, and inefficiency. 

In order to use “ideal team iterations” (or weeks, etc) as our foundational coarse metric for sizing and costing initiatives, we first need to define an “ideal team” (or work cell or line) for each delivery model in our operation. For example, a team in Palo Alto might have a cost much higher than a team in Bangalore justifying different ideal team models to produce acceptable accuracy for each delivery group. On the other hand, the difference in cost between the cheapest and most expensive teams within each location isn’t sufficient to impact accuracy at the portfolio management level. The same logic applies to production lines – a line focused on stamping sheet metal will require a different model than a line containing an advanced CNC machine producing precision millwork.  

The ideal team model will specify:  

1. Roles (or machines) in the team/cell/line 
2. Number of members (units) in each role 
3. Cost per role  
4. Cost per iteration (or cycle or shift or whatever)  
5. Number of iterations or cycles available in each of your critical portfolio planning and governance time horizons (per week, month, quarter, year, etc.)   
6. Cost per each of those critical time horizons (cost per iteration x number of iterations available in that timeframe) 

The benefit we obtain from generalizing ideal team costs is that it allows us to speed up (and reduce the cost of) our size/cost estimation process dramatically and evaluate (and reject) many more investment options faster. Absolute accuracy at this stage is not tremendous, but relative accuracy is sufficient to enable leaders to make informed tradeoff and prioritization decisions as we rapidly compare candidates. 

Continuing our software development example: Let’s posit that we have 60 teams that are stable and dedicated to one (or several related) software product assets. They can deliver working software to stakeholders and users every two-week iteration. Because the constituent teams are stable and dedicated to team-based work we know how much each will produce for any future time horizon (with a two-week resolution). We can forecast how much “stuff” stakeholders should expect for any date in the future, with tremendous accuracy, and we can predict delivery for any team or aggregation of teams up to and including the entire 60-team delivery organization. The ability to show stakeholders the “hard math” that demonstrates the delivery capacity of the organization is essential to  

1. getting everyone to acknowledge at what point the organization is “full” to avoid the waste and inefficiency of excess WIP, and  
2. consequently force stakeholders and product managers to make unpleasant tradeoff decisions selecting what won’t be built in a given timeframe.  

To inform those tradeoff decisions using our capacity forecasts, we project a “cut-line” onto a work queue or backlog for any time horizon requested. For each proposed combination of features, initiative candidates, and/or projects, we answer the question, “In this scenario, which items can you deliver by such and such a date (e.g., the end of Q3)?” Everything above the cut-line is “in”; everything below it is “out.” We can even leverage six-sigma statistical process control techniques to infer confidence intervals with “optimistic” and “pessimistic” bands around our “most likely” projections. The better the delivery organization, the narrower the band between optimistic and pessimistic. In any case, when stakeholders are confronted with a capacity limit based on observed throughput and empirical measures (rather than weakly supported opinions) they proceed to break down items, reassess size and value, and reprioritize items to ensure the items they value most are above the line. Many scenarios are modeled, decomposed, reprioritized, and reassessed until we produce the backlog that maximizes returns. The matching function helps ensure we avoid unwarranted debates about capacity. It ensures that the delivery organization is not pressured to overcommit or permit excess WIP (really the idea of a release “commitment” in this context is an inappropriate and unhelpful anachronism).  

As introduced in a previous installment, we strongly recommend using a multi-stage analysis process to enable progressive analysis in any enterprise portfolio management scenario. As repeatedly stated in the series, analysis is expensive and a form of WIP. We are accumulating sunk costs on at least SOME things that should never actually be done; thus, premature requirements elaboration and excessively precise estimating are forms of waste.  

The portfolio matching function is responsible for managing the analysis and intake process. The first stage is always a huge “idea bucket” or funnel that represents all the stakeholders’ wants, wishes, and partly formed ideas. The second stage of analysis should be designed to provide just enough accuracy and precision to kill unattractive investment candidates as quickly and cheaply as possible. Very rough measures of cost/effort focused on relative (not absolute) accuracy enable stakeholders to say, “Well, if initiative 3 is really twice as expensive as initiative 4, I don’t want it, because my gut tells me it’s not twice as valuable.”  

The third stage of analysis pulls from the top of the previous queue to perform a more detailed (and expensive) analysis including value estimation and initiating cost/benefit analysis. From a lean product point of view, we’re investing analysis capacity incrementally in each feature or initiative as it proves valuable and moves closer to production. Critically, both analysis queues have WIP limits enforced by the portfolio matching function to ensure (here’s that guideline again!) that we’re not creating excess analysis WIP. Set your WIP limits based on the average size and duration of work items, how fast you can perform analysis, how quickly production can consume items from the queue (cycle time), how volatile your business is (permissible lead time), and how much old stale junk you are willing to have sitting around in the queues while life (and the competitive landscape) passes you by.  

A Few Principles To Strive For In Lean Portfolio Management  

Decouple supply from demand by stabilizing the “factory floor” and moving work to it – do not tie workers or machinery tightly to projects or jobs. This enables you to switch the work being fed to production with minimum drama and cost.  

Support constant reprioritization and injecting new ideas/info anywhere in the process. Be willing to kill projects or initiatives when changes reduce their value. When business conditions change due to competitive or environmental pressures, those who respond the most effectively and quickly turn change to a competitive advantage.  

Decompose work into smaller chunks and maximize the amount of work NOT done to accelerate value realization by finishing work earlier and enabling more responsiveness to capitalize on new ideas and information. Low-value features hide in larger initiatives. Decompose work to find and deprioritize the junk obscured in a project wrapper. Every list of features from a project has deteriorating value as you deliver over time (if you’re doing it right). See if you can “trim the tail” by killing the project when the remaining features are less valuable than the features of the next initiative.  

Implement flow and then pull to reduce WIP and balance capacity with demand because excess WIP is a huge driver of waste and inefficiency, and it undermines agility. Pull-based systems revolutionized manufacturing and competitiveness of leading companies around the world, along with other Lean-based principles. It’s not easy to accomplish, but nothing will have a bigger impact on your productivity and efficiency.  

Plan quarterly with defined tangible outcomes by using OKRs and metrics that align with your desired business results.  

Give sponsors control of value assignment and prioritization. Hold them accountable to deliver outcomes and impacts by defining business OKRs that they are realizing. The matching function shouldn’t care if a feature performed well nearly as much as if the product line is achieving a high Return on Team or production line over a quarter-over-quarter basis, relative to other investment portfolios.   

The matching function should work with leadership to shift the organization’s investment mindset to have portfolio processes that less resemble the horrible, stodgy corporate annual budgeting process and more resemble the nimble meritocratic approach typical in venture capital organizations. VCs provide provisional or conditional funding based on performance. In a VC model, funds are issued in tranches based on performance. Further investment rounds in portfolio holdings are constantly weighed against emerging opportunities for investment as they pop up. When another portfolio opportunity exceeds the value of an existing investment, VCs don’t allow sunk investment to drag down their portfolio returns; they shift capital to better investment targets.  

This wraps up the final installment of our series on aligning strategy and portfolio management. I hope you have found this series valuable and have discovered a few innovative new elements to improve both your strategy realization processes and the investment processes that support your organization in achieving its strategic objectives. Obviously, there’s a great deal of depth and detail below these principles and practices. Feel free to reach out and advance the dialog.  

This series provides a host of (hopefully) intriguing insights to help organizations realize their strategic objectives and get better outcomes from their portfolio management and asset allocation processes. Implementing all the processes, practices, systems, and cultural and behavioral changes to make strategy reality in your organization requires expertise and experience. Adaptivity employs some of the leading experts in the field.  

We’d like to hear about your challenges and goals and help you succeed! 

We can be reached at www.adaptivitygroup.com and www.workboard.com