Example: practices of the life cycle of system engineering ​

The standard of system engineering life cycle practices ISO/IEC/IEEE 15288:2015 is an example of documenting practice not in the form of a body of knowledge. It establishes the most general descriptions of life cycle practices for systems created by humans during systems engineering projects ("system life cycle" just reflects that it is a standard of the past generation of engineering).

It defines a necessary set of practices for system engineering of creating and developing (in the standard - "life cycle") some system, related discipline/theory (including terminology for its expression). These practices can be applied at any level of system breakdown - recursive use of the standard is assumed. These practices are defined for the entire creation time (development may be, but is not explicitly provided for) and existence of the created system. All project roles (stakeholders, both internal and external) are involved in the execution of these practices, with the main goal being to satisfy the customer.

The standard divides all practices into 4 groups, some of them are "technical" and relate to transformations of the target system, some are "managerial" and relate to organizational units/creators engaged in projects where practices from this standard are carried out, some relate to the creators of creators (practices of creating an organization for the system creation project initiated by the organization starting that project), and some relate to the conclusion and execution of agreements on procurement and supply. Here they are:

The standard is designed to check: if you perform all these practices, then you are engaged in system engineering. If you do not - then it is just engineering, not system. However, it should be cautioned that this standard, like all possible BoKs, describes not the minimum or optimum use of various practices to achieve the result of some specific activity in a particular project, but rather the possible maximum in an abstract project. These standards are especially popular among representatives of governmental (and particularly military) circles, because the approach of "what else could be done" is excellent for situations when parties are interested in raising the price of a project for creating a successful system, and the influence of project roles interested in reducing costs is minimal. Each subsequent recommendation for the application of certain practices will be costly, but whether it will provide a significant effect in terms of each spent ruble or dollar is not guaranteed.

Therefore, it is necessary to use such standards and public documents only as reference material, not as a guide to action: take from these documents only the minimum that suits the scale of your project. And considering that this is a standard of the previous generation of system engineering (before the transition to "continuous everything"), it is not possible to rely on it at all. Although in governmental and especially military organizations, this standard just describes the method of creating (and even very limited development of) a system, no matter how ineffective and inefficient it may be.

Today, there is a trend of anti-perfectionism (movements like agile, lean, lightweight methodologies, ideas such as minimal viable product - google all these terms if they are not familiar to you, they are part of the modern knowledge base of managers, company founders, investors): you need to do a minimum of work, not strive for "perfection", not waste unnecessary resources. This countercultural trend fights against the culture of perfectionism, in which you must perform even unnecessary work and complete it, because "that's the way it is," and "that's the way it's done." But yesterday's counterculture of anti-perfectionism has become today's culture, it leaves perfectionism only in the implementation of a unique business proposition and increasing the development speed. This is all about applying the principle of minimal action in physics to engineering in general and to management (organizational engineering) in particular.

If it comes to standards that describe certain interfaces, implement them fully, but check which generation of the standard you are implementing (you may need to implement several generations of the standard, several interface options at once). If it concerns bodies of knowledge, standards for implementing practices, then take from them only the minimum for implementation! To do this, understand the subject area well to take the really important minimum, leaving out all the unimportant stuff outside implementation.

As with any other classification, alternative options can be proposed for the technical practices of system engineering from the standard. For example, our course "Systems Engineering" at the School of Systems Management uses a shorter list of practices (and the corresponding roles) that have different names (these are practices of visioning, development, architectural activities, production platform engineering), these same practices in management and roles performing these practices are called differently (business practices, organizing, org architecture, administration). So, the standard of system engineering practices seems to exist, but it is outdated (and it's not surprising: the development of international standards and voting of countries in ISO take years, and practices change before standards and BoK, which should provide knowledge about practices, can change. Therefore, the freshest practices should be sought in articles, and not in journals - the delay there will be a year, but in preprints, and the most modern will be published in blog posts).

But it is necessary to know about standards and public documents (like BoK) with descriptions of practices/processes/methods. Many people who you will have to talk to are guided by them - ignorance of them can be considered professional illiteracy. Therefore, you can show your knowledge of them, but it is absolutely not necessary to follow them, you do not have to implement old working methods from these standards when you can implement modern (state-of-the-art, SoTA) methods right away. On the other hand, there is always a risk of adopting some non-working method as the basis of your work - but it will be even worse to take a standard or a public document with a method that is knowingly not working. The "agonies of choice in conditions of uncertainty" will be discussed in more detail in the course of systems management, in the practice of strategizing.