Practices ​

Modular/product/constructive representation of the life cycle work "as in project management" was very popular with managers, but for engineers it turned out to be insufficient, as is usually the case with a systemic approach: the area of interest of engineers differed from the area of interest of managers involved in operational management. For designing, "manufacturing," and "commissioning" the sequence of works (that is, designing, manufacturing, commissioning by creators/organizational units performing these design, manufacturing, commissioning works) it was necessary to move towards a functional/role-based representation, to discuss the types of work from the standpoint of their role assignments/functions, and to consider the organizational units of the creators in their organizational roles. Works as behavior/"service resource instances"/"constructive objects"/organizational units must perform the functions/practices of functional/role objects/organizational roles in the creators, convenient for discussing "how creation systems work, so that the target system changes its state during the life cycle and becomes successful." What exactly Vasya Pupkin is doing, not understanding his current role - is always unclear (is he playing the role of Othello? Prince Hamlet? Ophelia with his "work"? It is clear that Vasya Pupkin is busy, working. But what and why is he doing?!). What a particular work does for a project manager (who is supposed to design it) is unclear, one needs to look at the content of the work/way of performing the work/method/practice/"functional embodiment of the work" as set by the applied engineer.

The consideration of the behavior of creation systems as functions of organizational roles/project roles/activity roles in the life cycle did not happen immediately: the resources in the creation systems were constructive objects, and as systems with their leading understanding as functional objects were not perceived! Creation systems were not considered as systems, there was no systemic view! "Organizational roles" at the same time are the same functional/role objects that are played out by organizational units. "Org" just emphasizes that it is about the organization, that is, there is an agreement on who can ask the role performer to perform the tasks of that role. Project role - here it is emphasized that it is about the project. Activity role - it is about multiple projects and multiple organizations. But in principle, all this is about the same thing: it is about functional/role objects that perform substantive actions in the organizational system as a creator system (including all creation chains, if necessary). The same organizational system has been referred to as the "life cycle management system of the target system", and now it is called the "creation and development system of the target system", i.e., the creator system or simply the creator. Organizational roles, project roles, activity roles - these are all roles in the creator.

The transition to diagrams such as principal/functional diagrams for creation systems occurred gradually (and remember that all these diagrams have reflected not the creation and subsequent evolution of the system, but a single passage through the "non-life cycle" - these are "segments", not "loops/cycles"). After the classical "sausages" for the life cycle stages, initially a multitude of hybrid diagrams appeared, trying to reflect both the constructive/logistical and functional/purposes embodiment forms of the life cycle as the behavior of creation systems. And this is no coincidence: key/conceptual decisions on the structuring of the life cycle - these are the decisions on which organizational roles will be performed by which organizational units, or in another formulation - which works will be performed by certain practices/types of work/activities. Making these decisions on the life cycle concept (analogous to the system concept) and organizing the implementation of these decisions have come to be called life cycle management (life cycle management, cf. work management/work management. Work management does not have conceptual decisions on the life cycle: it does not address the content and technology of work, i.e., practices, but only the duration of work and the required resources regardless of the "way of work execution"/ "way of working"/method).

