Delivery Risk is Found in Your Teams

In my QValue Portfolio Scoring model, the way we develop the risk model is to focus on our teams. The reason we do that is that teams manifest risk in your organization and if you look at their delivery cadence sprint over sprint you can assess the risk of delivery by quantifying the team’s predictability.

Predictability often becomes a weaponized performance metric, but this is not at all what you should be doing. First, you need to understand that a team’s predictability is a manifestation of the inefficiencies of the organization in general. For example, if there is an inefficiency in the flow of work to teams due to a lack of strategic direction and roadmap, this will manifest itself in team delivery cadence as they jump from one top priority to another.

Risk in the QValue model looks specifically at the cost the risk may entail. We don’t directly look at risk from a delivery date perspective as we are focused on delivering small strategically aligned outcomes that are associated with an expected return which is then compared to the expected cost of acquiring that value. Unpredictable teams, through no fault of their own, have a higher risk of their estimates (and cost) being larger and taking longer to deliver.

Moving to an investment mindset for our technology portfolio we need to assess our expected return relative to the risk to that return from a cost perspective. At some point in time cost may exceed the return. The QValue model provides the framework to make informed decisions on whether to continue investing or move to something else.

If you want to understand where to invest in organizational/process improvements, look no further than the impediments your teams face, from lack of strategic direction, siloed management decision-making, and lack of clear objectives to high levels of technical debt or lack of automation. Your teams are the guiding light showing you where to make organizational process improvements that will support the smooth delivery of valuable technology solutions.

Developing an Investment Mindset for Product Development

In general, when deciding what projects to work on during their annual planning cycles, most organizations use a cost-based approach to make those decisions.

Leaders in the organization know the project buzzwords that will move them above the line, the demarcation zone of approval they strive for. CapEx/Opex is often a key component in decision making, however, this focus on financial goals keeps us from aligning our ideas to long-term strategic goals and growth.

One of the reasons we fail to maximize our returns with software development is that we aren’t treating it as an investment, instead, it’s a cost center to be managed.

The difference between an investment and cost is both a mindset as well as an expectation. When we invest in something we do so with the express expectation that it will grow in value over time. Think of the investment you make in your 401k’s, you expect over time that the amount you put in will grow over time. Product investment needs to follow a similar approach. 

Every new feature or enhancement is an investment in the future returns we expect to receive from their development. But not every investment type is the same and we need a way to define what our Product Investment strategy is so that we are confident in receiving appropriate value from each incremental investment.

Portfolio money managers can approach building long-term value by leveraging what’s called Markowitz’s Efficient Frontier Model. This complex mathematical model has an implicit assumption that says each investment (Stock/Bond) and investor have a risk and return profile associated with them.

My risk and return profile will lay the foundation for my investment strategy. If I’m nearing retirement I’m going to be more conservative and risk-averse concerning my investment decisions. Conversely, if I’m young I’m likely to invest a certain percentage of my capital into higher levels of risk so that I grow my portfolio more quickly.

Organizations are no different and by developing a risk/return profile for your organization you can begin to understand, quantify and communicate your Product Investment strategy to your organization.

As a Product Manager/Owner I need to understand the risk/return profile of the organization and incorporate that into my Product Investment strategy. For example, if I work for a highly regulated organization in a mature industry, my goals may different than a start-up seeking to grab market share or differentiate themselves in the market. 

Each organization has different approaches to risk and return, however, this concept does not readily exist in most organizations, the reason is that we look at software development as a cost to the organization, which explains our primary focus on the cost of a project. 

Yes, we pay lip service to what the value the project is supposed to deliver, but let’s be honest we don’t typically have metrics in place to track the value the project is supposed to deliver, and in the end, we are happy to deliver something and declare victory.

Where I have implemented this model before I’ve seen that it changes the conversation across the organization, from leadership down to the team level. Combining a Product Investment approach to our Product Development initiatives with the generation of a value score that is tied to strategy, we begin to discuss more deeply why something should move forward from a place of value and investment over budget and timeline.

If you are serious about developing an Agile Delivery model, you must create a value-based investment approach to your Product Development.

