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).
Further deductions, and with help from organizational experience since the last century, it leads us to that 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 implement 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.
