The SOSD method – The portfolio

Due to the need of virtual cross-functional delivery structures for product development in bigger organizations, there is therefore automatically a need of a portfolio which is the interface between the line hierarchy and the virtual structures. The portfolio is also responsible for, and keeping track of the thorough planning and prioritization of all the different on-going initiatives in the organization. From the road map, the portfolio gives the responsibility for operating the initiatives to the virtual structures. The initiatives started by the portfolio need to follow the portfolio strategy, that in turn ensures strategic alignment with company goals, derived from the purpose of the organization.

With a portfolio, the executives, team leaders, team members, and stakeholders get an open and overall view of the initiatives run by the organization. This also includes how the initiatives fit into the organizations vision, mission and strategy, which in turn leads to insights into potential returns and what risks that can be seen. The need of a portfolio goes for both software and hardware organizations, where the latter also have a research organization, that normally is outside the portfolio management. This is because research is highly complex and therefore impossible to say what the result will be and when it comes. This makes research inappropriate for the portfolio and its initiatives, since initiatives are something promised to the customer and therefore must be less complex. For smaller organizations it is normally enough with a portfolio handling function.

As stated before, it is very important that the portfolio can handle the most complex initiatives that the organization will have, otherwise the organization will run into huge problems sooner or later. Complex initiatives normally means that the portfolio, already from start, needs to be able to handle new product development, which is really the complex part of the product development life cycle. Starting off with a portfolio, that only can handle maintenance and small functional enhancements in an existing product, which is rather a clear (easy) context in an organizational point of view, the risk is high that the portfolio will not be fit for purpose, and only be made for shovelling around money. This is unfortunately common in transformations to agile at scale, where the bottom-up transformation starts with non-complex initiatives for the agile teams, like maintenance or a small functionality lift in existing systems structures and systems test environment. If a portfolio is adapted to that non-complex work, the portfolio will then only have the ability of dividing money into kind of autonomous parts, with little or no possibility of follow-up. This problem is especially true for organizations that do not only fully understand complexity, or not taking care of dependencies and interdependencies, but also those organisations that only plans with only the length of the nose, which is the case with many scaling agile frameworks. Without these kinds of understanding, the portfolio will more look like some kind of ATM, dividing money to parts, like they were not connected at all, like when people taking out money from the ATM. Instead, the portfolio always must take the most complex initiative into consideration, which requires systems design, with resulting interconnected parts. And this does not mean just to divide money to parts without connection or where the connections already are set, since that can only be done in a Clear context, where we know that the parts are coherent and cohesive, so we can just aggregate them. The highest risk for portfolio failure is organizations that come from a Clear context; banks, insurance companies, governments, and other service companies, since they are used to a portfolio that are more like an ATM machine, since they have been used to buy in the products, that they now need to develop themselves.

The above discussions give us the necessary foundation for a big product developing organization, but since the market today is rapidly shifting, we need to add to the portfolio, also the possibility to be fast, flexible and adaptable. We have two different cases that the portfolio needs to be able to handle, which both are close to, but should not be mixed up with the research needed for hardware organizations, that is needed in order to reduce disciplinary complexity.
The first one is regarding organizations that will need virtual structures (maybe a team), that experiments with a new customer need, meaning high uncertainty in making the right product. This can be done by experimenting with for example MVPs, Minimum Viable Products, with very short feedback loops. This means also adding sketches, drawings, pictures, logic flow in power point or similar, etc., to make the feedback extremely fast, like when making the UX or the industrial design component.
The second one is about looking at competitors and especially other domains, looking for technology, processes, tools, etc. that can be used in the own domain. If something is found, that can be used in our own products, that will lead to input to the normal back log of the portfolio. We are here more talking about making the product right, i.e., reducing transdisciplinary complexity or transdisciplinary complicatedness in the product, where even some hardware research also may be needed first.

The next blog post in this series of the SOSD method will examine some examples of common root causes for some different way of workings.

C u soon 🙂

Leave a Reply