The SOSD method – Introduction

Welcome to this blog post about the Systemic Organizational Systems Design – SOSD method, which is the third blog post in the series about Dissolution of Organizational Problems.

Since SOSD solves any organizational root causes from SPPA. SOSD is generally (like SPPA) also a context independent method for dissolving the problems and makes a flourishing way of working in any context; production, service, retail, product development, etc., even though SOSD concentrates on the complex content of product development.

SOSD is also a blog post series itself, since it has many important parts to consider. It deep-dives into the overall thinking, as well as the parts. In these different blog posts, we will go through introduction, top-down integration, planning from the purpose needed, line hierarchy, systems design, virtual delivery structures, portfolio, examples with common root causes and summary. The reminder of this introductory blog post, will be a short summary of the whole series.

Introduction
In this blog post, as well as for the whole blog book, the focus is on achieving flourishing way of workings, especially for product development, in the domains of software (pin-pointed), hardware or combinations, which means that the focus is on dissolving the problems from a Complex (context), with reference to the Cynefin Framework. SOSD proposes domain independent solutions for the root causes of the current product development way of working to be enhanced. Remember that the organizational principles are domain independent, even if we choose a context, which is the reason why there is actually no difference between product development for hardware and software, since we still need to follow the organizational principles for a complex context.

It is important to go through WHY we need to dissolve the root causes in a complex context the way we do in SOSD, since there will be a required and therefore prescriptive order of the high-level HOW. Shortly, this depends on the need of a top-down approach organizational systems design when implementing any new way of working in any context. This need of a systems design of the way of working, in combination with the narrow solution space in a complex context when developing new products, gives a very prescriptive order of HOW for any domain in a complex context. This domain independence within a Complex context, means that this prescriptive order is valid and must be fulfilled also for hardware product development, before the hardware domain and the domain knowledge of the organization, will nail down to for example waterfall with projects, or Lean Product Development. For development of big software system, this is also valid, which is the reason for that TDSD for software (and hybrids) is now under construction, where we will go into the domain specific HOW when developing big software systems. Included in this order is also the important systems design for the actual products that is needed for all product development. And it is actually already here, as we soon can see, when deep-diving into systems design of our products, that we understand that we need fast feedback also on our systems design for big systems. That is where the concept of test-driven systems design starts to grow, actually valid for any product development.

With product development is meant the whole product life cycle of product development, from ideas to maintenance, i.e., new product development and not only maintenance or some small enhancements of existing products with their existing systems design and architecture. If we think about that, we per se need to be vigilant to any bottom-up transformation in product development, since the start often is maintenance or easy and small enhancements which is a fairly easy context. This is due to that the systems design, architecture and systems test (and its test cases and environment) of the product are already there, it has earlier in an integrative approach, already been scaled down to coherent and cohesive parts to make the whole system, in a (hopefully) planned and iterative manner. So, even if it feels more comfortable to start in a bottom-up manner (aggregation), in small scale and then scale up, that is a very treacherous way to try to achieve a way of working for the total product life cycle, especially regarding new product development. Instead, we always need to use an integrative top-down approach, originating from the purpose of the organization, that in turn gives us the context; product development, production, service, etc. By doing this, we can iteratively establish our way of working (including people structures), to be able to fulfil the organizational principles for our context. This means that every way of working is simply a systems design. This systems design for our way of working is needed for every context, complex as non-complex, but where the context exactly specifies what organizational principles that are activated, and therefore need to be fulfilled by the systems design.

Since traditional waterfall with projects, as well as trying to scale-up agile, are common solutions today for product development, but both have built-in root causes, SOSD will also show them as examples and how we can rescue organizations from them, with some pretty easy changes of the way of working.

Short summary
There can be two different outputs from SOSD: the first one is an awesome total way of working for a product development organization, including a proposed product development method that is suitable for the domain of the organization, where of course all the organizational principles are fulfilled from start. For the domain of big software systems, TDSD is the recommended product (system) development method, and in the blog post series about TDSD, also two different implementation plans (under construction) can be found; when transforming from waterfall or a scaled agile way of working. The other one proposes how to dissolve the organizational problems and their found root causes, or just some of the root causes. The latter output may be the preferred choice when there are not so many difficult root causes to solve, all root causes are not possible to eliminate, or maybe due to structural or political reasons, or when the context is not product (system) development. This means that the latter output covers any human complex adaptive system, operating in any context, given the root causes to the problems from SPPA as input.

