Welcome to the series of articles for the method SOSD – Systemic Organizational Systems Design, which is a part of the larger concept Dissolve the Organizational Problems. SOSD is a method that eliminates (dissolves) organizational problems in any way of working.
Since SOSD solves any organizational root causes found by SPPA – Systemic Problem Picture Analysis, SOSD is generally (like SPPA) a context independent method for dissolving the problems to make a flourishing way of working in any context; production, service, retail, product development, etc., even though SOSD has the focus on the complex context of product development.
SOSD consists of many articles with different content, covering all the important parts of the method. It deep-dives into the overall thinking, as well as the parts, where the needed solution to eliminate the problems, always depends on context, as well as taking care of the wholeness. In this series of articles, we will cover the method itself, with has its foundation on our Organizational Principles and the deductions in System Collaboration, as well as many examples on how to eliminate (dissolve) the organizational problems.
An important part of SOSD is how to eliminate problems within existing methods and frameworks, like waterfall and agile at scale, which both have built-in root causes, that in turn generates severe problems. But it should be pointed out, that sometimes it will be much easier to transform a bad implementation of agile at scale directly to TDSD for software, instead of taking the risk of trying to make major changes to the existing way of working, without knowing if the whole will work.
SOSD focus is on achieving flourishing way of workings, especially for product development, in the domains of software (pin-pointed), hardware or combinations of them both. This means that the focus is on dissolving the problems from a Complex and Complicated context, with reference to the Cynefin™ Framework by Dave Snowden. SOSD is, as stated above, to be used for making domain independent solutions for the root causes of deficiencies in the current product development way of working to be enhanced. Remember that our 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 software, hardware, or their combinations, since we still need to follow the organizational principles for the complex and complicated contexts.
It is important to go through WHY we need to dissolve the root causes in a complex or complicated context the way we do in SOSD, since this leads to that there will be a required and therefore prescriptive order of the high-level HOW, thoroughly described in the deductions of System Collaboration. Shortly, this depends on the need of starting from the organizational common purpose to get the context, leading to the need of having a top-down synthesis approach for our way of working, all to be able to fulfil the organizational principles in the end.
There can be two different outputs from SOSD:
The first one is an awesome total way of working (method) for a product development organization, 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 for software is the recommended product (system) development method, and in the article series about TDSD, two different implementation plans can be found; when transforming from waterfall or a scaled agile way of working, has also been added. The other output from SOSD proposes how to dissolve the organizational problems, by solving their found root causes, or just some of the root causes.
The second output may be the preferred choice when there are not so many difficult root causes to solve, or all root causes are not possible to eliminate, or maybe due to structural or political reasons, or when the context is clear and not product (system) development. This means that the latter output covers any human complex adaptive system, operating in any context (and therefore also domain), given the root causes to the problems from SPPA as input.
A main topic, which is extremely important, is the need to understand the complexity of product development of a new initiative, especially the need of reducing transdisciplinary complexity and complicatedness for novel products, which also includes the theory behind. This understanding gives tremendous information to the possible solutions of the total way of working for product development, for example that the whole product life cycle must be considered already from start. Other important topics that this leads to are the people structures, the static line hierarchy and the dynamic virtual delivery structures are always necessary. 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 a necessary part of the total way of working as well. All this are very well described in the deductions of System Collaboration.
Overview of SOSD
Here is a picture of the total System Collaboration, where SOSD has been high-lighted, system collaboration – SOSD.
As you can see above, SOSD is within the Dissolve the Organizational Problems part of System Collaboration, with a tight connection to SPPA – Systemic Problem Picture Analysis. The output from SOSD itself will, as stated earlier, be solved root causes, leading to a total and awesome way of working for the organization, or pointing out that a transformation to another way of working is needed.
If the organization needs help from scratch or there are too many root causes to dissolve, SOSD will therefore, 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 built-in organizational root causes of the way of working 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,) as well as all contextual deductions concluded in System Collaboration, need to be fulfilled.
Next article in this series will give some examples of common root causes when using the method waterfall and agile at scale.