The Tower of Babel of predictive methodologies: a comparative analysis of project lifecycle terminology

17/3/2026
etapa o fase terminologia del ciclo de vida del proyecto

Introduction

In the field of project management, terminological accuracy is a fundamental element for effective communication between professionals and organisations. However, a detailed analysis of the main predictive methodologies reveals significant discrepancies in the use of seemingly equivalent terms, particularly with regard to the components of the project life cycle. This article examines how four of the most influential methodologies — PMBOK (6th edition), PRINCE2 (7th edition), PM² (3rd edition) and P3.express — define and employ the concepts of stage and phase, highlighting the need for a critical approach when working in multi-methodological environments.

This analysis is based on a comprehensive review of the official documentation for each methodology, supplemented by the reference framework provided by ICB 4 (IPMA’s International Competence Baseline), which offers clear conceptual distinctions that serve as a benchmark for the comparative analysis.

1. PMBOK: Terminological Equivalence

The PMBOK® Guide (6th edition), published by the Project Management Institute (PMI), takes a unique stance by using the terms stage and phase interchangeably, treating them as effective synonyms. This approach is evident in numerous sections of the document.

In section 1.2.4.3, the PMBOK defines the phase review point as ‘a review point that occurs at the end of a phase’, and subsequently states that ‘phase transition points may be known by other terms such as phase review, stage transition…’ (PMI, 2017). This wording explicitly treats both terms as functionally equivalent.

Section 1.5 of the PMBOK states that ‘the project life cycle is the series of phases a project goes through from inception to completion’, defining a project phase as ‘a set of logically related project activities that culminates in the completion of one or more deliverables’ (PMI, 2017). This definition is reiterated in Section 3 (Definitions), confirming terminological consistency throughout the document.

It is worth noting that, whilst the PMBOK predominantly uses the term phase, it explicitly acknowledges that the term stage may be used with the same meaning in different organisational contexts. The PMBOK states that ‘phases may be sequential, iterative, or overlapping’ (PMI, 2017), a characteristic that is significant when compared with other methodologies.

2. ICB 4: The distinguishing framework

The International Competence Baseline 4.0 published by the IPMA (International Project Management Association) establishes a clear and rigorous conceptual distinction between stage and phase, providing specific distinguishing criteria that are essential for understanding the positions of other methodologies.

2.1. Project stage

ICB 4 defines a project phase as ‘a period within a project, distinct from other periods, with a predetermined deliverable and concluded by a go/no-go decision’ (IPMA, 2015). The defining characteristic is that project phases must not overlap. Each phase concludes with a decision gate where the sponsoring organisation must explicitly authorise the continuation of the project.

ICB 4 states that a project must consist of at least two stages: the definition stage (where the basis of the project is established) and the delivery stage (where the product or service is developed). The delivery stage may be subdivided into multiple successive stages depending on the level of control the organisation wishes to exercise.

2.2. Project phase

By contrast, ICB 4 defines project phase as ‘a period within a project with its own characteristics and a predetermined output’ (IPMA, 2015). The critical distinction is that project phases may overlap. Phases represent technical aspects of the work (e.g. engineering, tendering, construction) and culminate in milestones, not in authorisation decision points.

ICB 4 clarifies that ‘project phases may coincide with project stages, but need not necessarily do so’ (IPMA, 2015), thereby establishing a clear separation between the management components (stages) and the technical components (phases) of the project life cycle.

3. PRINCE2: Management by Stages as a fundamental principle

PRINCE2® (PRojects IN Controlled Environments), in its seventh edition, adopts an approach that bears notable conceptual similarities to ICB 4, although it uses its own terminology. The principle of Management by Stages is one of the seven fundamental principles of the methodology.

3.1. 3.1. Management Stages

PRINCE2 states that ‘a PRINCE2 project is planned, monitored and controlled stage by stage’ (AXELOS, 2017). At a minimum, every PRINCE2 project must have two management stages: the Initiation Stage and at least one Delivery Stage.

The management stages in PRINCE2 define when the Project Board (the project’s governing body) makes decisions, establishing formal control and authorisation points. At the end of each stage, there is an End Stage Assessment where the Project Board reviews performance, approves the plan for the next stage, and decides whether to continue, modify or close the project (AXELOS, 2017).

3.2. 3.2. Technical Stages

PRINCE2 draws a critical distinction between management stages and technical stages. Technical stages define how the product is built (requirements, design, development, testing, deployment) and may overlap with multiple management stages. Crucially, technical stages do not determine the project’s decision points.

A software project, for example, may have three management stages but five technical phases spread across those management stages. This conceptual differentiation is equivalent to the distinction between stages and phases proposed by ICB 4, although PRINCE2 consistently uses the term ‘stage’ for both concepts, differentiating them by the qualifiers ‘management’ and ‘technical’.

