TDSD – Test-Driven Systems Design – The portfolio team

For product development there is 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. 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 very important in order to be competitive and fast to market. As stated before in the blog post about SOSD, it is important that in order to implement a proper portfolio, we need to know the way of working for the product development. 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 hypothesis on how the system shall work, and absolutely not only about specifications, i.e., 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 as the last picture in this blog post, which is the last blog post in the series about our first trembling steps towards our Method. The iterative part is to the left under Complex, which is shown as the iterative systems design in the picture above, showing how the architecture iteratively emerge, 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.

As mentioned above, we will also have support functions of different kind, CM, release management, systems testing, etc, that can be centralized if suitable. These functions can never be part of the teams of many different reasons (more details in the SOSD blog post); the wholeness is not within the parts, every individual does not think everything is fun to do, some competencies require a very long education, it is not possible to learn everything (brain overflow), and finally plan and prioritize the wholeness within 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 post in the TDSD series is about the wholeness team.

C u soon 🙂

Leave a Reply