A main topic is the need to understand the complexity of product development of an initiative, especially the need of reducing transdisciplinary complexity for novel products and the theory behind that. This gives tremendous information to the possible solutions of the total way of working for product development, where the whole product life cycle must be considered already from start. Other important topics are the people structures, the static line hierarchy and the dynamic virtual delivery structures. The portfolio needed for all product development in bigger organizations, the strategical and tactical management within it and above it, is also a topic that will be discussed, since it is an important part of the total way of working.

It is necessary to grip the concept of SOSD, that it is all about the total way of working, which originates from the common purpose of the organization, where the way of working also includes the people structures. With the common purpose as origin, it means that we need to plan the way of working top-down, and we need to involve the whole product life cycle from start. Starting with the purpose in a top-down approach has been used by us humans for probably hundreds of thousands of years or even more. This is an approach for us to reduce the complexity on what we are going to do, by being systematic and structured in an organization, or in any human complex adaptive system. This planning needs to be done top-down, and it will soon be clear why, so let us start to elaborate on the need of planning of the whole way of working first. Top-down is to be sure that we take care of the most complex parts in our way of working for product development, especially systems design of novel products, that will have heavily impact also on the systems design of our way of working. And any systems design, no matter if it is a product or a way of working, of course needs to be systemic, which is what the name of SOSD implies. Since experts can guide us with the output from SPPA and the solutions by SOSD, it is not transdisciplinary complexity that is reduced with our systems design of our way of working, i.e., it is not something completely novel. This is vital to understand, not only in order to understand the method TDSD – Test-Driven Systems Design, needed when developing big software systems, but also for the hardware product development domain (and generally for any domain regarding product development). For other kind of product development of big systems, like waterfall and Lean Product Development, they will also from start, as when using TDSD, need to follow the concept of SOSD, i.e., to be sure to fulfil the organizational principles top-down.

Making this required top-down systems design, means that we for example cannot start in the middle of the total way of working, and add the portfolio later. This is because the portfolio stands for planning and prioritization, which is on a strategic and tactical level, and then gives the operative responsibility for the initiatives to virtual structures in product development. But, in order to be able to be responsible for structure, planning and prioritization, the portfolio also has responsibility for the money used for each initiative. This means that the portfolio will get most of the organization’s money in a product development company, even in a hardware company, where the portfolio gets much more money than the research part of the organization.

In the same way the portfolio responsible cannot start directly with designing the portfolio, without understanding the systems design needed, the need to reduce the transdisciplinary complexity for novel products. Transdisciplinary complexity means that a lot of new knowledge need to be achieved at integration of the systems designed (novel) parts, which means that we neither know the parts, nor when we can be ready. Our new initiatives therefore need to be broken down and integrated, verified and validated, in order to iteratively reduce the transdisciplinary complexity for the product we are going to build. All this is heavily affecting the portfolio, that need to understand risks, failures and that the product from start, including the undefined parts, cannot be planned in time, which also means money consumption. Unfortunately, many scaling frameworks for agile do not consider this transdisciplinary complexity (or transdisciplinary complicatedness, or planning) for either the product or the organization. Without consideration, they instead just divide the work and organization into parts, a construction sometimes called value streams, no matter transdisciplinary complexity. This gives an enormous risk for sub-optimization of both the initiative and the organization. This sub-optimization is even worse than for the old (but non-common) projectized organization (see this blog post), which at least only sub-optimized on the organization, since the total scope of the project/product/initiative was not split. The believe that the whole can be divided into smaller parts as a first step, without consideration of the whole (ignore context), also leads to the erroneous thinking that making the top-levels, including the portfolio, can be done as the last step. But, since new product development is novel, and therefore always has transdisciplinary complexity that need to be reduced, this thinking is putting the transformation and the whole organization at an extremely big risk for failure. We need to have the complete picture for our products/systems life cycle from start, in order to get organizational levels and the portfolio right.

Every organization need to prioritize which work that should be done and also to plan the work, finance the work etc., which is derived from the common purpose of the organization. Planning and prioritization of initiatives are valid for all organizations and will be strictly formal with a portfolio for a big organization and more informal in a small organization, where the initiatives are few. So, the reason for discussing the portfolio is therefore two-fold; 1) we need to know the way of working for the product development life cycle first where new development is the most complex, until we can know the implementation of the portfolio, and 2) we need to understand and reduce the risk taking in many agile transformations at scale, often leaving the portfolio as the last step.

