Segmentation

At the beginning of almost any project, one question appears sooner or later: how exactly should it be managed? Today, the menu is enormous, ranging from classical PMBOK-style planning to Kanban and agile approaches. Yet in practice, that choice is often shaped less by the project’s actual nature than by personal preference, corporate inertia, or the latest management fashion.

The problem is that a methodology is never neutral. It does not merely help organize work; it imposes its own frame on the project. It highlights some aspects, downplays others, opens some possibilities, and closes others. A mistake at this stage can cost the project more than it first appears—especially when the project’s real contours are only beginning to emerge.

Thermodynamic segmentation proposes a different move. Instead of choosing one universal management scheme in advance, it suggests assembling a management architecture around the specific project itself—taking into account its structure, the composition of the team, and the way uncertainty accumulates over time.

In other words, the question here is not how projects should be managed in general. The real question is this: which management modes, where, to what extent, and on what grounds are needed in this particular project?

That said, the limits of the method should be stated up front. It does not reduce management to mechanical calculation, nor does it eliminate professional judgment. Some parts of the procedure are calculative, some are expert-driven, and some require calibration as the project unfolds. Even so, the method offers something important: it replaces the ritualized choice of a methodology with a more grounded way of configuring management.

The easiest way to explain the method is move by move.

Move 1. Analysis and decomposition

Applied to projects, the Anna Karenina principle can be reformulated like this: successful projects tend to begin in similar ways, while failed ones unravel each in their own fashion.

That is why the first step is almost always the same: analyze goals, resources, and available competencies, then decompose the work into tasks.

This happens regardless of which methodology will eventually be chosen. But this is also where the first major mistake is often made: analysis and decomposition are shaped from the very beginning by a preferred management style. As a result, the project has not yet had a chance to reveal its own structure, but management is already being imposed on it from the outside.

A simple analogy helps here. When planning a trip, you can follow two strategies. One is to decide in advance which places you want to visit and build a route around them. The other is to arrive first, explore a little, and only then decide what deserves your time. Both approaches are legitimate, and both can miss something: either what never made it into the initial plan, or what never entered your field of view.

What matters more is that each strategy also changes how you prepare. In one case, you need to study the destination in detail. In the other, it may be enough to know how to reach the city center and start orienting yourself from there.

Projects work in a similar way. In classical approaches, detailed elaboration is a key part of the initial planning phase. In agile approaches, it is often only a starting point for later refinement.

So if no management method has yet been selected, it is wise to begin with the most demanding scenario in terms of analytical quality. This does not mean the entire project must later run under a rigid scheme. It only means that the initial understanding of the project should be richer than any management configuration that may later be built on top of it.

The outcome of this first step should include:

• clearly articulated project goals;
• a detailed task decomposition;
• requirements for team composition, size, and maturity;
• an analysis of weak points in both the team and the project itself.

The meaning of this stage is simple: a project cannot be properly configured through an external template until its own goals, work structure, and team characteristics are understood.

Move 2. Building the project plan and the temperature profile

Once decomposition is complete, a base project plan can be built. At this stage, PERT time estimates become especially important, because they form the basis of the project’s temperature profile.

That profile shows where uncertainty accumulates and how intensely it does so. In practical terms, it makes it possible to identify zones of natural heating in advance and see where management will most likely need reinforcement.

The outcome of the second step should be:

• a preliminary project schedule;
• a calculated temperature profile.

At this point, the plan ceases to be just a sequence of tasks. It becomes a map of the project’s expected heating—and therefore a map of its potential destabilization.

I discussed the nature of project heating and the temperature scale in more detail in an earlier article. Here, the key point is simply that the project is no longer seen only as a set of tasks, but as a system in which uncertainty accumulates unevenly.

Move 3. Placing management activities and optimizing interventions

Once the heating profile has been built, management activities are introduced into the project. Their purpose is to keep the combined profile within a workable temperature range.

This is where an important trap must be avoided. Management is not there to reproduce rituals or to serve a methodology for its own sake. Its role is to reduce accumulated uncertainty where that reduction is actually needed.

At this stage, two problems must be solved:

• identifying where intervention is truly necessary;
• minimizing the number and scale of management interventions so that they do not become a source of overhead themselves.

In other words, management is introduced not because the calendar says so, but because the project gives a substantive reason for it.

This is the point where a manager shows not loyalty to a school of management, but engineering judgment. They determine the composition of the interventions, their scope, their duration, their character, and the participants involved. All else being equal, preference should be given to activities with the narrowest effective scope and the smallest necessary number of participants.

The outcome of this step should include:

• a combined project schedule containing both productive and management activities;
• a structure of management interventions;
• a composite temperature profile.

In practice, this is the stage where the project’s cooling contour is designed: where, to what extent, and by what means management should compensate for rising uncertainty.

Move 4. Forming the primary segmentation and classifying segments

Once the key management activities are in place, the natural boundaries of the project’s primary segmentation begin to appear.