3.3. 3.3. Structural characteristics

PRINCE2 employs a hierarchical, tiered planning approach: the Project Plan provides a high-level overview, whilst each stage has a detailed Stage Plan. Significantly, only the current and next stages are planned in detail, thereby maintaining flexibility in the face of changes in the project environment (AXELOS, 2017).

This approach of phased resource commitment contrasts with methodologies that plan the entire project at the outset, providing regular go/no-go decision points based on up-to-date information on project performance.

4. PM²: Terminological inconsistencies and limited use of stages

The PM² (Project Management Methodology) methodology, developed by the European Commission in its third edition, presents an approach based on four main phases and exhibits terminological inconsistencies in the use of the concepts of ‘stage’ and ‘phase’.

4.1. 4.1. Phase structure

The PM² life cycle comprises four sequential, non-overlapping phases: Initiating, Planning, Executing and Closing. Monitoring and Controlling activities are presented as cutting across all four phases (European Commission, 2018).

PM² states that ‘a project moves to the next phase when the objectives of the current phase are deemed to have been achieved, following a formal (or less formal) end-of-phase review’ (European Commission, 2018). This feature of reviews at the end of each phase to decide on the continuation of the project is consistent with the concept of stage according to ICB 4.

4.2. 4.2. Inconsistencies in the glossary

Appendix G (Glossary) of PM² contains definitions that give rise to conceptual confusion:

  • Stage: ‘A stage is a point, period or step within a phase (primarily the Execution Phase) and is linked to a significant milestone in terms of project outcomes. It is primarily used in agile project management” (European Commission, 2018).
  • Project phase: “PM² has four phases: Initiation, Planning, Execution and Closure. Monitoring and Control activities span all four project phases” (European Commission, 2018).
  • Breakdown by stages: “describes a technique used to represent and organise project work into sequential phases or stages/iterations” (European Commission, 2018).

These definitions are problematic. On the one hand, the definition of stage subordinates it to a phase (“period or step within a phase”), reversing the conceptual hierarchy proposed by ICB 4. On the other hand, the definition of Stage Breakdown uses “sequential phases or stages” as equivalent terms, contradicting the previous definition.

4.3. 4.3. Critical Analysis

In practice, PM² predominantly uses the term phase to refer to the main components of its project lifecycle, and these phases function conceptually as stages as defined by ICB 4: they are sequential, do not overlap, and conclude with reviews that determine whether the project should continue.

The term stage has marginal use in PM², being limited mainly to agile contexts within the execution phase. It appears that insufficient attention has been paid to the rigorous differentiation of these terms, resulting in conceptual inconsistencies that may cause confusion in professional settings.

5. P3.express: The neutral approach using activity groups

P3.express adopts a distinctive strategy by completely avoiding the terms stage and phase, opting instead for neutral terminology based on activity groups and cycles.

5.1. 5.1. Structure of activity groups

The project lifecycle in P3.express consists of seven activity groups (P3.express, 2023):

  • Project initiation: An initiation activity group carried out at the start of the project.
  • Project execution: Four cyclical activity groups —Monthly kick-off, Weekly management, Daily management and Monthly closure— which are carried out iteratively during the project’s execution.
  • Project closure: Closure activity group carried out at the end of the project.
  • Post-project management: Post-project activity group for measuring benefits.

5.2. 5.2. Cyclical system

P3.express uses a cyclical system comprising monthly, weekly and daily cycles, each focusing on specific aspects of management activities. This approach differs substantially from traditional methodologies based on sequential phases or stages, adopting instead an iterative and continuous perspective.

5.3. 5.3. Advantages of the neutral approach

By avoiding the terms stage and phase, P3.express eliminates the terminological ambiguity found in other methodologies. This decision is particularly appropriate given the methodology’s lightweight approach, designed for small and medium-sized projects that require simplified management structures.

However, the absence of these terms also means that professionals familiar with PMBOK, PRINCE2 or PM² must adapt their conceptual vocabulary when working with P3.express, which may present an initial barrier to adoption.

6. Comparative analysis: similarities and differences

An analysis of the four main methodologies reveals significant patterns of similarity and difference in the terminological treatment of the components of the project life cycle.

6.1. 6.1. Conceptual convergence: ICB 4 and PRINCE2

ICB 4 and PRINCE2 demonstrate the greatest conceptual consistency, sharing a fundamental distinction between management components and technical components:

  • ICB 4: distinction between stages (management components, non-overlapping) and phases (technical components, overlapping).
  • PRINCE2: distinction between management stages (non-overlapping) and technical stages (overlapping).

