Program Management

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.

PMO Role in Agile - Part 2

My initial blog seemed to have some interest judging by the number of views it's received so I'm guessing that it's a topic that many are looking for input on.   So I thought I'd provide some more thoughts as to what a PMOmight  look like in an Agile organization. One of the key things that changes with a traditional Project managed organization is that they must change to one that is Product managed.  What this means is that the organization changes the way that it funds its business by essentially providing Product Owners with Scrum teams that will deliver on their vision for their product.  Given this paradigm, along with the creation of the Scrum Master role, the PMO and subsequent project managers are left outside looking in.

Managing Product driven teams means that you are managing towards outcomes that delivery value over projects that deliver features.

In my previous post I provided some suggestions as to what individual Project Managers could do to make themselves more valuable and productive to their teams.

In this post I will suggest a PMO structure that focuses on the Portfolio view and leaves the operational execution of the roadmap to the Scrum Teams and Product Owner.

For this structure to work the organization needs good Scrum Masters and preferable ones that aren't also individual contributors for their team.

The structure of the PMO will be lighter than you might think is right, but I'll argue that if you have the same number of Scrum Masters and Project Managers you will set up role confusion that will make your entire project management process cumbersome and less productive.

The PMO structure would look something like this:

PMO Org View - Agile

I think one of the things that a PMO organization needs to be aware of is that their focus is not on control of projects and people but on how teams are performing.

With this structure you have a thinner level of Project Managers who are focused on Program level Product Management (PPM new acryonym anyone?). Your Project Management function becomes one of oversight of Scrum Masters and working closely with Program Managers in other Product groups who probably will have cross org dependencies.  The Program Manager level in this structure is more about working to ensure that teams are working on the right things based upon the Product Roadmap and escalating when individual team priorities become out of line with the overal corporate product objectives.

What we want with a PMO is confidence and how we do that historically is to place controls, gateways and processes designed to show that teams are checking off boxes that we believe represent how a successful project should unfold (aka Project Governance)

How we do that in an Agile organization is to ensure that our teams we have a clear Product roadmap, that we are performing effective planning both in the areas of Product Discovery and Release Planning, that teams are provided time to review and estimate the work that they are being asked to commit to AND ensure that teams perform continual inspect and adapt cycles via Retrospectives.

If teams are allowed to form into solid high performing teams what you get from that is an organization that learns how to estimate accurately, which leads to consistent velocity which in turns leads to predictability....which is what we in the PMO (and Sr Management) are looking for, simple right?

What I learned years ago from my Project Management days is that Agile actually provides you with much more visibility and transparency about what is happening with your commitments,  providing you as the stewards of the product an ability to have fact based conversations with stakeholders who rarely understand the complexity of what they are asking for.

Member Login
Welcome, (First Name)!

Forgot? Show
Log In
Enter Member Area
My Profile Not a member? Sign up. Log Out