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 common 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, 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 into consideration from start, when we are making or transforming to a new way of working, 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, no matter context. This is valid for a number of things like; our people (which deduces that the line hierarchy therefore is 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. When having organizational problems, they are “built-in” to our way of working, and will over time 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 are only symptoms, the consequences 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 complexity, by doing a systems design, where all our organizational principles are fulfilled simultaneously.
Further deductions 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 already stated line hierarchy; always need to include a systems design, virtual delivery structures and a portfolio, which means that the solution space is reduced radically, where a picture of these prerequisites is included in the same article. This is valid to follow for any product development method, no matter domain, as well as already successful ways of working like hardware product development with waterfall and Lean Product Development. This directly means that these ways of working already fulfils our organizational principles, for the context where there are successful (of course), and also means that we indirectly already have experience in the usage and validity of our organizational principles. From the deductions made 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 solutions that will sub-optimize to some degree (not recommended!).
It is important to point out that there also are qualities, or non-functional requirements, on any system, including our way of working, like the ones for “performance”; efficient (time/development cost), effective (product with quality) and quality (on the way of working; healthy people doing few faults). These are normally not stated in organizational vision, mission or purpose statements, since they go without saying, every organization need this. But, due to the deductions that we need to follow for product development, in order to fulfil our organizational principles, this will give us a way of working with performance, as well as the flexibility and scalability needed for different sizes of the organization or initiative, without the need of wishing for performance. This is also straightforward, since we humans have our cognitive limitations in our DNA, which means that bad organizational performance never has “slow human” as a root cause, i.e., it is always due to a mal-functioning system not fulfilling the organizational principles. So, wishing for performance is never an option. Instead, it is actually regarding the ability of flexibility, that we to a high degree can increase the speed on the delivery of our products, by an appropriate scaling-up with more teams. See also this article for detailed information about also more non-functional requirements on our way of working.
From all the deductions above, we now have all the knowledge needed in order to also implement complete methods that fulfil all organizational principles and all the made deductions in System Collaboration, for example the product development method TDSD. It has the focus on software product development, since the existing commercial methods and frameworks, severely are missing the fulfilment of very important organizational principles (which is easily shown when making a problem picture analysis of an organization’s problems, with our method SPPA). With TDSD we add the last piece needed, the domain the organization is operating in and its people’s domain knowledge. TDSD is neither more prescriptive than necessary, making it easy for the ones that know the organization the best, the people within the organization itself, to make the TDSD implementation. When implementing this last piece of our way of working, all the organizational principles in the context of course need to be followed as well. But that is normally straightforward for the organization, referring to the domain and domain knowledge of their people.