Again about organization of development/lifecycle management/system creation and development management
Have you already noticed that our courses cover each question two to three times to train the student's neural network? Unfortunately, humans are not computers to instantly load complex schemes into their brains: they need each new concept and its relationship with other concepts to be presented several times for memorization to occur and for associative links to be established with existing knowledge.
A very common mistake, not only among students but also among engineers, is ignoring discussions on development organization/development process management/system creation and development management (in old terminology known as lifecycle management): ignoring discussions on practices, ignoring understanding of how system creation and development happen in their project, what development method they use and how successful it is (in old terminology -- which concept/type/model of lifecycle is used). Of course, by "development," they mean all practices necessary for system creation and development -- including development, visionary work, architecture practice, and production platform creation practice. But, just as you rarely hear the more correct "continuous everything," but rather either continuous development or continuous delivery, understanding should actually focus on the "everything," not just development or deployment. Similarly, in managing the development process, it is crucial to understand management of the entire system creation and development process, not just managing development alone, excluding architectural work, production, or product profitability tracking.
All of this talk is about practices. Students make "novice mistakes" and list not the practices of system creation and development, but rather work tasks -- and then the discussion moves to operations management/work management: instead of discussing roles, practices/methods/ways of working and required technologies, they talk about resources, project start dates, work duration, responsible performers/organizational units.
By now, you should have a better understanding of what a lifecycle is, and you won't confuse lifecycle management with work management. Just in case, we'll remind you of the main differences.
Discussion of work execution methods and what projects at various points (roughly: throughout the project at various moments as the need arises, or at certain "stages") are undertaken from the perspective of their substantive necessity (rather than resource availability), work execution in the correct substantive sequence (regardless of resource availability, e.g. "priming before painting, not the other way around"), coordination of results during execution to prevent configuration clashes -- all of this falls under development organization (product development), considering all other system creation and development practices, which are often historically referred to as lifecycle management. This is a practice that is half engineering and half managerial: engineering when discussing methods/practices as functional/role behaviors and considering the time of system operation (remember, it is all about "system creation and development," emphasizing the "continuous everything") as organizational roles.
Development organization/lifecycle management answers the question of how the creators are organized, what skills and equipment they have to ensure a successful target system creation, and how to sustain its success over time (through development!). Engineers choose development methods that are well-versed in the technological operations, the services that the system creators will need to perform operations in the correct sequence to change the descriptions/project/design state of the target/created system and then realize this system. Unlike a butterfly or a cat, a house or a rocket will not build itself. Someone must indicate the methods and ways to do it, in which sequence. This is what development organizers/lifecycle managers do.
In terms of development organization/lifecycle management, the focus is on understanding who does what in the organizational units, what work can be assigned and then requested, and not so much on the practices themselves. The organizational designer needs to understand what the units assigned to them will be doing, the leader needs to understand how to explain to people how they will cooperate. For organizational design, the development method must be known (for example: should a system architect be assigned to a separate division? The organizational designer and organization architect must be aware if there is a practice of architecture in the development method that will be adopted in the project! And they need to assign someone in the role of architect to start performing their functions -- but they will learn about the need for these functions in development from the development method/lifecycle concept).
Among other things, the development organizer traditionally guarantees the integrity of the practice configuration: no practice will be missed (that is, they will be planned and executed at an engineeringly appropriate time with the practitioners), the inputs of one practice will be able to work with the outputs of other practices (for example, data will be re-encoded from one format to another if it's about information technology). Furthermore, the development organizer/lifecycle manager will ensure that practices are supported by technologies, and employees use support technologies as intended by the practice discipline/theory/explanations. A lifecycle manager often functions in the role of CTO (chief technology officer) because this role has a better grasp of the work practices leading to the creation of a successful system. They are not developers or architects of the target system; they are engineers whose focus is on the systems of creation (people trained in practices and technologies/tools provided to them for support). They are not fully responsible for the enterprise concept and architecture; they are less concerned with allocating organizational units to organizational roles. However, they are concerned with the methods/practices/ways of working of the engineers of the target system (and recursively all parts of the target system). They engage in substantive discussions about engineering methods of work. Target system engineers work with the target system (and remember, roles are roles, and role performers can play many different roles).
Moreover, system configuration management and changes are often attributed to lifecycle management: after all, configuration changes occur during the course of lifecycle practices, during system creation and development! Therefore, lifecycle management is often referred to as engineering documentation management (documentation describing the target system as well as its lifecycle -- what to do during its creation). However, this is just the form of work: it is checked whether the system architecture practice is implemented, whether there is architectural documentation, but there is no interest in the architecture itself; this is done by the target system architect, while the lifecycle manager works in managerial form, they are not involved in architecture but are involved in lifecycle organization.
Don't expect that everything will be named uniformly everywhere. The practice of development organization as a separate practice is new, and the concept of the lifecycle is just beginning to fade. It can be difficult to understand the "work method" today. So names will vary. For example, in the SAFe development organization method[1], which is referred to as a framework, a scaling agile framework, SAFe, they define the transition to a continuous flow in the Enterprise Solution Delivery competence[2]. We can see that it discusses the organization of the development process and even shows traditional explanations of how the old "V-diagram" as a development method concept differs from "continuous flow" as a development method concept (we explain this V-diagram in detail in our courses, as you will encounter it in the most unexpected places, so you need to understand what it is trying to convey and what practice people are expressing when they draw it). However, it is not easy to visually recognize what came to replace it later, as there is a rare diversity. But upon closer inspection, you can see traces of the bumpy diagram, and even "requirements" are still among the practices).
Here is a diagram from the SAFe 5th version[3]:
And here is a version of the same diagram from SAFe 6.0, released in March 2023[4]:
We can see that traditional practices are receding, and instead they discuss that out of hundreds of statements about the future system during continuous development (flow both in work and development, although often translated as "stream"), thousands of statements about what the system will be and a multitude of decisions accumulate as the process progresses. However, requirements are no longer present (though some references to them remain in other parts of the documentation, they are minor), leaving only "Evolve the Solution Intent" -- the gradual formation of the intention to have the final solution. This intention is never final (part of it is variable, meaning that some questions remain, and thousands of statements about what the solution will be never completely turn into a complete solution intention, questions persist).
We will not discuss the practices themselves here (for example, if you already have a usage concept ready, even called something else, for example, "intention to develop an engineering/software solution," should you then prepare requirements afterwards?), for that, you need to take a course in systems engineering. But maintaining a conversation about practices is necessary for you to understand what your small project (a small piece on this diagram) or your large project (comprising several such diagrams, each structured differently, plus someone will use the old V-diagram, and someone will deploy this SAFe -- either 5th or 6th version, and some will say they have SCRUM with completely different words, while others will create a unique development method and will be right as well, maybe even more so -- remembering the inapplicability of complex development methods/methodologies today!).
Development organization/development management/system creation and development management does not address the questions of "who does all this" (organizational units as resources) and "when it is done" (operational management, task completion time). The logical "when" includes "paint only after priming" (an engineering remark), while the operational "when" with specific resources ("Vasya paints at 12:00") -- this aspect is not included in lifecycle management/development management/system creation and development management because there are no instances of practice execution, meaning there are no works. There isn't actually a flow of works, only a description of "continuous development" as a type of executing work according to certain practices in their complex interrelation, referencing the "continuous everything," not "continuous flow of actual work."
Instances of works (i.e., tied to specific time and resources for specific methods/ways/practices/types of activities/labor) are handled by work management/operational management: Operation management involves managing resource allocation to meet all checkpoints on time and within budget. Lifecycle management/development flow (not work flow!) is considered predominantly an engineering discipline (requires a good understanding of engineering methods), while work management (work flow!) is purely a managerial discipline (requires a good understanding of operational management practices).
Work management abstracts away from the engineering essence of operations, the knowledge of work execution methods. Work management aims to achieve the fastest and most cost-effective work completion, using not engineering methods (e.g., changing the manufacturing method) but managerial methods (if the productivity of a processing machine for a pile of homogeneous parts is low, add another machine -- it doesn't matter what the process is).
Work management and development management are closely intertwined. For example, in systems management, you will learn about "firefighting" as a way to eliminate emergencies and "fires" in a project. There are five steps, three and a half of which are engineering, and one and a half are operational management. This illustrates how difficult it can be to distinguish between work management and development management even within some particular practice. However, to maintain clarity of thought, it is essential to clearly differentiate these practices since engineers and managers usually have different responsibilities (and use different computer applications). If it's difficult to separate them, one can always carry out a practice together with two roles, divided among different agents, coordinating actions with each other.