There are nearly a hundred popular project management methodologies. In real projects, they rarely exist in pure form. They mix, overlap, and mutate, eventually forming management styles unique to each organization.
Over time, every company develops its own way of handling work.
When you step into someone else’s project from the outside, this becomes immediately obvious. The formal methodology rarely tells you how decisions are actually made. There is no adaptation period. You are expected to act immediately, inside an already established management flow.
In such situations, a universal way to quickly grasp how a project is really managed becomes critical. You need to recognize the underlying structure, understand the project’s internal rhythm, and decide how to move forward without disrupting what already exists.
I know this problem well. For over fifteen years, I have been developing project management applications used by thousands of people. Users regularly come to me with questions, issues, and requests. For a brief moment, I get to see their projects from the inside—how work is structured, where it stalls, and where control is lost.
To be clear: I never share user data without permission, and I remove it as soon as the issue is resolved.
Over time, this exposure gave me access to a wide range of projects—from student coursework to large corporate programs, across industries and countries. To be genuinely helpful, I needed a way to compare these projects systematically. I needed a shared lens. Surprisingly, even methodologies as different as Waterfall and Agile share more than it initially appears.
From Linear Work to Project Space
Let us start with the simplest possible project—one where management risk is minimal.
It consists of a sequential series of basic activities performed by a single qualified resource, with sufficient materials available. Attention is never split. Focus remains on one task at a time.
This is a purely linear process. A single vector. A laminar flow.
Every project manager starts here. If you cannot manage a linear process, you cannot manage complexity.
There is also a familiar archetype at the extreme end of simplicity: the zero-dimensional project. We know it from myths and fairy tales—problems solved by a single action, a magic wand, a genie in a lamp. In corporate folklore, it appears as the promise: “just press one button.” Most of us have encountered this illusion.
Real projects, of course, are nothing like that.
They contain hierarchies of tasks, multiple resources, and a dense matrix of risks. We usually visualize them using two-dimensional diagrams. Strictly speaking, these diagrams are not truly two-dimensional. As soon as dependencies cross, the diagram gains layers. Topologically, it becomes something closer to “two and a half” dimensions.
Interestingly, once you reach three dimensions, almost any project structure can be represented. Increasing dimensionality further adds little practical value.
This creates a fundamental tension. Projects exist as complex, multidimensional spaces of activity, yet humans are only good at managing linear, sequential processes.
Most project management methodologies exist to resolve this tension.
They all attempt, in one way or another, to project multidimensional work onto a sequence.
PMBOK does this implicitly, through its process groups. PRINCE2 does it explicitly, with a rigid set of mandatory management processes. Agile approaches slice the project body into iterations.
Different forms, same intent: collapse complexity into a controllable line.
I refer to these linear slices as segments. To avoid confusion with classical work decomposition, I call the process project segmentation.
One of the key differences between project management methodologies lies precisely in how they segment projects over time.
When Segmentation Follows the Project
In practice, segmentation usually starts from project goals. The structure of work naturally follows from what needs to be achieved, how it can be achieved, and under what constraints.
In large projects, work often groups itself into stages as the nature of activity changes—design, mock-ups, prototyping, production. This is product-based segmentation. It follows the structure of the emerging product.
Waterfall and the classical PMBOK / PMI tradition are built around this logic. Kanban also follows product segmentation when dealing with requirement evolution.
Resources introduce a second segmentation axis. Availability, competence, and supply timing often shape the plan more strongly than goals themselves. Harvest seasons, delivery lead times, and staffing constraints all impose structure.
This leads to resource-based segmentation, used by approaches such as the Theory of Constraints, Lean, Just-in-Time, and Kanban in its load-balancing role.
The third classical dimension is risk.
In some projects, the cost of achieving the goal is lower than the cost of ensuring safety, compliance, or regulatory oversight. In such cases, the structure of risks becomes the dominant organizing principle.
Risk-based segmentation defines control boundaries around stability and safety. PRINCE2’s management stages, each ending with a “continue or stop” decision, fit naturally here. Stage-Gate models operate in the same spirit.
Some projects require a combination of these factors. Combined segmentation blends product, resource, and risk considerations where their interaction is critical. The IPMA ICB standard reflects this breadth, though often at the expense of focus.
In practice, combined segmentation is sometimes chosen not because it is necessary, but because the team struggles to set priorities.
All of these approaches share one property: they arise from the project itself. Goals, resources, risks, and internal logic determine them. These are natural segmentations—they exist whether we acknowledge them or not.
When Segmentation Is Introduced
Artificial segmentation is more interesting.
It is introduced deliberately. It does not reflect the structure of work itself, but rather how work is organized, perceived, and coordinated.
The simplest artificial segmentation is rhythmic. Humans are good at measuring equal intervals. Rhythmic segmentation divides projects into fixed time slices—years, quarters, months, sprints—and evaluates progress at their boundaries.
Scrum and other iterative Agile approaches rely on this principle. Managerial competence in this case can be described as the product of the average number of activities that can be effectively managed simultaneously and the duration of the management period. It is easy to see that by artificially shortening the control period, we reduce the requirements for overall managerial competence and thereby gain the ability to manage projects with complex task structures.
The trade-off is cost. Short cycles increase coordination overhead. Meetings, synchronizations, and context switching become more frequent.
Research from the University of California, Irvine shows that developers need around 23 minutes to regain focus after an interruption. Excessive rhythm can erode productivity instead of improving it.
Large organizations introduce another layer. Project offices often manage multiple projects within a single program. Individual schedules become dependent on external factors—other projects, corporate initiatives, budget cycles.
Cooperative segmentation aligns project segments across projects and programs. Frameworks like SAFe synchronize teams through shared program increments and release trains. LeSS does this through common sprints and integration points. Portfolio management ties projects to shared budget and review cycles.
Here, segmentation serves coordination, not the internal logic of a single project.
Projects also serve another purpose: developing people.
Many methodologies explicitly focus on competence growth and organizational maturity. Methodological segmentation introduces stages and activities aimed at learning and improvement. Six Sigma and DMAIC place continuous improvement at the center, treating project execution as a vehicle for sustained quality growth.
Finally, projects are driven by people. Until humans are replaced, psychology and social dynamics will shape outcomes. Behavioral segmentation structures time to manage motivation, team rhythm, and perception of progress. It ranges from rituals and habits to gamification and symbolic milestones—demo days, sprint endings, or “day zero.”
External forces cannot be ignored either. Priority shifts, crises, political constraints, and regulatory pressure all intervene.
Strategic segmentation aligns internal project phases with external planning, budgeting, and oversight cycles. It includes supervisory variants where control points are imposed by standards or regulation.
What Segmentation Really Does
Temporal project segmentation structures work over time to make it manageable, comparable, and transparent. It defines the project’s temporal architecture—how activities, resources, and results align with specific segments.
Segmentation performs three functions:
- Structural: shaping the project’s temporal composition
- Analytical: enabling assessment of dynamics, load, and risk
- Managerial: aligning calendars, reporting, and control points
Segmentation can be natural or artificial. Natural segmentation follows the project’s inherent structure. Artificial segmentation adds control and coordination where competence or environment requires it.
The Map That Matters
At this point, the segmentation landscape becomes clear.
- Natural segmentations that follow the project itself:
- Product-based
- Resource-based
- Risk-based
- Combined
- Artificial segmentations introduced by management:
- Rhythmic
- Cooperative
- Methodological
- Behavioral
- Strategic
Misunderstanding segmentation has consequences. Disrupting artificial segmentation reduces controllability and focus. Disrupting natural segmentation directly damages product quality or goal achievement. Sprint dates can often move safely; technological or product boundaries rarely can.
The ideal situation is a mature team working in harmony with natural segmentation. Artificial constructs become necessary when team competence falls short of project complexity. In such cases, part of the project cost goes not into delivering outcomes, but into developing the team itself.
This has economic implications. Clients are not automatically obliged to pay for a contractor’s internal capability growth. Understanding segmentation clarifies where responsibility lies and helps separate genuine project value from internal overhead.
It can be shown that the fundamental reason for the emergence of artificial segmentations is the desire to more strictly adhere to the natural decomposition of a project. Tracing the history of project management, it is easy to notice a gradual increase in the degree of “artificiality” of segmentation in contemporary methodologies. This clearly indicates that the complexity of the projects being addressed is continuously growing, while the growth of human competencies is far less dramatic—necessitating the use of artificial compensatory mechanisms.
This article outlines a conceptual framework rather than final answers. It opens space for further analysis: the history of segmentation, criteria for choosing appropriate structures, parallel segmentation models, and even forecasts for the evolution of project management itself.
If interest persists, this introduction may grow into a series. For now, the discussion is open.