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

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 introduced high-level portfolio management structures and processes. In this, the fourth installment, we’ll discuss some foundational practices and principles for achieving high-performance adaptive portfolio management specific to the supply/capacity side of the portfolio equation. Episode five and onward will tackle the demand side and the matching function.

Having established in the last installment that portfolio management is composed of three major functional areas, each with a unique set of competencies for effectiveness and maturity, let’s zoom down in elevation to discuss some practical principles and practices that enable success in portfolio management.

As presented last installment, the three major functions are:

• the capacity (or supply) side of the system (this installment’s focus)
• the demand side of the system  
• the matching function that allocates scarce capacity to infinite demand to maximize strategic impact and financial returns

Key Practices and principles for the capacity side of portfolio management

It may surprise some readers that a series ostensibly focused on OKRs for portfolio management would devote many words to managing and measuring delivery capacity, but knowing capacity is a foundational prerequisite to effective portfolio management. In the vast majority of situations, you MUST stabilize and measure delivery capacity BEFORE pushing major change on the demand side, or distrust, violated expectations and antagonism will become worse.

In some situations, capacity stabilization and measurement can be relatively simple – cycles per hour on a press, for example (ignoring tool changes, MTBF/downtime, maintenance, etc). Other scenarios, like a 600 person IT software development organization, delivery capacity can be extremely difficult to measure and forecast accurately. Old-school “best practice” software project management and IT portfolio management frustrate process control by constantly reshuffling the “factory floor” and inviting excess work in process (WIP), impeding measurement and forecasting. This is a huge contributor to the delivery delays and budget overruns that are so common in traditional IT organizations.

