All organizations want a way of working with high performance, which indirectly means to fulfil non-functional requirements (qualities) like; cheap, fast, qualitative and that is delivering correct and bug-free products, visualized in the picture below. Another way to put it is that an organization wants the way of working to be efficient (both resource and flow efficiency, which are strongly connected), effective and qualitative. These non-functional requirements are an acontextual part of the organizational purpose, which means that they are valid for any context; production, service or product development, etc. They go without saying, and since it is all about making happy customers, they are therefore seldom mentioned in an organization’s vision, and only sometimes in the mission or purpose. These performance requirements are (in run-time) the visible ”as-is” non-functional requirements on our way of working. If our way of working is mal-functioning, top management will see them on their table as the highest-level symptoms. Our organization is then simply lacking performance. Inside the organization other symptoms will be seen much earlier, and since all symptoms are connected, down to the root cause(s), it means that we can be proactive when we see the first early symptoms, long time before the effect of them will reach the top management. We also have other non-functional requirements, that neither are stated in organizational vision, mission or purpose statements, like scalability and cybersecurity, desirable and mandatory non-functional requirements.
The science and the System Collaboration Deductions gives per se that the desirable and mandatory non-functional requirements on our way of working, e.g., scalability, stability and flexibility will be fulfilled, and that cybersecurity with easy measures, will be fulfilled. We can understand that the combination of the line hierarchy and the virtual structures are suitable for covering different type of scalability, stability and flexibility. First, we have the line hierarchy with its stability, accountable for strategic and tactical work that are slower and having longer feedback loops, but that still having the possibility to scale, in order to increase or decrease in size, without difficulties. Then we have the flexible virtual structures with short feedback loops, that have full flexibility and easily can be scaled to any size, which is a perfect match for doing the operational work, as well as support parts of the tactical work.”
This means that we due to the Organizational Principles and the System Collaboration Deductions, that we need to follow for product development, in order to fulfil our organizational principles, always will get a way of working with performance, without wishing for it. This is also valid for desirable and mandatory qualities, like flexibility and scalability mentioned above, needed for different sizes of the organization or initiative, without the need of wishing for them as well. This is 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, and have never been, 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. Here is a picture showing the requirements for a product development way of working vs the requirements on the product to realize; requirements on the WoW.
Other non-functional requirements on our way of working that are desirable, are for example; flexibility (as well as stability 🙂 ), capacity, maintainability, modifiability, to mention a few. If we fail them, we will be aware of that due to early symptoms from a mal-functioning way of working. These symptoms will once again finally end up as these highest-level lack-of-performance symptoms, that top management finally will notice, if we not take early measures. As we understand, this indirectly means that when we have a mal-functioning way of working, we can only know that we are not fulfilling our organizational principles, which in turn is giving us bad performance. This also means that if our way of working is successful in one context, does not mean that it will be successful in another context, or if we for example scale-up in the same context. To copy a way of working, without understanding if we will be able to fulfil the organizational principles in our context, is just high risk for a painful failure. But, due to that the organizational principles and the System Collaboration Deductions are followed, these non-functional requirements will, or with easy measures will, be fulfilled.
Until now, it has always been easy to claim that a way of working, apart from fulfilling the performance non-functional requirements, also fulfils desirable non-functional requirements. Many times, also as a means for the way of working or framework to be chosen, for example due to its scalability properties, but with the System Collaboration Deductions, we can now judge that. The System Collaboration Deductions originates from the organizational principles, and show us step by step how the implementation of a way of working for product development on a high-level, always must look like, in order be successful with the necessary simultaneous fulfilment of all organizational principles. And this does not regard only the performance non-functional requirements, but also the desirable non-functional requirements on our way of working. This is due to the fact that at every deductive step, there will be more and more of these desirable non-functional requirements fulfilled, or with easily added measures fulfilled, as well. In this way we can easily judge if a way of working fulfils scalability as claimed, or any other non-functional requirement.
Regulatory compliance is most of the times strongly connected to mandatory non-functional requirements on many different businesses. They can for example require the way of working to include cybersecurity measures, that in turn requires traceability. Also here, System Collaboration Deductions show that the needed prerequisites for any implementation of regulatory compliance is secured as well, giving the needed order, structure and traceability, often required by regulations. This is especially thanks to the necessary top-down approach, which is a must to be able to follow the organizational principles for any way of working in product development. It can also be added that System Collaboration as a fundament, secures that many regulatory management systems, that is required due to regulatory non-functional requirements on the product, easily will be integrated in the organization’s total management system, like management systems for; quality, information security, cyber security, software update, safety and sustainability.