Both methodologies emphasise that management components conclude with formal decision points where the continuation of the project is authorised (or not), whilst technical components culminate in milestones with no authorisation implications.

6.2. 6.2. Terminological inconsistencies: PMBOK and PM²

PMBOK and PM² exhibit weaknesses in their use of terminology:

  • PMBOK: uses stage and phase as synonyms, missing an opportunity to distinguish between management components and technical components. This lack of distinction can prove problematic in complex projects where a conceptual separation would be beneficial.
  • PM²: predominantly uses phase for its main components (which function as management stages), whilst relegating stage to marginal use with inconsistent definitions in its glossary.

In both cases, insufficient attention has been paid to the rigorous differentiation of these terms, which may lead to ambiguity in environments where multiple methodologies coexist.

6.3. 6.3. The neutral alternative: P3.express

P3.express takes a distinctive approach by completely avoiding the stage-phase dichotomy, opting instead for neutral terms (activity groups, cycles). This approach eliminates terminological ambiguity and is consistent with its lightweight philosophy, although it requires a shift in thinking on the part of professionals trained in other methodologies.

7. Conclusions

A comparative analysis of project lifecycle terminology across the main predictive methodologies reveals a significant lack of standardisation, which may have a negative impact on communication between professionals and organisations.

7.1. 7.1. Key findings

First finding: there is a fundamental divide between methodologies that make a conceptual distinction between management and technical components (ICB 4, PRINCE2) and those that do not make this distinction (PMBOK, PM²).

Second finding: ICB 4 provides the most rigorous and differentiated conceptual framework, establishing clear criteria to distinguish between stages (non-overlapping, concluding with authorisation decisions) and phases (overlapping, culminating in milestones).

Third finding: PRINCE2 shares the conceptual approach of ICB 4, although it uses its own terminology (management stages vs. technical stages), demonstrating that the same conceptual approach can be expressed using different nomenclatures.

Fourth finding: Neither PMBOK nor PM² has developed a rigorous terminological distinction, using the terms as synonyms (PMBOK) or inconsistently (PM²), which represents a methodological weakness.

Fifth finding: P3.express offers a pragmatic solution to the terminological problem by adopting neutral terms, although this decision entails adaptation costs for professionals familiar with traditional terminology.

7.2. 7.2. Professional implications

For project management professionals, these terminological differences pose significant practical challenges:

  • Multi-methodological communication: in organisations where multiple methodologies coexist, it is essential to establish explicit agreements on the meaning of key terms to avoid misunderstandings.
  • Training and certification: training programmes must explicitly highlight these terminological differences to ensure professionals are adequately prepared.
  • Project documentation: when documenting projects, it is advisable to include a glossary that explicitly defines how these terms are used in the specific context.
  • Methodology selection: the choice of a methodology must consider not only its technical characteristics, but also its terminological clarity and its compatibility with existing organisational vocabulary.

7.3. 7.3. Recommendations


Based on this analysis, the following recommendations are proposed:

For organisations: develop a corporate glossary of project management terms that establishes standard definitions, regardless of the methodologies used internally. This glossary should preferably be based on the ICB 4 conceptual framework due to its greater precision in distinguishing between concepts.

For professionals: adopt the conceptual distinction between management components (authorisation decision points) and technical components (progress milestones), regardless of the specific terminology used by each methodology.

For methodology developers: pay greater attention to internal terminological consistency and conceptual interoperability with other established methodologies, recognising that terminological clarity facilitates adoption and reduces the risk of misunderstandings.

7.4. 7.4. Concluding remarks

The terminological diversity analysed in this article is not merely a semantic issue, but reflects fundamental conceptual differences in how methodologies structure and manage projects. Whilst ICB 4 and PRINCE2 explicitly recognise the need to differentiate between management and technical components, PMBOK and PM² omit this distinction, which may limit their effectiveness in complex projects where such a separation is essential.

In an increasingly globalised and multi-methodological professional context, the project management community would benefit from a conscious effort towards greater terminological harmonisation, without necessarily sacrificing the distinctive characteristics of each methodology. The adoption of the ICB 4 conceptual framework as a common reference could constitute a significant step in this direction.

Ángel Águeda Barrero


References

AXELOS. (2017). Managing Successful Projects with PRINCE2® 6th Edition. TSO (The Stationery Office).

European Comission (2018). PM² Project Management Methodology Guide 3.0. Publications Office of the European Union.

IPMA (International Project Management Association). (2015). Individual Competence Baseline for Project, Programme & Portfolio Management, Version 4.0.

P3.express. (2023). P3.express Manual, Version 2. Available here: https://p3.express/es/manual/v2/

Project Management Institute. (2017). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition. Project Management Institute.

Share