At this stage, it becomes visible how the project breaks into areas:

• with different patterns of uncertainty accumulation;
• with different coordination requirements;
• with different valid forms of local management.

The segments are then classified: which are local, which are end-to-end, which arise naturally, and which require an artificial managerial boundary.

The outcome of this step should be:

• the project’s segmentation structure;
• a classification of its segments.

This is the first point at which the question of methodology becomes truly concrete. Not “Which is better, Scrum or PMBOK?” but “Which management mode is appropriate in this part of the project, at this stage of its progression?”

Move 5. Finalizing the segmentation structure and aligning it with local management methodologies

After the primary segmentation has been established, the project is assembled into a second, more engineered configuration.

At this stage:

• the final segment structure is fixed;
• appropriate management modes and methodologies are chosen for each segment;
• the project plan is rebuilt in accordance with the chosen management architecture.

This is one of the key moments in the method. It does not attempt to reinvent management rules from scratch. Instead, it draws on existing approaches where they are genuinely appropriate. That is precisely why it does not become yet another universalist dogma.

The management literacy of the team matters greatly here. It determines which methodologies are not only theoretically suitable, but actually available in practice. The choice, therefore, should not be made from the entire universe of theoretically admissible methods, but from those the team can apply competently and meaningfully.

At this stage, segments are matched not only with abstractly suitable management modes, but also with the team’s real ability to sustain those modes.

Move 6. Project launch and execution

Only after that does the project proper begin.

But now the project is no longer executed simply according to a plan or merely within the logic of a chosen methodology. It unfolds within a previously assembled architecture of segmentation and management. That means execution is no longer the only thing that matters. What matters as well is whether the project’s actual behavior corresponds to its expected temperature profile.

Field assessment of a project’s current temperature is itself a separate and fairly difficult topic, worthy of its own discussion. Still, even at a basic level, observed heating should be monitored and compared with planned values.

This is the point at which the model is first tested against reality. If the gap between expected and observed behavior becomes stable, there is now a reason to move to the next step: reconfiguration.

Move 7. Reconfiguration

Reconfiguration is triggered not because the calculated temperature happens to be high or low in itself. The trigger is different: the actual behavior of the project diverges consistently from what its temperature profile predicted.

This means the source of error may lie in different places:

• in the model itself;
• in the assessment of team maturity;
• in the segmentation structure;
• in the intensity of management interventions;
• in a mistaken understanding of the project’s current phase.

This is the point where the method fully reveals itself not as a static setup scheme, but as a closed management loop.

In essence, two basic kinds of reconfiguration are possible:

• hot reconfiguration, when the project is governed worse than the model suggests it should be;
• cold reconfiguration, when the project is governed more densely than it actually needs.

Overheating and hot reconfiguration

Overheating does not appear only when the calculated temperature is high. It can also arise when, despite a formally acceptable profile, the project begins to exhibit managerial chaos.

Its signs may include:

• cross-team coordination spilling beyond the designated management contour;
• a growing number of shadow agreements;
• unstable decisions;
• intensified horizontal coordination that fails to produce clear managerial fixation.

In other words, the project starts looking less governable than the model suggests it ought to be.

In such a case, hot reconfiguration is required—as a form of emergency cooling. It may include:

• limiting or partially stopping project activity;
• reassessing goals;
• creating a new decomposition;
• creating a new segmentation;
• rebuilding the management structure.

In essence, this is a local restart of the project, or of part of it.

Overcooling and cold reconfiguration

Overcooling occurs when the management contour becomes excessive relative to the maturity of the team and the real rate of uncertainty accumulation.

Its signs may include:

• management activities continue, but no longer produce meaningful decisions;
• discussions increasingly end by merely confirming what is already known;
• management density remains high while useful return declines.

In other words, the team has become capable of carrying a greater volume of natural uncertainty without that many interventions. It is important to note that this is not “good news” in itself, but another form of mismatch between the project and its management system.

In such a case, cold reconfiguration is required. It may include:

• reassessing team maturity;
• temporarily weakening or reducing management interventions;
• observing the project’s natural heating;
• revising the temperature profile;
• rebuilding segmentation and the management profile around a more mature mode of operation.

What is restarted here is not the project itself, but the management system around it.

Grounded management

The core idea of the method is simple: management should emerge from the nature of the project and change together with it. Goals, tasks, and resources define the structure of the control they require, and the structure of management interventions can then be used to choose an appropriate methodology. This contour may be called a natural management contour.

In that sense, the method really does operate at a meta-level of project management—and that is also its weak point. To use it fully, a manager should ideally be able to work across different management modes, understand their strengths and limitations, and combine them thoughtfully rather than switching between them mechanically.

Even so, the method is useful well before that ideal level is reached. Even when a team works mostly within a classical management approach, the very act of building a natural management contour helps reveal the project’s real tension points and the appropriate degree of managerial intervention.

In other words, this is not about choosing the “right” methodology. It is about choosing the right place and the right measure for each of them.