From all the deductions made so far, we can also deduce that any way of working for product development needs to be a complete top-down process to be able to follow the needed science in the complex context. This means that it never can be a framework, according to today´s definition, since cherry-picking methods and sub-methods, built on a provided a set of rules, guidelines and best practices, never automatically will fulfil the needed science. Here below, the reasoning and deductions are presented; context is always king, we need to understand our organizational principles and the need of organizational top-down synthesis, where the latter was stated in earlier deductions.
The first reason for that frameworks are not possible for the product development of big systems, is that one-size-fits-all solutions for ways of working are not possible. Context is always deciding what solution for a way of working that we can have, where the deductions made in System Collaboration shows that top-down synthesis always are needed when making the methods for product development of big products and systems. Some frameworks claims that exhaustive information about different Best Practice is the best. But, the more information the better, is never a good concept for any way of working, since excessive information is hard to navigate when looking for the solutions we need. This is especially valid if the right solution is not to be found within the framework yet, which we can never know, as well as product development can take years, which means that it will be a very expensive learning if the way of working cannot be validated until then. The need of top-down synthesis also means, that even if the solution can be found within the framework, we can never know what methods and sub-methods to pick in order to be able to correctly develop our product or system. Also, the constant updates on the home pages with more and more information added, makes us want to raise the question if we ever, and not only yet, can find the (Best Practice) information we need for our specific situation, context and needed solution. So, the really important consideration is that it is never stated what parts in the framework that will become a unified and well-functioning way of working when aggregating the parts for our context and domain. This in turn induces that neither the product will. We can conclude that more, is here definitively (worth)less.
The second reason, which is the self-evident argument, is that we always need to follow the science, not only our organizational principles, but also the deductions, for example top-down synthesis, made in System Collaboration, otherwise we can never be sure that we will fulfil all the organizational principles at the same time. The reason for this is that it exists very few different solutions, meaning that when cherry-picking processes, sub-methods, tools and artifacts to become a satisfactory solution, we still need to understand and follow all our organizational principles, i.e., we most probably need to change our thought patterns. Without understanding the existence of our organizational principles, will of course lead to an extremely high risk of the solutions to be mostly mal-functioning and expensive solutions, with high risk of a non-working product or system.
We can therefore deduce that the need of an organizational systems design when making any way of working in order to fulfil the organizational principles, is always a necessity, since we otherwise never can be sure that we fulfil the needed science. And this organizational systems design always has to be done top-down, in a top-down synthesis approach, which was stated in the series of articles about System Collaboration Deductions. These deductions are the foundation not only for the method TDSD, but any product developing method, also for hardware product development methods like waterfall (silos with projects) and Lean Product Development, that already have similar foundation with line hierarchy, virtual delivery structures, systems design and a portfolio.
The conclusion of all this, means that we can never make our own framework for product development (and it will be very difficult in non-complex contexts too), where more details can be found in the series System Collaboration Deductions. Just having a particular set of rules, ideas, beliefs and “principles”, home-made or collected, and to that add all famous small methods available and try to aggregate everything to a united and unified whole for a way of working, no matter combination, and trying to scale it as well, is therefore wrong per se. The reason is that we need to state validity (the need of fulfilling the organizational principles) for any combination (organizational systems design of our way of working) of the aggregation of all these small methods, and we could see in the deductions of System Collaboration, that there was really only one overviewing solution that follows the organizational principles for product development. But unfortunately, this is obviously not the reality (since we already have frameworks), and the frameworks instead let their users cherry-pick small methods and other needs from a smorgasbord, what the users with the help from framework coaches, think is valid for their way of working, to try to achieve scale. And if the organization fails, the answer from framework coaches will always be that they picked the wrong methods, or implemented them wrong, or not implemented everything in the framework, or with the comment “it will take 5-10 years to get it right”, leaving the organization with the failure. This cherry-picking approach is invalid also for any systems design of a product (cherry-picking (new) components), and not only for a way of working (cherry-picking sub-methods/people/parts/value streams (popular now)/dimensions/or any other division of the organization). Instead, we need well-informed hypotheses, that during some iterations are integrated, verified and validated, to understand the validity of the way of working, i.e., that we have fulfilled the organizational principles. And since we have both our organizational principles to validate against, as well as tremendous knowledge of success and failure of existing methods, it is not as tricky as we think to achieve a flourishing way of working. It is instead straightforward.