Stabilizing delivery to gain control and transparency can be very difficult, especially in highly fungible “humans are the factor of production” settings. It is even more difficult if the organization has a history and culture of overcommitting to excess WIP and ignoring foundational Lean principles like “move work to people; do NOT move people to work”. (It is out of scope for this series to provide an education in lean product development and manufacturing, but proven lean principles guide our approach to portfolio management. (Contact us on our site www.adaptivitygroup.com if you’d like Lean training or some recommended reading.) 

I will use the typical enterprise IT software development organization as an example of how to stabilize and measure capacity because 1. It is extremely common, even the norm, that IT organizations manage work and capacity badly… so badly that it makes portfolio management almost impossible to perform well.  2. It is so complex and difficult to make the shift to organizing and managing capacity properly in IT that almost any other capacity measurement problem in the enterprise is easier (but we can leverage the principles from this IT example to good benefit in other scenarios).

Medieval software project and portfolio management viewed utilization of expensive developer “resources” as a key metric to optimize for. (Side note: “Resource” is a dehumanizing word best avoided when referring to knowledge workers that the firm wishes to motivate and retain.) Traditional IT also valued the metrics on-time and on-budget but were, in fact, sub-optimizing those complex lagging indicators (and overall value delivery) in preference to the easy-to-measure, easy-to-drive, short-term metric of keeping people really really busy!

Closely wedded to the traditional resource management model were the funding and planning construct of the “project”. Traditional organizations tend to treat developers as undifferentiated widgets to shuffle between projects to maximize utilization. (Time and motion studies show that lost productivity from context switching more than offsets increased productivity from being “busier”.) In this context of constantly reassigning people to different projects, we’ve learned that trying to measure organizational capacity using individual employees as base “factors of production” doesn’t work well. Individuals are: 1. Too small and specialized at the task/code-commit level to produce actual throughput of value, and 2. Too variable in output from one employee/project/technology to another to be predictive. Consequently, these organizations are never sufficiently stable to permit accurate measurement of productivity or throughput (no, counting lines of code or function points isn’t effective either).

In modern software development, value is delivered through the collaboration of people possessing a range of skillsets (developers, testers, designers, ops, etc) ideally organized into stable teams committed to one (or few) technology assets that they focus on and master collectively as a team. A software development team (who can consistently ship working valuable product to users in frequent increments) is the smallest accurately measurable unit of production in a software development “factory”. By establishing synchronization and cadence among many teams in the organization, we can measure aggregate throughput of value, coordinate sequencing and dependencies, and begin to establish the lean principles of flow (and for peak performance, pull). THEN the system is in control, capacity is measurable, forecasts of future delivery are unerringly accurate.

Note that many organizations will require significant organizational redesign and restructuring of teams and employee assignments to fully stabilize delivery. Examples of reorganization could include:

• Shifting from component teams to feature teams (eg putting DBAs or middleware developers on each team, instead of housing them together in specialist team(s) that all other teams depend upon). If it is blessed to manage dependencies, it is heavenly to break them!
• Staffing teams to be more cross-functional so each team can deliver increments of product value more independently. This includes QA professionals (team assignments and reporting relationships may be orthogonal).
• After dissolving component teams and making teams more cross functional, imbalances in skillsets often become more visible enabling the organization to rebalance roles for optimum throughput.
• Making teams stable and permanent so everyone on the team is individually and collectively accountable to perform with quality and efficiency and deliver customer value.
• Aligning teams and groups of teams to personas or market segments and technology assets in a manner that develops their empathy and expertise

Here are a few example objectives and key results to drive improvement toward incrementally stabilizing the IT software delivery organization (all numbers notional):

Objective:  Our teams will be dedicated and stable to maximize performance and predictability!  

KRs:

1. Reduce employee regrettable attrition in development teams to below 5%.
2. Reduce each developer’s work from other than THEIR team’s product backlog to <5%.
3. Software development work shifts from 85% project bundled to less than 15% project bundled (ie 85% of work items are decomposed from discreet features and epics that deliver value).

Objective:  EVERY team delivers customer/user value!

KRs:

1. Dissolve half the component teams by reassigning their members to feature teams (probably repeated multiple quarters).
2. Increase the number of teams that contain every skillset they require to independently deliver working software from 50% to 75%.
3. Reallocate accountabilities for n teams from tech-stack orientation to persona/market customer value stream orientation.

Objective:  Exterminate dependencies with extreme prejudice!  

KRs:

1. Reduce inter-team dependencies from 35% of work items to 15%.
2. Reduce the number of teams that must participate in big room planning together from 90% to 40% (multiple smaller BRP sessions are OK).
3. Shift 50% of manual test coverage to automated tests that run every build cycle for early defect and conflict notification via continuous integration.

There is another big and difficult step required to stabilize the capacity side of your IT organization: you will need to deal with all that excess work in process (WIP) that the delivery organization committed to over months and years. The excess WIP should become obvious after the teams are formed and focused, and their throughput becomes measurable. Forecasting future portfolio delivery scenarios is based on observed historical throughput of releasable working software. Six Sigma process-control tools like standard deviation of throughput and cycle times will provide a confidence index on your forecasts through cutlines projected for optimistic, most likely, and pessimistic forecasts of future delivery. At that point it will become obvious that work queues are being chewed down at a pace that is MUCH slower than the project delivery dates committed to stakeholders and incoming demand for work, and that the organization is essentially constipated with compounding delays, rework, and replanning cycles.

NOW is the time to sit down with the stakeholders on the demand side of the portfolio equation for a tough conversation, after the organization has stabilized delivery and captured unassailable evidence of the organization’s true capacity. Confronted with hard statistics, stakeholders should be willing to engage to reduce excess WIP under the guidance and supervision of the matching function.

The invitation to this dialog should balance carrots and sticks. Here’s an example:
In our initiative to dramatically increase the value produced by the delivery organization per dollar invested, we have addressed many inefficiencies and improvements. In the past, delivery AND stakeholders together created an overloaded, inefficient, and opaque development system. Because delivery was opaque and its leaders were loath to tell stakeholders “no more”, delivery is now so overcommitted that current WIP will take 2.3 years to produce and release. Therefore, delivery cannot accept new features or initiatives until the queues are worked down, OR SOME OF THE WORK CURRENTLY IN THE QUEUE IS CANCELLED, PAUSED, OR REPRIORITIZED.

The portfolio management office will be reallocating delivery capacity to portfolios and stakeholders to improve return on investment for the company.  Stakeholders who engage constructively in this process to maximize portfolio returns will be allocated capacity accordingly.

We have set the stage to obtain stakeholder engagement to implement new techniques for value assignment and prioritization in order to dramatically improve portfolio returns! We’re now ready to optimize the demand side of the portfolio equation.

The first step in improving the demand side of the portfolio function will be to disaggregate those huge boluses of work called “projects”. These large and often arbitrary accretions should be broken into discreet features and functions. We estimate their financial and strategic value and cost/effort, then reprioritize them. They will not only be reprioritized within each project – features from one project will be prioritized against features from other projects within a portfolio. The project construct (for software development) will be abandoned as we move towards a continuous flow of valuable features being released to realize value frequently.

We reduce WIP by pulling work from the team backlogs up to the program backlogs, and from the program backlogs up to the portfolio backlogs, at the feature and epic level, to reevaluate and reprioritize the work. We typically leave about six weeks (evaluate for your organization) of work in team and program backlogs because this reprioritization process with backlog refinement/grooming and potentially mid-term big-room planning takes some time and we don’t want teams to be starved for work while we’re fixing the portfolio process. Alternately, if the team backlogs are of questionable value, a few weeks can be invested in paying down technical debt, designing an aggressive quality improvement program, and improving skills and technical practices like CI/CD/DevOps pipelines.  

The next installment of our series will delve into the demand and matching functions of portfolio management, starting with some exploration of how portfolios are defined, shaped and structured. I promise there will be more discussion of OKRs in the next installment!

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