In the end, when putting all the bits and pieces together, it becomes clear that for big product (system) development in any domain, there is on a high level, only one track forward with already predetermined steps, as a result from SOSD. The steps on the track, are the result of following the organizational principles, and are presented in a picture that is finalizing this blog post.

Overview of SOSD
We start with the picture of the total, System Collaboration, which this total blog book is all about, system collaboration – SOSD.

As you can see above, SOSD is within the Dissolution of Problems part of System Collaboration, with a tight connection to Systemic Problem Picture Analysis – SPPA. The output from SOSD itself will be a total and awesome way of working for the organization, which includes also structures like the portfolio, the line hierarchy and the virtual (cross-functional) delivery structures, where the delivering teams are operative and can be found on different levels in the latter structure.

If the organization needs help from scratch or there are too many root causes to dissolve, SOSD will, depending on many different parameters, propose the way forward for the portfolio, the line hierarchy, and the virtual structures, as well as propose an appropriate way of working for the actual product development; waterfall with projects, Lean Product Development and TDSD – Test-Driven Systems Design (under construction), The reason for these proposals and no others, depends on that they neatly handle all our Organizational Principles for their respective domain where they are the most appropriate, which we will explain more about further below. For small scale software with high uncertainty (of the customer need), the proposal is Agile with MVPs. This means that all organizational principles cannot be properly fulfilled from start, which is a deliberate choice, but that is fixed through the later needed refactoring, or a completely new product. When an organization is transformed (redesigned) from scratch, the recommendation is still to do a SPPA, since there can be root causes from normal problems, or root causes that can be easily fixed, making the organization more efficient to some degree right away.

If the organizational root causes of the organization should be dissolved instead, a proposal for how to fix them will be presented. As can be seen in the picture, all Organizational Principles valid for the context of Complex, Complicated or Clear, which in turn are generated from the purpose, need to be fulfilled, even though all of them are not “activated” in a Complicated or Clear context. Moreover, other parameters of the purpose needed for our system as; security level, size of the system, size of the organization, length of the life cycle for the system, etc. are also very important input in order to achieve a flourishing organization. Depending on these different parameters, other necessary qualities of the system need to be taken into the equation, for example requirements traceability if our system starts to get big, which also will be further discussed below.

This also leads to that it is difference between qualities and qualities, as well as qualities and non-functional requirements. All put together will give some different ways of working, as already presented, which actually is not so many as one can expect, even if every one of them can have some flavour (SOSD is then non-descriptive) depending on the organization. We can then see that the solution for the top level of big systems is domain independent as well. We will also be able to understand that talking about emergent architecture and design, i.e., bottom-up software development, is easier said than done when it comes to big software systems, or many teams in a big organization that is working within the same system. Worth mention is also that for hardware systems, emergent architecture/design is not possible, so a proper systems design is needed, no matter the size of the system. The line between small and big systems depends on many parameters. But, a few teams and a total of up to 50 persons, is where an organization many times is said to go from small to bigger, needing a formal setup with a line hierarchy and virtual delivery structures, a proper systems design and documented information. For big systems, built from scratch, it is seldom the uncertainty of WHAT the customer needs that is the hard part. Rather it is reducing the transdisciplinary complexity/complicatedness, i.e., HOW to make the big product, which is the case for many service organizations, like banks, governments, insurance companies, finance institutes, or retail. It is rather how to iteratively reduce the transdisciplinary complexity/complicatedness of especially the backend part of the big system developed, all in order to avoid risk taking, with a resulting proper systems design. This also means that most of the requirements for big systems, both the functional and non-functional requirements, normally can be acquired early on, meaning that we do not even need to take the risk with emergent architecture and emergent design, which easily leads to sub-optimization. With that said, we can understand that systems design is always a vital part when doing big systems. But, before we deep-dive into the world of systems design, we need to go through some theory of how to dissolve organizational problems, showing why sub-optimizations are never the way forward.

Next blog post in this series will cover the necessary integration, i.e., to have a top-down integrative approach, which is always needed when making a new way of working.

C u soon.

Leave a Reply