Starting with the organizational purpose is a must
Normally we consider planning to be something we do for an initiative, so we at least get a good enough understanding of time, cost, people needed, quality, etc. This planning and later work to fulfil the plan, is relying on that the way of working is appropriate and well-functioning. But, what if our way of working, or the method or framework for product development we are transforming to, have built-in deficiencies due to that it has not been planned good enough itself?
An apt and informational enough organizational definition is the following: "People that interact to solve activities with interdependencies for a common purpose.", which gives us an understanding of the focus on people and activities in our organizational principles. From that definition, we cannot only draw the conclusion that everything starts with the organizational purpose, it also gives us that we need to do it top-down, because the organizational purpose gives the context, and it is therefore really where all starts. When we have the purpose, which is our first WHAT (to do), on the highest level, we will understand both the context (like production or product development) and domain (like hardware or software) we will operate in. The context gives us the highest complexity on the activities that need to be solved, that in turn together with the domain, gives us what competence, skills and experience our people need to have. This means that the first planning we need to do is to secure that our way of working, our HOW, can fulfil the purpose (WHAT) and make our organization flourish.
It is important to understand that we need to take the whole life cycle of our WHAT to do, in consideration when planning our way of working, which is stated in SOSD by the need of top-down synthesis also for any way of working. This means that we need to be vigilant when we are transforming our way of working, our HOW, to a new method or framework for example software development. Because, it is actually a very bad idea to start the transformation with teams doing maintenance or easy feature enhancements in an existing and already systems designed architecture. Why? Since that really is the easy part of the life cycle of any product development, hardware or software. If we still try, this leads to an extremely high risk that our way of working, our HOW, is not fulfilling our organizational purpose, our WHAT to do, since any product development life cycle includes also completely new products or even new platforms.
SOSD is only prescriptive enough in order to fulfil our organizational principles for product development, i.e., the domain independent parts of the purpose. This needed prescription for product development (in any domain), induce the need of a line hierarchy, systems design, virtual delivery structures and portfolio, in the way of working. The systems design in turn, induces the need of "scaling down" any initiative iteratively. This further leads to the concept of test-driven systems design, especially valid for product development of hardware and software. Test-driven systems design is used in the method TDSD for software, taking the whole life cycle of software into account. TDSD for software adds the domain specific parts of the HOW, the domain and the organization's domain knowledge, still fulfilling the organizational principles and deductions from SOSD, all in order to make TDSD for software a complete method.
More information about the need of start the planning of the way of working already from the organizational purpose, the WHY, can be found in here.