One of the most famous hybrid life cycle management and work management diagrams is the hump diagram from the Rational Unified Process methodology (RUP): (see image at: https://en.wikipedia.org/wiki/Rational_Unified_Process)

In this diagram from 1996, it can already be seen that in addition to the unnamed "iterations" as groups of works, traditionally divided into "stages" in time, a new type of object appeared, practice (practice, activity, type/kin of work, labor, engineering as a change of something in the world in some explicit manner), named after its theoretical engineering or management discipline (discipline, theory).

"Practice" is the culturally conditioned functional/role behavior of creators. The works of organizational units perform the role of various practices culturally conditioned by organizational roles, and the life cycle consists precisely of works by these methods/practices, named after their disciplines (and sometimes the word "discipline" includes both the actual "theory" and the use of materials and tools - thus referring to both the method/activity/engineering itself, and not just its theoretical part).

Roles and practices, objects and their behavior are inseparable, always together. A system architect (role) carries out the practice of system architecture (role behavior). An aviation company (role) carries out the practice of aircraft construction (role behavior). There is no need to come up with roles and practices "from scratch" every time, they should be taken from culture, they are culturally conditioned, defined by the successfully replicating (and evolving) memes of these practices. If in the past a dating practice included the "clock" template (a good reference point plus the opportunity to check the time), today mobile communication has led to the fact that the template has not survived - the date is set in an approximately agreed place at a more or less approximate time, and the "exact meeting" is already adjusted considering the available technology, the dating practice has changed, evolved. Therefore, cultural conditioning:

• Includes the common awareness of the practice: if someone does something in a certain way, they probably did not come up with their method by themselves. "Took from the air" - they used the memes they already had. Maybe there are better memes elsewhere, more modern ones. But "invented the practice" is an extremely rare situation.
• Is tied to time. For example, the Requirements discipline in the 1996 diagram was very modern and culturally conditioned. But now it is considered an anachronism, a greeting from the past.

How to check cultural conditioning? Usually, there are textbooks on culturally conditioned practices. And if it's an act of individual inventiveness/"I came up with it myself!" - then there is no textbook available - and you have to make a decision: there is no textbook because it's a frontier area, and textbooks have not been written yet, or there is no textbook because this crooked newly concocted work method cannot be reflected in a textbook in any case, or we simply do not know about the textbook (but it actually existed, and we learned how to perform the practice from someone who studied from that textbook. But we don’t even know that he studied from the textbook).

Methodology does not teach what to do in this case, but it requires maintaining an interest in the practices of work and being interested in their cultural conditioning.

The works of different practices were distributed over the life cycle at its initial (1.0) representation as "sequences of works." In RUP, these are the works of organizational modeling/business modeling practices (remember the translation of business as "organizational"), requirements engineering (already outdated since the popularity of RUP), analysis and design (analysis as a separate sub-practice is not considered, it is included in design), development (the boundaries of this practice are now defined differently), testing (today it is "engineering justifications"/quality assurance), deployment (but delivering is not there as "introduction to use"), configuration and change control, project management, working with environmental factors. And it's not in loops, although they are segmented into "portions of works for all practices together" as "iterations" - but it's just "gradual achievement of the end result," and not about creation and then development, development, development, i.e., not about a continuous evolution without reaching a pre-determined goal. No, it is assumed that "requirements were defined, handled, requirements met - all life cycle projects are completed, even if there were several projects, all development as a continuation of work on systems of the same class is beyond the life cycle."

These works are divided into stages, and then into more and more detailed works in the classic work breakdown structure (WBS) from project management. At the same time, practices (named on the "hump diagram" according to their disciplines) reflect the division of labor.

The division of labor (of practices, activities, engineering) into qualitatively different types should not be confused with the division of work, which is quantitative. The division of work discusses how much work should be distributed among resources (for example, if a homogeneous job needs to be done twice as fast, then twice as many people should be put on it, or a machine with higher productivity should be used), whereas the division of labor discusses how to break a practice for a single performer with a single role into sub-practices, where different agents under the role can perform different sub-practices as sub-roles of the main common role. Further, the performer of the sub-practice can deepen their mastery since they do not have to spend time on the complete practice and can achieve higher levels of mastery higher than the initial practice without the division of labor.

In the past, a doctor dealt with all disciplines, and then a deep division of medical labor took place, and a gynecologist started to significantly differ in qualification from a dentist. A webmaster handled all the work on a small website, and then a deep division of labor took place, and the same work has been done by a back-end programmer, a front-end programmer, a designer, a content manager, editor, and many other activity roles. An engineer was "just an engineer" in the past, but today you cannot say anything without specifying what type of engineer it is. And so with all practices. Where there was one textbook of one discipline, ten textbooks for ten disciplines appeared.

Works are about the quantity of work and its speed, while labor/activity/practice is about the assignment and diversity of types/kinds/sorts/ways of work and their appropriateness/usefulness/appointment/role in the project.

In the 21st century, life cycle descriptions are no longer discussed as descriptions divided into stages of works only. These descriptions now also include practices: the main (not all! Life cycle descriptions are usually made at the concept level, not detailed design level) practices of organizational roles, which are performed as production works by organizational units. The creator concept as the system concept involves a functional/role decomposition of roles as subsystems of the creator, but also a decomposition of their behaviors, i.e., practices, not just constructive/productive synthesis of the organization/organizational units but also the synthesis of works. For a comprehensive systemic view of creators, organizational roles, organizational units, and their behaviors (practices/functions and works/services) and further placements and costs are needed. Mentioning the life cycle (a linear one-time "not cycle", or including development, a "cycle, even without reproduction") - this indicates not so much the target system, but the behavior of creation systems, considered both as organizational roles and the practices of these roles, as assigned organizational roles of organizational units and the works performed by them, implementing the practices of these roles.

The life cycle of a birdhouse would have been mainly considered as a carpentry practice, performed by carpentry works carried out by Fadey (organizational unit) in the role of a carpenter, just a few years ago it would have been discussed as the works of Fadey, and it doesn't matter what practice (carpentry practice was implied, but not explicitly discussed). Today, the concept "life cycle of a birdhouse" would be blurred, and it would be talked more about the program of creation and development of the birdhouse - because some continuous improvements in the design and materials of the birdhouse, methods of construction, would have been expected, and Fadey and his carpentry skills would be implicitly included in the discussion.

The life cycle of a nuclear plant today is considered a set of practices of conceptualization, design, construction, operation, modernization (unfortunately, we cannot talk about development - the industry is heavily regulated), liquidation, realized by works performed by project, construction, installation, and operational organizations in various organizational roles: the company founder, linear/operational manager, target expert engineer. Just a few years ago, it would have been mainly discussed as stages of works rather than the practices of those works.

The rigid conditions of government regulation make discussing development/evolution of a nuclear power plant very difficult, so the question of development is not raised at all: "modernization" is actually just "extending the service life of the power units" (in fact, it's a repair, not improvement with smart mutations in the project/design of the nuclear power plant) - this is how "life cycle management" at nuclear energy objects is understood. In any case, the main focus is on the sets of practices when it comes to life cycle management - not on sets of works. The works are discussed in the context of operational management, work management.

Improving the practices meanwhile is primary: if you don't know how you are going to work, you cannot say anything substantial about the work itself. Fastening two parts - what practice is this? If you don't know, is it welding, gluing, bolted joint - nothing can be said about the work. Therefore, practice (behavioral consideration of practices) is always logically discussed first, and work (constructive consideration) is logically discussed second, iteratively finding a balance to meet the conditions of project availability, economic efficiency, and other architectural characteristics that must be satisfied by the creation system. Because even the life cycle of a nuclear power plant is not so much about the plant itself and its architecture but about the creator of the nuclear plant (project and construction organizations, equipment suppliers) and its org-architecture (the creator of the nuclear plant is an organization, so we are talking about not just the architecture but the organizational architecture).

Creation systems have primary names based on the main function/practice, their organizational role. These names are built like any other system names, the issue was thoroughly discussed in the Systems Thinking course. A barber shop carries out the works of its service as an organizational unit (for example, as a private barber Olga, as an enterprise "Haircut Ltd.," or as a subdivision of the holding "AllHaircutSetting"), and the practice of hairdressing is carried out as ... a hairdresser! The organizational role of a barber shop is "barber shop," "hair stylist"! Unfortunately, in everyday language, organizational roles do not have special words for naming. And what about project roles? This is their function.

A project role can be not only a person (today it is the smallest organizational unit, where the agents are mainly people), but also any other organizational unit from the group of people and their equipment. The main thing here is not to generalize too much, the organizational role "clinic" or even more generalized "medical institution" usually does not allow for anything substantial to be discussed: a medical institution carries out too many practices/activities for the systems of different levels, and it is better to divide these "super roles" into roles with more understandable competencies, roles that an individual can perform as an organizational unit. Project roles are not "clinic," but "doctor" and "medical equipment technician," and even better not "doctor," but "gynecologist" and "dentist." It is better to adhere to the postman principle with organizational roles too (they are also functional parts, just like system creators!), not only with functional parts of target systems: it is better to give the address of the subject of discussion precisely, without "mumbling."

And the organizational unit? For each smaller role, there will be a smaller organizational unit. For a clinic - the company; for a doctor - not entirely clear what (and this should be worrying: modular synthesis will be difficult); for a gynecologist - a person skilled in/knowledgeable of the discipline, and equipped with instruments/practicing gynecology and occupying a position in the staff schedule and equipped with the tools/equipment necessary for their work: an organizational unit the size of one person. Is a community, or society, or even humanity an organizational unit? Unlikely: "org" here means organization, that is, everyone who manages the resources of the organizational unit is known. With a stretch, it can be said that in socialist dictatorships, it is clear who manages all the resources (the dictator, and then there is some delegation of powers "on-site"), but this approach proves to be extremely inefficient in terms of labor distribution on a large-scale; organizing (setting up a system of issuing instructions to do something) labor in such a way that the number of produced shoelaces somehow matches the number of produced shoes at the society level turns out to be an unsolvable task (the calculation argument by Mises, formulating this, has not been refuted so far). So in our course, we limit organizational units minimally to individual personalities (beings as organizational units will not work, you can't organize cats or elephants, expect computers with sufficient intelligence), and maximally to companies/organizations with all their computers, where computers are included at lower levels in the structures along with people and other equipment.

In systemic management, the discussion does not end with practices and works. Today, significant attention is paid to the concept of organizational capability to indicate the resource availability of a certain practice (meaning that a competent organizational unit is assigned for executing the practice, and they have all the authority to use the resources necessary for performing that practice. Competence means knowing how to execute the practice, including the competencies of individual people and the competencies in the coordination of the work/activities of these individuals, and resources include the necessary equipment and materials). Basically, when you are interested in not the "theoretical possibility of doing the work" (all people are educated, the equipment and materials are there - the practice is set), but the actual organizational possibility (the practice is set, resources are there, plus the authority to work according to this practice, and spend resources on it. The transition from the state of "practice set, theoretically it is possible to work" to "now it is indeed possible to work" can take many years. You may know how to use the latest nail gun, it may already be purchased and deployed, the special nails for this nail gun are already purchased, but the team will not use it, the already mentioned "political will" in our course needs to be shown - and you will be hammering regular nails with a stone or a microscope. You won't have a hammer either because "we just bought a nail gun!" - "It completely replaces the hammer, and even better!" This is a typical situation for organizational management where you need to distinguish practice ("how it's usually done," described in the textbook) from organizational capability ("how we will do it in our project"). But again: when we refer to an organizational unit, we most often talk about organizational capability - which means it is not just an organizational unit there, but an organizational unit capable of performing a service/behavior according to an