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. The portfolio is the interface between the line hierarchy and the virtual delivery structures, even though the portfolio team itself also can be seen as a virtual structure. The portfolio is also responsible for, and keeping track of the thorough planning and prioritization of all the different on-going projects/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, normally within a portfolio office, 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 already from start, 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 life cycle of a product. Starting off with a portfolio, that only can handle maintenance and small functional enhancements in an already 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, like maintenance or a small functionality lift in existing systems structures and systems test environment. If a portfolio from start is only adapted to non-complex work, the portfolio will then only have the ability of dividing money into kind of autonomous parts, for example value streams or team of teams’ constellations, with little or no possibility of follow-up on the whole. This problem is especially true for organizations that only do not fully understand complexity, or not taking care of dependencies and interdependencies, but also those organisations that only plan with the length of the nose, which is the case with many agile scaling 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 people taking out money from the ATM. Instead, the portfolio, when it is designed, must always from start, be able to take the most complex initiative into consideration, which requires systems design, with resulting interconnected parts of the product. 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 a portfolio failure (leading to product failure as well) is when 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 instead need to develop themselves.
The above discussions give us the understanding of the portfolio as a 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. They are both close to each other, but not similar and should neither be mixed up with the research needed for hardware organizations, which instead is about reducing disciplinary complexity. The two cases are about uncertainty respective transdisciplinary complexity/complicatedness, and the following explanation shows the difference between them.
The first one is regarding organizations that will need virtual structures (maybe a team, within the wholeness level), 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. Note! The uncertainty on a whole product, shall not be mixed up with making the UX interface or the industrial design component (the look and feel of the product), when already knowing what product to do, even though they are very similar regarding the way of working.
The second one is about looking at competitors and especially other domains, investigating for new technology, processes, tools, etc. that can be used in the own domain, also part of the wholeness level. If something is found, that can be used in our own products, that will lead to input to the normal backlog of the portfolio, maybe to become a future initiative. We are in this case talking about making the product right, i.e., reducing transdisciplinary complexity or transdisciplinary complicatedness in the product, using existing material. For hardware organizations, this may of course also first need hardware research (reducing disciplinary complexity) that normally is separate from the portfolio, as mentioned above.
Next article is the last one, and the summary part of the series.