Here is a short and very compromised list of all the deductions made in System Collaboration.
Any organization can be defined as “People that interact to solve activities with interdependencies for a particular purpose.”
From that definition we can deduce that we need to follow the science for people and activities, for any way of working our organization has, where a way of working always includes people structure(s). The existing science for people and activities is in System Collaboration named as our Organizational Principles.
From the organizational purpose we get the context, that with reference to the Cynefin Framework (TM), can be of three different types; Clear, Complicated and Complex. In a Clear context we have all the knowledge we need, in a Complicated context we have some knowledge so we can be guided by our experts, and in a Complex context we do not have the knowledge we need. This indirectly means that the more complex a context is, the more of our Organizational Principles are “activated”, and in a Complex context, all of them are “activated”. Production is normally referred to as a clear context, and product development as a Complex and Complicated context, depending on the novelty of the product; the more novel, the more complex. Remember that we always need to take the full life-cycle of our product in consideration from start, when we are making or transforming to a new way of working, since we as can be seen further down. This because we cannot just aggregate new parts to our way of working later, which in turn means that frameworks for product development are wrong per se.
From our organizational principles we find that we in all context need to have enough order, which when everything is big, means that we need structures to get that order, and we always need to do it top-down, starting with from the organizational purpose. This is valid for a number of things like; our people (the line hierarchy is therefore a necessity), the activities (WHAT) they will do, the dependencies and interdependencies between the activities, our product, HOW the work need to be performed (our way of working), which means that we need planning, an ancient common sense. The structures also need to be visualized in order for us humans not only to understand complicated things, but also to be able to explain them to other people, as well as getting a good overview of the wholeness and its parts.
We can now deduce that if our way of working is not fulfilling our organizational principles, we will get organizational problems (symptoms) in our organization, making it hard or impossible to fulfil the organizational purpose. These organizational problems are therefore “built-in” to our way of working, that over time will generate a gigantic and nasty network of interconnected and intertwined symptoms, leading down to the root causes, i.e., the non-fulfilled organizational principles. The deductions so far are the foundation for SPPA, that is a context independent method for finding all the problems within an organization, that can be used in all organizations, i.e., actually in all constellations of people.
Since symptoms always are impossible to solve, this means that the solution to our organizational problems, never are about changing people’s behaviour, their mindset, the culture, etc., which is only symptoms of our way of working. Instead the only way to eliminate the organizational problems, is by redesigning our way of working (by an organizational top-down synthesis), which Dr. Russell Ackoff stated as “dissolve a problem”. Designing a way of working in any context, means that we as for our products, need to do reduce the transdisciplinary complicatedness (no transdisciplinary complexity) by doing a systems design, in order to be able to fulfil all our organizational principles at the same time, as well as time/development cost, quality and product cost (non-functional requirements on the way of working).
Further deductions, and with help from organizational experience since the last century, also give that to be able to fulfil all our organizational principles in a way of working for the complex and complicated context of product development we, apart from the existing line hierarchy, always need to include a systems design, virtual delivery structures and a portfolio, since the solution space is reduced radically, where a picture of these prerequisites is included in the same article. This is valid for any product development method, no matter domain, which in turn means that the success of hardware product development with waterfall and Lean Product Development, directly means that they already are fulfilling our organizational principles. From the deductions so far, we now have our method SOSD for eliminating organizational problems within an organization, that gives suggestion of solutions to root causes (non-fulfilled organizational principles). If there for some reason, normally political, are root causes that is not allowed to be solved, SOSD can also give proposals to sub-optimising solutions (not recommended!).
From all the deductions above, we now have all the knowledge needed in order to finally be able to implement the product development method TDSD. It has the focus on software product development, since the existing commercial methods and frameworks, severely is missing the fulfilment of very important organizational principles (which is easily found to be the case using our method SPPA). With TDSD we add the last piece needed, the domain the organization is operating in and its people’s domain knowledge. This means that TDSD is not more prescriptive than our organizational principles and the deductions above, since the ones that know their organization the best, are the people within the organization itself. When implementing the last piece, all the organizational principles in the context of course need to be followed, but that is normally not complicated, and straightforward for the organization, referring to the domain and domain knowledge of their people.