This article on MediumIn the previous article, I showed that any project management methodology—whether consciously or not—introduces project segmentation. In essence, it is a way to reduce a multidimensional space of tasks to a manageable linear form.
Instead of observing segmentation from the outside, we can treat it as an independent control mechanism and attempt to use it deliberately. In doing so, segmentation stops being a hidden by-product of methodology and becomes a management instrument in its own right.
Like any instrument, however, it is not neutral. Applied consciously, segmentation strengthens control and clarity. Applied implicitly or inconsistently, it can just as easily erode them. That is why, before moving on to a formal theory of segments, it makes sense to pause and fix a set of rules for working with this tool — a codex rather than a doctrine.
In this article, I formulate the core principles of project segmentation. Some of them may seem obvious—but precisely such things are the most important to state explicitly. Others follow from rational considerations, while a third group represents an attempt to generalize useful practices encountered by many project teams.
So, let us begin with the first principle.
1. The Principle of Tolerant Hierarchy
When a project reaches a certain scale, segmentation inevitably produces a large number of segments. Managing them as a flat, homogeneous set quickly becomes inconvenient, both analytically and operationally.
As a result, segments naturally begin to group. Short intervals form stages, stages combine into phases, and phases become higher-level structures. In this way, a hierarchy of segments emerges almost on its own.
This forms a hierarchy of project segments. It not only simplifies tracking and control but also provides an additional degree of freedom in management. Different levels of the hierarchy may employ different types of segmentation—those best suited to a particular scale and context.
This makes it possible to abandon the dictatorship of a single segmentation criterion and replace it with a hierarchy of diverse segments, tolerant of a project’s specific characteristics. At the same time, the unifying focus of management is preserved, while the model itself is enriched with nested detail.
Example and Methodological Link
For example, at the top level of the hierarchy, a project may be segmented by product criteria. Nested segments may then be evenly divided using rhythmic segmentation. As a result, both approaches benefit: at the strategic level, the project follows product logic, while at the tactical level it maintains the cadence characteristic of agile methodologies.
A useful analogy here is a television series. Each episode has its own internal rhythm and narrative arc, yet all episodes contribute to a single overarching storyline that unfolds across seasons.
In practice, this approach allows the accumulated experience of PMBOK to be combined with the dynamics of Scrum. In fact, this is how projects are usually managed—it is just rarely made explicit. Frequent planning meetings in classical approaches can be seen as precursors to agile practices; at the same time, an agile team planning a sprint always relies on a WBS structure.
A hierarchy of segments enables explicit management of interactions between methodologies and, more broadly, their combination. In essence, it is a mechanism for their coexistence.
Principle Formulation and Limitation
Formally stated: project segmentation may be multi-level. Segments can be subdivided into subsegments, and each new segmentation scheme may use its own defining criterion, localized within the parent segment.
A small practical note: to preserve analytical meaning, each segmentation should contain at least three segments. From this follows a natural limitation: a project consisting of A base activities can sustain no more than log₃(A) hierarchy levels.
This is an important limitation: each additional level introduces new constraints that every base activity must satisfy simultaneously. Beyond a certain depth, the model collapses under its own weight.
2. The Principle of Respect for Criteria
Each segmentation scheme must be based on a single dominant criterion—product, resource, risk, periodicity, strategic horizon, and so on. A limited combination of heterogeneous criteria is permissible only within a single branch of the hierarchy and must remain local.
This principle is difficult to follow—and precisely for that reason, it is crucial. Choosing a segmentation criterion requires weighing multiple factors and consciously rejecting alternatives. By its nature, this is a managerial decision made once and then consistently adhered to.
By selecting a segmentation criterion, the project team defines the execution policy the project will follow in the near term. This is not an instrument of coercion, but a way to conserve managerial resources.
As will be shown later, for complex projects the scarcity of managerial competence is one of the key limiting factors of effectiveness. Once a specific criterion is adopted, the team temporarily gains a principle by which many decisions can be made automatically or with minimal discussion. In disputed situations, priority is given to the decision that most closely aligns with the spirit of the chosen segmentation criterion. This significantly reduces the burden on management and avoids repeated renegotiation of the same issues.
It is important to note that the chosen criterion does not override other project requirements. It merely defines the order in which they are resolved in case of conflict and sets local priorities.
Here the principle of reverse seniority applies: the most significant criterion is the one closest to the current work. Requirements originating from higher hierarchy levels should be considered and followed where possible, but not at the expense of the chosen local segmentation basis.
In the earlier two-level “classical / agile” example, this means the following: if pace was chosen as the final criterion, it is precisely that pace the team must prioritize. In this case, large and complex WBS tasks are artificially decomposed to fit sprint boundaries, even if they might appear more cohesive from a higher-level perspective.
In practice, the absence of an explicitly chosen criterion often leads to negative effects: every decision must be re-discussed, weighing product, resource, temporal, and strategic considerations against one another. As a result, the team spends energy not on execution but on priority alignment—especially painful for complex and saturated projects.
To avoid this, it is useful to assign an administrator of the current segmentation. This is not a new position, but a role—often temporary and combined. This participant is responsible for maintaining the chosen segmentation basis and coordinating it with higher-level criteria, helping the team preserve decision consistency.
The principle of tolerant hierarchy and the principle of respect for criteria do not contradict each other—they complement one another. The first defines a space of permissible flexibility, allowing different segmentation types at different project levels. The second introduces local rigidity, requiring a conscious choice and consistent adherence to a criterion within a specific scheme. As a result, hierarchy determines where different approaches are possible, while criteria determine how decisions are made locally—keeping the project flexible overall and predictable in detail.
3. The Principle of End-to-End Segmentations
If a particular type of segmentation appears at least once in every branch of a project’s temporal structure, it forms an end-to-end segmentation. In this case, the chosen criterion is maintained throughout the project and remains stable from start to finish.
Top-level segmentation is end-to-end by default: it defines the overall management contour and does not disappear as the project evolves.
Additional end-to-end segmentations at lower levels are particularly valuable. They ensure continuous process manageability across the entire project, eliminating breaks in decision logic. If such segmentation is based on a specific project methodology, its mechanisms can be applied consistently without fear that temporal or structural gaps will undermine coherence.
In the “classical / agile” example, both segmentations are end-to-end. This means the project can simultaneously—and with minimal constraints—employ both the full functionality of classical PMBOK methodologies and Scrum tools. The methodologies do not interfere with one another because each is continuously supported throughout the project.
In practice, the opposite situation is common: a methodology is applied only locally, in isolated project sections. A typical example is Scrum used solely during development, while high-level planning, dependency management, and reporting remain waterfall-based. The project is formally declared “agile,” but outside of sprints the rhythm is lost, transparency declines, and responsibility becomes blurred. The issue here is not the combination of approaches, but the lack of continuity: no methodology is supported end-to-end.
Local segmentations themselves are often useful and justified. They allow specific tools and techniques to be applied where appropriate, without restructuring the entire project. However, their presence does not justify relying on a methodology as a holistic management system. In such cases, mechanisms operate fragmentarily and fail to form a stable decision-making framework across the project.
Multiple end-to-end segmentations also make it possible to separate roles. One methodology may be leading—used for day-to-day work and operational decisions—while another remains reporting-oriented, used to present project progress to clients or stakeholders. This separation adds flexibility without compromising management integrity.
Such possibilities, however, require caution. Multiple end-to-end segmentations can both simplify management and introduce confusion through duplicated accounting and overlapping roles. Therefore, priorities must be clearly defined in advance and consistently maintained.
4. The Principle of Encapsulation
Each project segment must have clearly defined entry conditions, completion criteria, and a result evaluation procedure. Risks associated with the chosen segmentation method must be localized within the segment and not propagate across the entire project.
From this follows an important constraint: each base project activity may belong to only one lowest-level segment. This rule ensures logical consistency and prevents double inclusion, where the same work is accounted for in multiple management contours.
A change in segmentation scheme or leading criterion should be formalized as a separate reporting activity. It marks the transition point and ensures data continuity. Upon its completion, all project participants must clearly understand that execution priorities have changed.
Boundary activities naturally become project-wide review points. These are the appropriate moments for global decisions critical to future progress. Making fate-defining decisions in the middle of a production cycle should be avoided: perspective is inevitably narrowed, and strategic judgments are easily replaced by tactical considerations.
Explicitly fixing transitions makes the segmentation structure adaptive to project dynamics without destroying analytical comparability and while preserving continuity of management contours.
In practice, violating the encapsulation principle looks like this: the same work simultaneously belongs to multiple project segments. A task is considered completed in one contour, ongoing in another, and revised in a third. Reporting diverges, schedules drift, and when a problem arises, it becomes impossible to determine precisely where and why it originated. As a result, the team spends effort not on fixing the issue but on reconstructing a coherent picture of events.
A marginal note. There is often a temptation to formalize boundary activities as project milestones. However, segmentation and milestones are different mechanisms and should not be conflated.
Segmentation serves as an internal tool for structuring the project and managing its logic, while milestones reflect external temporal reference points and control checkpoints. They are best used together—but not substituted for one another.
5. The Principle of Limiting Overlaps
Segments, like real work itself, may have fuzzy boundaries—this is a natural state of complex projects. Partial overlap between segments is acceptable, but as cumulative overlap increases, planning quality and project manageability inevitably decline.
Launching a new management contour before completing the previous one sharply increases the load on managerial competence. At this point, the risk of losing control arises: attention scatters, priorities mix, and decisions may begin to distort already achieved objectives.
At the same time, overlaps should not be avoided at all costs. They are acceptable if introduced consciously and accompanied by an understanding of the associated risks. The management task here is not to eliminate overlaps as such, but to control their scale and consequences.
The Segmentation Code
As a summary, we can formulate five fundamental principles of project segmentation:
- The principle of tolerant hierarchy — defines a flexible project architecture.
- The principle of respect for criteria — establishes execution discipline.
- The principle of end-to-end segmentations — ensures continuity of management.
- The principle of encapsulation — localizes and limits risks.
- The principle of limiting overlaps — accounts for unavoidable uncertainties.
These principles demonstrate that segmentation is a full-fledged project management instrument, capable of effectively controlling execution policy for projects of any nature and scale. Any project can be examined through the lens of segmentation to identify violations of these principles—both to prevent potential errors and to analyze those already made.
The particular value of this approach lies in its compatibility with existing project management methodologies. It allows them to be applied without contradicting segmentation logic. In the next article, we will move from principles to segment theory and examine how this framework can be formalized and applied in practice.