The variety of work management methods ​

In lifecycle management, decisions are made about which work management methods to choose, as there is a diverse range of these methods. The main question is whether it is possible to plan work in advance: how to conduct "logical planning" within the framework of lifecycle management.

What methods/practices to apply in general, what practices to use to treat a patient when it is not yet clear what they are suffering from? What practices to use to build a system when it is still unclear what it will be made of? In operations management/work management, "operational planning" is carried out - determining who (organizational unit) and when to perform a practice, by carrying out the necessary work to minimize the overall duration and cost of the work.

Work management has a variety of different practice options, each characterized by its own discipline variant, offering their own concerns and corresponding work flow description methods. The preference for all options is the acceleration of work flow while minimizing their cost.

Classic project management implies planning all milestones of the project, including deadlines and resources for their achievement, before the project starts. This means creating a schedule of all work with resource assignments for these works before the start of the execution. This is often referred to as upfront work planning, and the entire project is simply considered as a unique work with clearly defined start and end times, as well as resources allocated to it. In modern versions of project management methodologies, of course, updating plans during the project implementation is provided for, but actualization of existing work plans is expected, not continuous planning in small steps ahead in a situation of uncertainty about the content, budget, and project deadlines.

In addition to knowing the composition, complexity, and work sequence before the start of a project, project management also needs to know the resource production rates: resource productivity estimates derived from past work experience. In construction, for example, production norms are well known: how many bricks a bricklayer lays in an hour on average, how much rebar is tied by a steel fixer in an hour.

However, not all work with the system can be planned before the start of its execution when little is known about the system description (no system concept yet, no architecture, no "working prototype"), little is known about the system realization, and even little is known about who will be involved in creating the system - system creation (in project management, these will be "resources," both the organizational units themselves and the equipment included in their composition). It is easy to pre-plan for manufacturing and assembly projects when the system description is ready. This includes large-scale bespoke machinery manufacturing, construction. But it's usually not possible to plan in detail the work on the description/design of the system - often it's even unclear what resources may be needed during design, how many and what parts of the system will need to be developed. In this case, other work management methods are used that do not require mandatory upfront planning and mandatory knowledge of production norms for resources performing the work.

If it is unclear what the control points of large chunks of work can be, then we are talking about program management. As these control points are understood (engineering work!), projects to achieve them are launched as part of the program, using upfront planning to achieve each of them, as in classical project management. However, there is no plan to launch individual projects within the program (only vague outlines, often called a roadmap), as the program's activity consists of identifying these projects and planning them, and then the project works are managed by standard project management methods. Program management differs from other work management methods in that smaller work units are managed with a different practice: programs usually do not have "subprograms," but there are "projects." In projects, there are usually subprojects, in process management processes, subprocesses, in case management case subcases, and so on.

If the control points and resources for their implementation are known, but it is unclear at what moment a large number of similar works are launched, we are talking about process management. A process here is not a unique work but a typical sequence of steps, usually defined not so much by a plan (and certainly not by a schedule) but by regulations, and in recent years, instead of regulations, a computer program is more often used (then the "process" is called a workflow and it is stipulated that these are works, some parts of which are performed by people, and others by computers. In this case, the workflow is described twice: once by regulations and the second time by the program's code. But more and more often, nothing is written in the regulations, as the computer program defines very strictly what the worker participating in the workflow should and even can do.

All these work management methods listed gradually give way to case management, and this practice comes under various names. It has its own name only in medicine, and its variants are called by very different names (some "Kanban for development," supported by software like an issue tracker). But it is all operations management: the concerns of operations managers lie in who::department what::work when::time with what::work product, and the preference is that the overall work flow is made faster solely through the right choice of the timing of work launch depending on the availability of resources and unexpected decision solutions from engineers about the need for some work and involvement of unexpected resources.

A significant section in the course "System Management" is dedicated to operations management.