Risk and Return

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.


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:
 Efficient Frontier
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.