Investment Portfolio Management Applied to Product Management

I've been telling myself that I needed to attempt to apply formal investment portfolio management techniques to how we value, prioritize and manage our portfolio of product development efforts, so here goes (definitely still a work in progress)

Back in 1950's Dr. Harry Markowitz created an investment model called the 'Efficient Portfolio'.  Markowitz stipulated with his theory that an "Efficient Portfolio is one where no added diversification can lower the portfolio's risk for a given return expectation (alternately, no additional expected return can be gained without increasing the risk of the portfolio)".

The Markowitz Efficient Frontier is the set of all portfolios that will give the highest expected return for each given level of risk.

 

This model set the framework for how current money managers build a portfolio of securities that provide range of investment returns to meet each investors risk profile.  Providing investors with a broad range of risk/return choices allows individual investors to build an investment portfolio that meets their specific risk threshold with respect to a given rate of return.

An efficient portfolio looks like this:

 

When you are younger and have time to take chances your risk/return profile might be higher on the frontier, whereas at retirement you will slide down that scale as you are more interested in protecting your total investment.  One thing to note is that if your risk/return data falls above the efficient frontier, then you are accepting a level of risk that is not in line with the rate of return you might receive.  Pushing past the efficient frontier can open you up to unexpectedly high returns but conversely you can also expect very high negative returns due to the risk you are taking on.

Product Development organizations can utilize the Frontier as well, for example, a young startup will have a much higher appetite for risk as they understand that to take market share from competitors they need to take risks with speed to market.  However there are specific elements of risk that need to be considered as you speed your product to market.  Ensuring that Usability has been considered, Prototypes have been developed, code quality is considered and test automation all need to play part when you are building your risk/return Efficient Frontier for your Product Portfolio.

If we were to apply the Efficient Frontier to how we manage our Software Development investments we could build a risk/return profile that is easy to understand and align with the organizations risk/return profile.   There are many software projects that at inception are known to be risky, however a lack of empirical data often means that the projects will get the green light and then fail miserably.  The organizations inability to accurately asses risk/return at any time with their software development investments is a huge blind spot and keeps us from consistently delivering the value that the organization needs to stay competitive.

Agile addresses the value (return) part of what the Efficient Frontier speaks to however it talks nothing of Risk overtly.  Risk is more implied with the notion that we manage it by delivering in short increments and focus on shipping value consistently.  However Risk is more quantifiable as I mentioned earlier.

Building an Efficient Frontier in the investment world is a data intensive effort, which our current product/software development processes doesn't easily support.  However I believe that we can use the formula that Markowitz created to generate an Efficient Frontier for Product and Software Development organizations.

For this effort we will make some assumptions with respect to the Frontier model and changes to Markowitz's formula so that it works with our limited data set:

1. Portfolio = Product Development
   1. An organization can have several Products in their Portfolio -
      1. Consumer Facing
      2. Internal Facing
      3. Infrastructure
      4. Research and Development
2. A security is equivalent to a Scrum Team.
   1. These would equate to the individual securities that Markowitz speaks to in his model.  Where an investment portfolio consists of many securities, each with their own risk/return profiles so to does an organizations product development portfolio consist of the same.  Each team is a security that can on its own provide return that comes with an associated risk.
   2. Though we don't think of investment securities as having dependencies (as software development teams have) in fact a diversified investment portfolio consists of a range of investments that will perform a certain way based upon the dependency that business has to the market that they operate in, so in this case the notion of a portfolio still holds as a viable means to build a Product Development Efficient Frontier.
3. Potential Risk Parameters:
   1. Development Lifecycle - Waterfall, Agile, RUP, XP, Blended (use at macro level). You could equate this potentially to Bonds, Stocks or other investment instruments.
   2. Experience of Team
   3. Number of Scrum Teams
   4. % Test Automation
   5. Code Complexity
   6. Speed to Market
   7. Roadmap volatility

In my next post I'll provide some supporting ways we can 'build' an efficient frontier for Agile Product Portfolio analysis that both Product and Program Managers can utilize to assess priorities for the entire organizational backlog.