System Collaboration Deductions™
A way of working in any organization, no matter context, needs to be efficient, effective and qualitative, qualities that normally goes without saying, which therefore makes them seldomly stated in an organization's purpose. These acontextual qualities, or non-functional requirements, on our way of working, are strongly connected to the organizational principles. This means that a failure to achieve them, is often where top management indirectly will be noticed that we are not fulfilling the organizational principles for the context the organization is operating in.
From the organizational purpose we get the context, that with reference to the Cynefin™ Framework by Dave Snowden, can be of three different types; Clear, Complicated and Complex. From left to right we have increased complexity, with more and more "activated" Organizational Principles, where visualized structure and order for us humans, when things get big, is of utterly importance. To achieve a flourishing organization, we simply need to follow the organizational principles "activated" in our context, where non-fulfilled organizational principles will be our only possible organizational root causes.
This means that if we not fulfil our organizational principles, we can deduce that we will get organizational problems (symptoms) in our organization, making it unnecessarily hard, or impossible to fulfil the organizational purpose. Over time these organizational problems will increase and get worse, an increasing network of problems, but which we can detangle with our method SPPA, valid for any organization in any context.
Since symptoms always are impossible to solve, this means that the only way to eliminate the organizational problems, is by redesigning our way of working (by an organizational top-down synthesis).
Here is where System Collaboration Deductions comes into the picture. By starting with the context independent Organizational Principles (we do not even need to know the organizational purpose), continuing with the context dependent Organizational Principles (we only need to know the context from the organizational purpose), and finally taking the domain dependent Organizational Principles (we need to know the full organizational purpose) into account, we can deduce how our way of working for product and software development must look like, in order to fulfil all our Organizational Principles.
This leads us to a way of working "architecture" where we need a line hierarchy in all contexts. For the context of product development in any domain, the solution space is further decreased, with the conclusion that we always need to include a systems design (transdisciplinary work), virtual delivery structures and a portfolio. All these deductions are the foundation of our problems-eliminating method SOSD. Throughout the deductions, we can also deduce that many desired and mandatory non-functional requirements on our way of working also will be fulfilled.
From all the deductions above, we now have all the knowledge needed in order to finally be able to enter the domain, where we fulfil the last of our Organizational Principles. After that we have the total way of working "architecture" needed to be able to implement TDSD, where the focus (right now) is on software, the software product development method TDSD. With TDSD we add the last piece needed, the domain the organization is operating in and its people's domain knowledge. When implementing the last piece, all the organizational principles in the context of course need to be followed, but that is normally not difficult, and mostly straightforward for the organization, referring to the domain and domain knowledge of their people.
For a more detailed summarizing list of the deductions, please see here, and for complete information and examples look here, which is the introduction to System Collaboration deductions.