Flexible life cycle management methodologies and case management for work management. ​

If the milestones are unknown and the resources for their completion are also unknown, and the planning is carried out based on emerging circumstances during the project (all developments are like this: you don't know whether a new engineering idea will lead to success, or you will have to discard it after verification and come up with something new), then the very idea of upfront detailed planning has to be abandoned as a preliminary design.

Due to the widespread recognition of the utopian nature of the waterfall with predetermined timing for each stage for the vast majority of projects (except for purely conveyor-like ones, such as construction based on an already completed project), a new generation of methods for creating and developing systems has emerged, where the emphasis shifts from "creation" to "evolution." These methods are no longer associated with the "spiral" (which, as we recall, did not claim to ensure the long-term development of the system, but simply indicated the gradual release of versions of the system until all predefined requirements are met—and then the project must be completed).

The next generation of life cycle models received the name of "agile" development methodologies (agile development process/agile product development). This terminology has displaced the concepts of "life cycle" and "life cycle management," leaving these concepts essentially limited to the "hard engineering" of large military and government projects.

When using the term "agile," we are referring to a variation of the method/methodology (a complete set of practices) for life cycle management (but not work management!). These agile methodologies are considered a variety of the spiral model. They imply "operational flexibility" (the absence of a preassigned astronomical moment for completing work, the absence of upfront planning): assigning work (i.e., allocating resources) for life cycle practices can happen at any moment in the project. Thus, requirements (remember that at the time agile methods emerged, requirements were—precisely agile development methods and later triggered a shift away from requirements) can be adjusted closer to the end of the project—and then implement these requirements, it is one requirement to be implemented, not a complete redesign of the entire project! However, redesigning the entire project in the case of agile is not an abnormal situation, prototyping (which involves several complete redesigns of the entire system) also fits well within this life cycle management ideology.

The impossibility of upfront planning and classical project management approaches became particularly apparent in software engineering projects. Software systems were very different from one another, and in the beginning of a project, it was impossible to make assumptions about the work that needed to be included in the development plan closer to the end—unlike buildings, where it was known in advance that a foundation needed to be built and walls raised, followed by equipment installation and interior finishes; unlike planes, where it was immediately clear that the aircraft would include a fuselage, wings, cabin, in software systems, even determining their composition required some engineering requirements and architectural work, and therefore development work could not be tied to this composition upfront, before these activities were performed.

All these agile methodologies/methods and the corresponding life cycle models emphasize case management in work management. A case is a situation, circumstances, or initiative that requires a set of actions to achieve an acceptable result or goal. Case management focuses on the subject on which actions are being taken (e.g., a person, a legal case, an insurance claim) and progresses gradually with emerging case circumstances.

Case management essentially combines project and process management. Initially, a case presents a milestone question (issue, case statement, description of the expected state of the case subject as an alpha, realized by certain artifacts/work products, but the time of completing this description is still unknown), primarily focused on what needs to be achieved, with the timeline still uncertain.

Next, work is formulated to address this milestone. Formulating a task assignment for a resource is a separate operation, but the milestone can be determined long before this operation; the resource allocation for tasks and planning and scheduling are then dealt with separately. Convenient case management planning methods, such as Kanban, can be used here, primarily for case management, while traditional Kanban methods for manufacturing processes are usually employed for production planning. Even at this point, the life cycle of the milestone in case management is ongoing. Within the scope of configuration change management, project participants must be informed when a case is closed: the state of the system has changed, and everyone else needs to adapt to the new situation.

The technologies used for agile methods in life cycle management, particularly in terms of case management in work management, include tracking milestones (issue tracking, often referred to as task management systems, bug tracking systems, assignment tracking systems). The name reflects the fact that milestones arise in an unscheduled manner; they initially present as questions/problems (issues) requiring resolution. Incrementally, important issues transform into tasks assigned to specific resources (tasks are designated to be realized by specific resources, along with identifying the practices to solve the issue and resources possessing the relevant organizational capabilities to carry out the work for those practices), which are then transformed into notices upon completion. The world's state changes after solving the original issue/question/problem, and all relevant project roles need to be notified of this change.

Even if there is an opportunity to plan something, it is done within the framework of case management. Plans may simply be the how-to from a previous case that is leveraged as a template for future case runs. These records of past experiences (taken from the case file where everything happening in the case is recorded) are known as templates, if used for planning a similar successful sequence of sub-cases. If templates are prepared not by specially trained programmers of such templates but by team members themselves, it is referred to as an adaptive case management, and the templates are called community templates.

Differentiating life cycle management and life cycle models (e.g., waterfall, spiral life cycle, concurrent engineering, agile methods) and their corresponding work management methods (e.g., program and project management, process management, case management) within work management methods, planning methods (e.g., critical path method or critical chain method for project management planning, Kanban for case management). All of these are management practices within the organizational/engineering/entrepreneurial sphere and are recognized as separate, yet interconnected disciplines, without a clear understanding of their deep relationships in enterprises/project groups/organizational units/systems without a systems thinking and methodological mindset.

Here is a schematic representation of the life cycle of one of the most common agile working methodologies, SCRUM:

In this diagram, the non-linear/non-waterfall form stands out, highlighting the presence of daily work cycles and monthly "sprints." The non-linearity, the absence of prescribed clear stage execution in work practices, is a sign of a "principal scheme." The essence of the diagram is to show how alphas will change throughout the project. Key events (milestone moments, when alphas will change their states) include "requirements selection" (this is quite an old diagram, in 2008 when this classic and widely used diagram was created, requirements still existed), "client demonstrations," and others. The work content is affected by the development method shown in the SCRUM model on the diagram. It prescribes which work practices (e.g., the practice of planning sessions for the current sprint, daily meetings) need to be employed so that its alphas (e.g., product backlog alpha, sprint backlog alpha) change their states. Subsequently, the work of specific organizational units/resources will alter the artifacts/products that implement these alphas.