System life cycle 1.0: work items changing the states of the system-of-interest ​

At first, the life cycle simply denoted a period of time during which creating systems carried out work with the target system, and following an analogy with the biological cycle, the sequentially conducted work was related to different stages, sometimes called phases of the life cycle --- periods of time during which the system was in some state. There was no evolution, no hypotheses, just meeting requirements. Although prototypes could be considered, they were "sequential approximations to the final version," no "infinite development," no "continuous everything," but "achieving the goal": the result of the work.

The life cycle of a teapot was called a period of time during which work was carried out with it (after all, a teapot cannot make itself, it's not biology --- all work with it must be done by some external creating systems). These creating systems had to decide to make a teapot (and not a coffee pot), document the requirements, then (sequence matters! Requirements first, then design --- these will be "stages") design the teapot (select the appearance and materials), make the teapot (purchase and manufacture materials according to the project), then use it for brewing tea (operate it), then break it and throw it away. This was all time of work by the creator with the teapot as the target system, and it was called the "life cycle": "a period of time," while the work themselves in their highest-level partitioning: decision-making about the teapot, designing the teapot, manufacturing the teapot, operating the teapot, discarding the teapot were called "stages/phases of the life cycle": work. Note the difference in object types: the life cycle is a period of time (measured in hours), and the stages are work, when someone does something with something, changes the world. Work is a dynamic object/change/behavior, not a period of time of the existence of this object, that is the period of time while changes are happening. The life cycle was "twenty years," divided into "formulate requirements for the fence," "design the fence," "build the fence" (and two years have already passed), "make sure the fence is in working condition" (eighteen years), "demolish the fence and dispose of the construction waste" (last two weeks out of twenty years of the life cycle).

Let's call this understanding "life cycle v1.0"^[1], it was developed somewhere in the 70s of the last century, not only in systems engineering, but also in management, which was considered a more or less "psychological" special discipline at that time, rather than just a drain of systems engineering for organizational systems. Systematic approach then recognized not only systems engineering coming directly from it, but also operations research/operations research^[2] --- research of work/operations with the aim of making better decisions to speed up their completion. Operations research soon ceased to be "analytical," that is, only research, and in its synthetic/managing guise, turned into operations management (operation management, with an emphasis not only on understanding and reports, but also on actions based on these studies --- actual management, changing the situation in terms of streamlining the flow of work through the resources performing these works).

Next, this work management/operations management/operations management based on some understanding of the then systemic approach developed into classical project management, as it is understood today in management (although in addition to managing operations, project team organization has been added today, detailed explanations are provided in the course of systems management^[3]). We consider operation management as operational (i.e., occurring with an already created system) the engineering of an organizational system.

One of the most popular books on project management, released with its first edition back in June 1979, is Harold Kerzner's "Project Management: A Systems Approach to Planning, Scheduling, and Controlling". That is, project management at the time of its emergence was the application of a systematic approach to planning, scheduling work, and controlling work execution. This resembles how classical "iron" systems engineering was understood at that time: applying a systematic approach to engineering work.

Of course, the use of a systematic approach in management does not today limit itself only to operational management. Essentially, all management as a specialization of systems engineering for creating and developing organizations is built on the systemic approach.

The concept of life cycle 1.0 as the production time of work creator with the target system (no talk about creation chains) was actively developed both in systems engineering and project management for decision-making on planning and scheduling work.

"Work" is specific processes in which resources participate for these works. Anastasia hammers nails into boards with a hammer. Hammering nails is the work she does. Works are usually named not after their goal, but after their current content --- not "joining boards", which can imply both gluing and nailing connections, but specifically "hammering nails," although there are many other options. Overall, works turn out to be sessions of the service of system creators as service providers (remember service ontology from the system thinking course). These service sessions, viewed as work, completely lose their specificity: it is simply behavior of some resources **participating in the work / participating, this is a specialization of the relationship composition / part of / part-whole, but not only as volumes in space, but also extended ​​in time. For example, the work "hammering a nail" consists of a hammer every 30 seconds, a nail, boards, and a worker hammering them. They need to be assembled together in these 30 seconds in order for this 30-second work to occur.

Discussing works is usually the subject of operation management and it involves the logistical subject of interest: time to pass work flow. The focus here is not so much on the content of the work (this is discussed as a method/practice/way of working), but on how to use the available resources for this work to achieve the optimal time for the work to pass (not always minimum, because sometimes it's more important to evenly allocate resources than to achieve the minimum execution time, which usually requires a very uneven load on resources). In operation management, the focus is on operational facts apart from work methods. The area of interest of operational management includes such important characteristics as time for resource allocation to work, time for using resources for work, prices for using these resources (no matter what and how they are doing, this is handled by other roles in other practices, the operation manager is only interested in how much the resources are working and how much they will cost), and the time of the work itself without delving into the methods of its execution. Life cycle 1.0 as a sequence of major work-stages thus reflects the modular/constructive/product representation of the work of creating systems. A "project" is the work of the organizational unit as a group of organized agents, biological and otherwise, with some equipment and materials, authorities to conduct work (a project is not even the work of organizational units, but the work of organizational capability). The goal of a project is its work (it is more correct to talk about the goal of the organizational unit or even the organizational capability, the "goal of work" here is --- a metonymy^[4]) of creating and developing a system. Moving forward, if we are talking about a unit-organization, then it has already reached the state of organizational capability --- all skills, resources, and powers to manage these resources by the unit have already been obtained.

Terminologically, the term project sometimes means the work of the project unit (often replaced slowly), and sometimes it means the unit itself, that is, a project as an organization of the project. In life, both meanings of the term are encountered, and they must somehow be distinguished: confusion of the project team (which usually changes slowly) and the work of this team (which can easily be replanned) should be avoided. "The project changed the color of the fence from red to blue" can be understood as "the work changed the color of the fence" and as "the team changed the color of the fence with its work," so attention must be paid to the context --- sometimes these ontological differences are not important, sometimes they are important. But you cannot send a letter to work, but you can send a letter to the team. Therefore, "I wrote a letter to the project" --- there will be ontological inconsistencies in this case.

In the course, we will also use both meanings, but more often by project we will mean the unit with all its resources and powers (i.e., organizational capability). In this understanding, the project::organization leads the work and "creating a project," "organizing a project" means creating an organization that will then perform the project work as services of this organization.

To assemble some necessary (target, thinking about the utilization time) structure from boards, we need to create a project/project/creator::organizational unit. This project (creator, thinking about the creation time of the structure from the boards as the target system) consists of modules of Anastasia-with-responsibility, a hammer, 20 nails, four boards. We also need to plan all these resources for 20 minutes; otherwise, the work will not happen. These are all managerial works: managers create projects (organization creators).

We need to get all this from somewhere, and the result of the work (assembled boards) needs to be sent somewhere --- this is also a task not for engineering, but for management (logistic, i.e., on moving resources from one place of processing to another). The operation manager (a role conducting the practice/labor of operations management) is interested only in logistics, "how to assemble work from its parts-things/resources." Not interested "how the work is being done, why it will yield results," how nails should be hammered, and why boards need to be fastened with nails, not glued together, or even fastened with ropes, nor interested in making the nail connection sturdy. And therefore, discussing the works how to work is useless, discussing works is related to resource planning and monitoring plan fulfillment: minimizing the time for the work to pass, is the typical preference of the operation manager. Discussing works requires discussing not works, but practices!

It's worth noting that in fact, the life cycle does not say anything about the target system and its states. It talks about what the creating systems do: they work, not the target system. The target system is passive, it is the subject of work, in modern operational management the work on some changing object is called a case/task (from "legal case", medical "medical history", case file --- a folder "Case #__"). In the hammering nails case, the target system (when in operation!) is the hammered nail. All work for this, and the case itself will be named after its subject --- "nail" (the subject of this work). This variation of operational management is called case management in its various versions, such as adaptive/dynamic/advanced case management^[5], which in recent years has ceased to exist as a compactly presented discipline due to the widespread adoption of low-code software support for streamlined programming, universal modelers, LowCode^[6]. Very often, a "project" refers to a more or less large case. The word "project" has completely detached itself from classical "project management."

This was only in the biological life cycle in the wild where any egg or caterpillar creates themselves! Remember that creators/enabling systems/constructors are called in system thinking not systems that provide/supply/feed during operation (usually done by the environment, systems of operation time), but systems that guide/move the system during creation, modification, and dismantling and then repeat it multiple times during system development/evolution.

The methodology uses system thinking and views such creating systems as projects/organizational units/enterprises/teams/collectives/organizations, just as it views any other systems:

• As functional objects, it sees them as a set of organizational roles that perform practices/work by the method
• As constructive objects, it sees them as organizational units that, during their use, "carry out work"/"provide services" (and how exactly the work of that constructive object will proceed --- is a different matter. The constructive representation endeavors to abstract from the method of work achievement).

Reasonings about the fact that creators can be communities, societies, and humanity are currently not formulated so strictly. So we will limit ourselves to human creators and their organized (clearly defined authority to manage labor, materials, and other resources) groups in the subsequent sections, that is, to creator-organizations/organizational units. And don't forget that with the development of machine/artificial intelligence (AI) and the emergence of scaleless thinking against the backdrop of the total automation trend, there is also an alternative understanding: organizational units are represented as "semiautomatic," that is with a computer (possibly with sensors and actuators), which is serviced by people. This is all a symmetrical representation --- human and computer working together to perform service S at interface I can be considered as "machine and its operator," or as "operator with his machine,".

By actual act, Anastasia, providing the service of nailing, takes her hammer and hammers the nail #143 into board #26, i.e., performs a work. The life cycle of the nail in the views of the last century (first generation, 1.0) no longer consists of states of the nail ("lays in the box", "taken in hands", "aimed", "hammered", "nailed"), but of the work happening to it, which of course can be described as final states of the nail, but they are in fact works of system creators, for the nail itself does nothing in response, it is passive. The life cycle in non-life cycle never assumed an "Aristotelian physics" where the finger presses on the table, and the table is not pressing on the finger. Creating systems operate, and the nail does nothing in response, it only changes states as work with it progresses. Systemic thinking even in this early version of life cycle representation tracks to make sure the discussion concerns the complete life cycle, rather than just a fragment at the moment Anastasia is striking the nail. Anastasia's works are part of her work! Here is an approximate life cycle of a nail as stages/works (it’s "the nail case," but it will be recounted as "nail states passage," and the work practices on moving the nail from one state to another will be selected based on the situation):

• Discovery of the need for nail connection (the nail is planned --- but this was written less often in the 1.0 life cycle, because it refers to a work result, not a nail! The state "nail is planned" indicates the result of a work service by independent services to form a consolidated order specification that entered the procurement service. Writing "nail is planned" when referring to the change of a nail state as an object of the case is more correct, as it is easier to control the work result, but this was rarely put in writing in documenting the life cycle in the first-generation understanding. Although it is exactly how the primary work result should be described as the name of the work in project management methodology PRINCE2^[7], it is a good naming practice. Remember that "a big case is called a project," and the link between case management and project management is detailed in the "Systems Management" course).
• Procurement (or nail is purchased --- remember, the 1.0 life cycle is concerned with works, not states of the nail! Nail states are important when discussing the target system and its traversal of various states during the life cycle --- that is, traversing different states during work with the target system. The "nail is purchased" state here indicates the result of a procurement service work for the nail, and the work with the nail --- "procurement," was indicated, always omitting even the word "nail," reducing "nail procurement" to just "procurement." Managers like to generalize when writing about works, the content of the work and the specificity of that work are of no interest to them).
• Issuing to assembly (or nail is available at the nailing spot --- a note referring to the work on issuing the nail to assembly. From here, no further explanations regarding these details will be written, the idea is understandable).
• Aligning the nail (nail is aligned).
• Hammering the nail (nail is hammered).
• Checking the strength of the connection (the "nail holds tightly," but the object has changed. Now it’s a "connection." A doll turned into a butterfly! Different object, renamed differently).
• Operating the connecting (connection holds stably under load)
• Pulling out the nail (nail is pulled out).
• Disposing the nail (nail is thrown out --- the life cycle always continues until the object of work disappears).

The life cycle --- always, even in its early versions, guides the creators from the moment the target system idea appears until the target system destruction (including operation: we believe this is also conducted by creators, although the system is already created during operation. The elimination/disposal from operation is handled by creators, even though it is a reverse action from creation). Moving forward to the life cycle at the moment of the appearance of the third generation of the systemic approach with its time of evolution/development add to the development. This means that during the development, numerous life cycles of systems and individual features of these systems are completed.

The methodology keeps the attention of the project team/creators not only on the current operations with the target system, but on all from the moment the idea appears to the destruction of the system, as well as on the multiple of these operations during the system's development/evolution, not just the one-time conception-design-manufacturing-operation-disposal. Always keep the attention of the team or even the collective (team of teams) **of the project on what has happened to the target system before, what is happening now, what will happen later, and also keep the