For product development there is always a need for a portfolio, an enterprise portfolio, that structures the strategical and tactical planning, and prioritization of initiatives in the organization. The portfolio, that is the responsibility of the line hierarchy, consists of a sponsorship function, and can be placed in a portfolio office or similar, and is mostly represented by higher level managers, taking the strategic decisions. The portfolio is most of all responsible for the WHAT to do on the organizational level, as well as the money for doing the initiatives, where doing the right initiatives is strategically important, in order to be competitive and fast to market with the right products. As stated before in the introductory article in the System Collaboration Deductions series, it is important that, in order to implement a proper portfolio, we need to understand the way of working for the product development, which includes the full product life cycle. Especially for big systems where we also for new systems or enhancement need to do the systems design or look over the existing one. This always means reducing the transdisciplinary complexity/ complicatedness, which in turn induces iterations in order to gain new knowledge about the systems design, architecture, systems test, et al. It is actually about coding from a well-thought-out systemic hypothesis on how the system shall work, and absolutely not only about specifications, i.e., actually no difference from developing a hardware platform in Lean Product Development. These iterations mean a preparation phase that is very uncertain regarding the time perspective, and must be something that the portfolio can handle, both regarding money and planning. Reducing this transdisciplinary complexity/ complicatedness in product development is clearly exemplified in the picture in this TDSD article. The iterative part is to the left under Complex, which is also shown as the iteratively making the systems design in the pictures in this TDSD article, showing how the architecture iteratively emerge by the team of teams, until fulfilling the non-functional requirements. Taking care of the non-functional requirements is actually no difference depending on domain; buildings, bridges, software, electronics, etc.
The portfolio office is also responsible for the overall HOW to do it, the high-level way of working, but the initiatives are then handed-over for implementation by the operational virtual delivery structures, where the actual product development and therefore TDSD comes into the picture. This means that the portfolio gives the responsibility for planned initiatives (WHAT) to the virtual delivery structures, but the portfolio is always accountable for all initiatives. The virtual structures are then responsible for making the best, and most efficient as well as effective HOW, under the current circumstances, for delivering the whole initiative. By having virtual delivery structures, micro-managed by the managers in the line hierarchy can be avoided and sub-optimization can be reduced. The portfolio is not leaving the virtual structures just because the responsibility for the delivery of the initiatives is moved to the virtual structures, since in the end the portfolio will receive the result of the initiative. The portfolio therefore has functions for supporting the virtual structures. This can be both regarding the need of changing the initiative (steer function), or of supporting and advising character (reference function), for helping the initiatives to fulfil their respective goals. Many times, these supporting functions are line managers, both as receivers of the implemented system, or just supporting to achieve a successful implementation.
The plan forward of all initiatives are shown in the road map at the portfolio level, with rougher finishing times the more in the future the initiative is planned. For already started initiatives, the Interdependency and Delivery Board, will show more details about dependencies between different initiatives and when they are to be delivered. In that way a delay of an initiative will be clearly shown for everyone, and the appropriate actions and mitigations can be taken. Very big organizations, which more or less has small companies as silos producing their own products, may have their own respective portfolio. Traditionally a portfolio was called a project portfolio, but here we will talk about initiatives instead of projects, so we will just call it portfolio.
From the road map, the portfolio gives the responsibility for operating the initiatives to the top-level of the virtual structure, the wholeness level. The initiatives started from the road map 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.
It is worth to mention that for smaller organizations it is normally enough with a portfolio handling function.
The portfolio will be placed in the portfolio office in the line hierarchy, where also people responsible for different initiatives will be placed. The portfolio office gets the money for the initiatives and is responsible for the overall way of working, as mentioned above.
As stated earlier, it is a necessity that the portfolio knows about how the overall product development process, since the portfolio is responsible for the money of all initiatives, where the virtual structures can be dynamic, static or a mix of them. Especially the need of exploring the systems design is vital in planning of the portfolio, where some work of higher-level teams, needs to be done, before the lower-level teams, doing the actual design of the parts, the components, can start to work.
The next blog article in the TDSD series is about the wholeness team.