Problems with the life cycle 1.0.
But the new concept of the life cycle (compared to the state change of the target system) did not have time to take root, and problems began to arise.
The first problem with understanding the life cycle as a sequence of major project works: in real projects for creating systems, the stage approach began to degenerate massively. First, in agile software development approaches, thematic stages of work were replaced by unnamed "iterations" of fixed length — and it was very difficult to track the main theme of work in these iterations. In fact, each iteration involved envisioning a piece of the system, developing it, testing it, and using it, and while it was understood that all this needed to be discussed, the idea of "stage as a period of conducting similar work, followed by another stage for conducting similar work of a different type" did not survive. The era of the "waterfall" as a "sequential passage of stages of the life cycle" ended even before the emergence of the idea of "continuous development," in which multiple linear life cycles and the system as a whole, and its features, closed into the initial "quasi-biological" ring/cycle. The quasi-biological cycle is still techno-evolution, not Darwinian biological evolution — mutations are not random, and the hereditary material does not replicate along with the system.
Next, in construction projects, "concurrent engineering" emerged, intentionally carrying out work in parallel/simultaneously that were previously considered strictly separated into different consecutive "thematic" stages of the life cycle: design and development of the system were carried out simultaneously, and incomplete versions of the system were even put into operation (for example, the wing of an unfinished building).
This led to questions in the early 21st century regarding the idea that work in life cycle stages is conducted with a certain state of the target system. Different parts of the system were in different states, and all types of work were conducted simultaneously on different parts of the system: if a ship was being painted, it was not done as before — first stripping the entire surface, then priming the entire surface, then painting the entire surface, then drying it. Rather, more commonly, a piece would be stripped first, primed, while simultaneously starting to strip the next piece, then painting the first piece, priming the second piece, and starting to strip the third piece — and "first" and "then" turned out to be strictly local to each piece, not global for the entire target system. Stages of "stripping," "priming," "painting," "drying" turned out to overlap in time/be concurrent, meaning they ceased to be sequential stages, a grouping of work sequences!
On one hand, the sequence of work was obvious to all (you can't paint without priming, prime without stripping), but on the other hand — one couldn't say "here the entire system is clean, now it's primed, now painted." When describing the sequence of types of work (this is now a discussion of the content, not resources! Functional consideration, not constructive!), time for the system as a whole turned out to be logical/functional/content-based, not physical. The work itself is physical, but the types of work, in terms of their content, turned out to be something else — the content of the work and their "logical" sequence/relationship needed to be discussed in a different way.
Talking about the "staging" of the life cycle became more and more conditional, rather than essential/substantial. Discussing work and resources was productive (operational management!), but discussion of the staging of work — not so much. Therefore, the concept of the life cycle as a set of stages as "aggregated works of a similar nature" became less convenient to use.
Here is a typical illustration explaining the transition to concurrent engineering (and it is clearly seen that the durations of all tasks in creating a system are significantly reduced):
Secondly, the problem of understanding the life cycle as a sequence of major "thematic" works: interfaces between works were discussed from the standpoint of work flow, operational management, resource availability in project management. The results of previous works/output became available for the next ones in the chain of work flow/input. This was very convenient when the question was about the precise response to the stage of "how to do the work": "when and by whom will the work be carried out, when will it be completed?". But when functional issues were discussed (how does this set of work create a system? Why these works, and not others?), how to best perform the work in terms of technology (rather than faster, i.e., an engineering question, not a managerial one), there was a lack of concepts. Discussion was needed on how and why to change the substantive set of works, rather than optimizing the start time of each pre-known work or optimizing the resource supply of each pre-determined work — information was sorely lacking: information about the types of work, the purpose of the work and its content, rather than the works themselves and their resources regardless of their content.