Abstract

Over the course of the last hundred years, project management has undergone significant changes and continues to evolve, similar to several other concepts and careers. In recent times, various factors, such as the requirement for specialised skills and the rapid pace of innovation, have led to a substantial surge in the need for project management experts.

As the evolution progressed, it brought about several challenges, including the global agreement on the various definitions and terminology used. The project management field is flooded with numerous technical jargons, making it perplexing and leading people astray during project implementation. Moreover, certain misconceptions are adversely affecting other professions and career choices.

The objective of this research is to dispel misunderstandings about crucial project management terms and their definitions. It aims to accurately place these terms and facilitate a comprehensive global understanding of their meanings. By establishing a clear and consistent understanding of these fundamental terminologies, instructors and professionals alike can enhance their performance and ultimately elevate the project management industry.

This research does not create anything new but instead concentrates on the precise significance of the terminologies and phrases employed. It extracts the real meaning from numerous reliable sources, including the definitions and terminologies used by esteemed project management institutions and respected English language dictionaries.

To ensure that this study is useful, trustworthy, and coherent, I will commence by defining the key terms that gave rise to the concept of project management. Following this, I will delve into more intricate terminology. For each term, I will present definitions from various reputable sources and provide my analysis, opinions, and recommendations for potential revisions.

The Terminologies that this paper discusses in the context of project management are:  Project, Project Management, Project Management life cycle, project management approaches, Project Management Methodology, Project Management Framework, Project Management Delivery Method.

Keywords: project management, methodology, framework, delivery method, project management life cycle

1.   Introduction: The Crisis of Terminology

1.1. The Problem Statement

The project management profession faces a significant challenge: terminology chaos. Terms like “methodology,” “framework,” “agile,” and “Scrum” are used interchangeably without precision, creating:

1. Confusion during implementation – Teams misunderstand what they’re adopting
2. Professional dilution – Non-professionals exploit vague terminology for marketing
3. Ineffective project execution – Wrong tools applied to wrong contexts
4. Certification confusion – Conflicting definitions across institutions

1.2. Research Objective

This research does not aim to create new concepts but rather to:

• Extract precise meanings from authoritative sources
• Establish logical classification criteria based on linguistic and practical definitions
• Challenge existing misclassifications, particularly regarding Scrum
• Propose a unified taxonomy for the project management community

1.3. Methodology

This study employs:

• Comparative analysis of official definitions from PMI, ISO, AXELOS, Scrum.org
• Linguistic analysis from authoritative English dictionaries
• Logical reasoning based on stated characteristics
• Critical evaluation of internal contradictions in official documentation

2.   Foundational Concepts

Let’s first explore the true essence of the words that constitute the term “project management” before delving into the core of this research.

2.1. Project

• According to PMI, a project consists of a temporary initiative in a unique context undertaken to create value[1]

• ISO defines a project as a “temporary endeavor to achieve one or more defined objectives.[2]

• Axelos defines a project as “a temporary venture that exists to produce a defined outcome that leads to the achievement of intended benefits (value).[3]

It is evident that each of the respective bodies has agreed on the primary definition of the project, even though they have used different terminologies. Ultimately, they have led us to identify and agree upon the concept that a project should be considered “unique, temporary, and composed of a series of structured tasks and activities.”

2.2. Project Management

Now let’s see how these respected and well-known bodies define “project management “

• PMI defines project management as “the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.” [4]

• The Association for Project Management (APM) defines project management as “the process by which projects are defined, planned, monitored, controlled, and delivered such that the agreed benefits are realized.”[5]

• The International Project Management Association (IPMA) defines project management as ” the application of knowledge, skills, tools, and techniques to project activities to meet project requirements.” [6]

After agreeing on a definition for project management, respected bodies have not presented any differing definitions, and other respected project management bodies also adhere to this same definition.

Based on the commonly accepted definition of project management, we can say that it involves the planning, performing, monitoring, and controlling of all aspects of a project in order to achieve its objectives.

2.3. Project Management Life Cycle

The project management life cycle was developed to manage projects efficiently. It was realized that just defining the concept of project management was not enough. Therefore, a structured approach was required, leading to the birth of the life cycle concept. This concept and representation of the project’s life cycle were created before the development of any project management methodologies or frameworks. It has evolved through the years to have the final and widely agreed-upon definition.

• The Project Management Institute (PMI) defines the project management life cycle as “the series of phases that a project passes through from its initiation to its closure.” [7]

• The Association for Project Management (APM) defines the project management life cycle as “a framework comprising a set of distinct high-level stages required to transform an idea of concept into reality in an orderly and efficient manner.” [8]

Other project management bodies typically adhere closely to the definitions of the project management life cycle provided by organizations like PMI and APM

3.   Project Management Lifecycle Approaches

The world has made tremendous progress in recent decades, leading to significant changes in project management. Consequently, it has become necessary to develop new approaches that can be adapted to the nature of modern projects. At first, there was only one approach available, the predictive or linear approach. However, as time went by, the adaptive approach was introduced to cater to projects where adapting the linear approach was not feasible.

We have seen tremendous progress in recent times, resulting in the evolution of more accurate approaches from the heart of the predictive approach. These approaches include the (predictive iterative approach ) and (the predictive incremental approach). Additionally, some project management bodies consider the hybrid approach the 3^rd  type of project management lifecycle approach.

Broadly speaking, we can categorise lifecycle approaches into three types:

• Parallel (Adaptive)
• Sequential (Predictive)
• Mixed (Hybrid)

The adaptive approach itself includes two subtypes: incremental and iterative.

Up until now, I refrained from discussing project management methodologies or frameworks as I wanted to focus solely on the fundamental principles of project management in its most basic and purest form. My objective here is to eliminate any confusing jargon or buzzwords that have emerged as trends in the project management universe, but have no actual added value. These terms are often used to add more drama and for marketing purposes only. Unfortunately, many experienced project managers and respected project management institutions fall into this trap.

The aforementioned sections, though fundamental, serve as the foundation for my method of assessing and appraising incorrectly utilized terms and definitions such as methodology, framework, agile, and other terms that are intentionally or unintentionally misinterpreted in a way that harms the reality of project management.

By this way, we clear up the confusion that often surrounds the Agile vs. Waterfall debate. Why? Because now Waterfall, as a methodology, clearly belongs to the predictive (sequential) approach, while Agile, as a mindset, philosophy, and set of principles, aligns with the adaptive (parallel) approach. This distinction helps professionals avoid mixing delivery methods with management philosophies and provides a common language for discussing project lifecycles worldwide.

“It is important to note that the concept of the predictive approach originated long before Agile.”

4.   Core Distinctions: Methodology vs. Framework

As human beings, we have a natural inclination towards creating boundaries and rules, but we also enjoy breaking them. Our brains are wired to process structured data more effectively, which is why simply developing approaches is not enough for efficient project implementation. Thus, we have created methodologies and frameworks to systematize our approaches and help us implement projects more effectively.

We achieved great things by developing reliable methodologies and frameworks that became essential references for us as project managers. However, some approaches or tools were marketed and used as project management methodologies and frameworks, even though they were vastly different from the true meaning of project management. To uncover these misused approaches, we need to first understand the real meaning of methodology and framework.

4.1. Linguistic Foundations

 

Methodology – Dictionary Definitions:

• Merriam-Webster: “A body of methods, rules, and postulates employed by a discipline”
• Oxford Languages: “A system of methods used in a particular area of study or activity”
• Cambridge Dictionary: “A system of ways of doing, teaching, or studying something”

Framework – Dictionary Definitions:

• Merriam-Webster: “A basic conceptual structure (as of ideas)”
• Oxford English Dictionary: “An essential supporting structure around which something is built or developed”
• Cambridge Dictionary: “A supporting structure around which something can be built”

From the definitions provided above, it is evident that the methodology revolves around the system. It emphasizes defining the system, which makes it less flexible than a framework. A framework, on the other hand, provides general boundaries for doing something, while a system focuses on performing tasks in a very structured manner.

In my opinion, it is crucial to establish a common understanding and use unified terminology when discussing a concept. Failure to do so can result in incorrect implementation and usage of the said concept. Therefore, it is imperative for the project management community to agree on a clear definition of what goes under project management methodology, what goes under project management framework, and what cannot be considered as project management methodology or framework.

The methodology cannot be modified. It must be implemented correctly or not at all. On the other hand, the framework can be used and implemented in various ways, as long as we stay within the boundaries of the framework.

Key Concept: Methodology revolves around SYSTEM – structured, organised, sequential.

Key Concept: Framework provides BOUNDARIES – flexible structure, adaptable implementation.

4.2. Practical Distinctions

Characteristic	Methodology	Framework
Nature	System of methods	Conceptual structure
Flexibility	Low – must follow prescribed steps	High – adaptable within boundaries
Implementation	“As-is” or not at all	Multiple valid implementations
Modification	Not permitted or severely limited	Encouraged (tailoring)
Prescription	Detailed, step-by-step	General guidance, principles
Completeness	Self-contained execution path	Requires additional tools/methods

Table 1

4.3. The Golden Rule for Classification

For any approach to be considered a Project Management Methodology or Framework, it must:

1. Cover all aspects of the project management life cycle (Initiation → Closing)
2. Address all critical knowledge areas:

• Scope Management
• Schedule Management
• Cost Management
• Quality Management
• Resource Management
• Communications Management
• Risk Management
• Procurement Management
• Stakeholder Management
• Integration Management

If it doesn’t meet these criteria, it cannot be classified as a comprehensive project management methodology or framework.

“While project management schools differ in their approaches to these knowledge areas, all acknowledge them as critical domains that every project must address.”

4.4. Validated Examples

• PRINCE2 – Comprehensive Project Management Methodology( h

Classification: Methodology ✓

Rationale:

• Defines 7 processes in sequential order
• Prescribes 7 principles (mandatory)
• Specifies 7 themes covering all PM aspects
• Provides detailed, step-by-step execution
• Covers entire project life cycle
• Limited tailoring permitted within strict boundaries

Scope: Comprehensive Project Management

• PMBOK Guide – Project Management Framework

Classification: Framework ✓

Rationale:

• Provides Knowledge Areas (boundaries)
• Defines Process Groups (structure)
• Does NOT prescribe specific execution sequence
• Encourages tailoring and adaptation
• Offers guidance, not rigid procedures
• Compatible with multiple delivery methods

Scope: Comprehensive Project Management

Building on this, we can implement the same reasoning to distinguish between a project management methodology and a framework.

5.   Delivery Methods

This word appears frequently in project management and product management publications. It is an extremely significant phrase that must be utilized appropriately in project management. In my opinion, we may think of this phrase like a vehicle’s engine: the vehicle’s body cannot move without the engine, similarly the project management framework needs a delivery mechanism to produce project outputs and objectives. On the other side, the project management methodology has its own integrated delivery system. This highlights the necessity of differentiating between the PM framework and methodology.

This example may help clarify things: Scrum, as a project management delivery method, may be used with the framework PMBOK guide to carry out a project; however, it cannot be used with PRINCE II since PRINCE II is a methodology with its own delivery system.  Later in this paper, you’ll learn how and why I believe Scrum is a project management delivery method.

6.   Neither a Methodology nor a Framework

As I mentioned at the beginning, the main reason behind this paper is to invite the project management community to discuss and reach an agreement on the main terminologies used in project management and to clarify any misunderstandings about them. In my opinion, based on my experience as a project manager and considering all the points mentioned above, I can clearly state that the following methods or terms are not project management methodologies or frameworks.

Although it’s not possible to list all terms and methods here, I will present the most notable ones and allow readers to assess the others themselves.

6.1. Agile

I’ll start with the most contentious terminology, those that have grown popular and were formerly considered an appealing title in project management universe.

We can’t separate the phrase from the context in which it’s used, and we’re talking here about Agile in project management.

The issue with this term is as follows:

• Miscommunication and misinterpretation
• Incorrect usage and adaptation
• Non-professionals might deceive the community by generating meaningless titles, courses, and other content.
• Considered it a project management magic stick.

Return to history. The term “Agile” was first used in the context of software development in the early 2000s, and it has since spread to other fields such as project management and business. The challenge is that this expansion occurred without any significant study, research, or substantial initiatives, such as when the Manifesto for Agile Software Development was first drafted. My argument is that Agile Software Development took on its ultimate form and name when 17 software development practitioners assembled to discuss a better way to perform software development. In contrast, in the project management and business sphere, this did not happen. When Agile spread as a concept and started to be a trend in the business world, everyone started to make his interpretation and contribution, which produced a messy environment and a lot of abuse.

Agile is best understood as a set of concepts, a philosophy, and a collection of guiding principles. From this perspective, the correct term in project management is the Agile approach, rather than Agile methodology or Agile framework. The Agile approach encompasses various methodologies, frameworks, and delivery methods that align with Agile philosophy.

Building on that, I believe that framing the discussion as Agile versus Waterfall is a false argument, since we cannot compare a philosophy with a methodology. A more meaningful comparison would be Scrum versus Waterfall, as Scrum is a concrete methodology that operates within the Agile philosophy.”

Also, it is critical to distinguish between project management and software development. These are two distinct areas; certain concepts may cross; therefore, we need to place them in the appropriate context. 

6.2. Scrum

Scrum Guide (2020) states:

“Scrum is a lightweight framework that helps people, teams, and organisations generate value through adaptive solutions for complex problems.”

However, the same guide also states:

“The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety…”

6.2.1.  The Fundamental Contradiction

This presents a logical impossibility:

• If Scrum is a Framework → It should be flexible and adaptable
• But Scrum is Immutable → It cannot be modified
• Immutability is a defining characteristic of Methodology → Not Framework

Conclusion: Scrum’s own documentation contradicts its classification.

 

6.2.2.  Evidence-Based Reclassification

1. Scrum should be regarded as a methodology, not a framework. This viewpoint is based on the definition of methodology in English dictionaries, as well as the Scrum Guide, which specifies that Scrum should be executed as a whole. In methodology, there is no place for the invention or implementation of different approaches; you must utilize them as they are. It is a system that you either love it or leave it. A framework, on the other hand, gives you the freedom to experiment and create new ideas within its constraints. According to the guide, modifying Scrum means that it is no longer Scrum.

2. Scrum is a software development methodology that differs from project management. The official Scrum guide does not refer to it as a project management methodology or framework. It is commonly acknowledged that software development is a distinct area from project management; hence it cannot be maintained that software development is project management.

3. Project management requires a project manager. Although some may claim that the presence of a project manager is unnecessary because a product owner and scrum master can do the job, this is not true. A product owner or scrum master cannot be expected to have the qualifications, education, and skills that a project manager does. As a result, it is critical to recognize and respect the particular contributions that project managers may provide to a project.

4. In project management, I execute Scrum as a delivery method. This strategy is utilized in conjunction with additional tools we employ to manage our projects.

5. Scrum does not cover all areas of the project management life cycle. You may check the official Guide to ensure it doesn’t.

I won’t go into all of the claimed project management methodologies or frameworks in-depth, but I will identify a few Of them, and the reader may apply the same logic we used here in this paper to discern.

6.3. Kanban

One of the best sources for information about Kanban is David J. Anderson’s book “Kanban: Successful Evolutionary Change for Your Technology Business.” The book states unequivocally that Kanban is “a method for managing knowledge work and controlling the flow of work items in a process.” It emphasizes incremental improvements to systems and processes and encourages collaboration, transparency, and flexibility.”

So how come some people still refer to Kanban as a project management methodology!!!

6.4. Critical Path Method (Tool)

The first significant publication detailing the Critical Path Method appeared in the mid-1950s. Kelley and Walker’s fundamental publication, “Critical-Path Planning and Scheduling,” appeared in the journal Operations Research in 1959. I won’t go into detail about the study, but the title indicates that the CPM is a tool rather than a methodology or framework. I was surprised when I searched for PM methodologies and saw the CPM on the list. CPM is a tool, like other tools, that we employ to work on various aspects of the project. We use CPM to plan and schedule tasks utilizing the Critical Chain Method (Tool).

6.5. Critical Chain Method (Tool)

The same rationale applies, except that the CCM imposes more limits than the CPM.

6.6. Lean Philosophy

Lean is not a project management approach or framework. It is a well-organized, straightforward, structured approach that originated in the early twentieth century and has continued to evolve. The finest reference for Lean is the book “The Machine That Changed the World” (1990), by Womack, Jones, and Roos. They invented the word “Lean” to characterize the concepts and practices they witnessed in the car industry, notably at Toyota.

6.7. Six Sigma

I don’t understand why some people mention Six Sigma as a project management methodology. Six Sigma is a data-driven technique for increasing process quality via the identification and elimination of flaws and variances. In the context of project management, Six Sigma and Scrum, in my opinion, should be classified as delivery methods.

7.   Proposed Unified Taxonomy

 

Figure 1

8.   Practical Implications

8.1. For Project Managers

Understanding these distinctions enables:

1. Better Tool Selection

• Choose the right tool for the right job
• Avoid expecting Scrum to do what it wasn’t designed for

2. Proper Integration

• ✓ Combine Framework + Limited-Scope Methodology (e.g., PMBOK + Scrum)
• ✗ Avoid combining competing Methodologies (e.g., PRINCE2 + Scrum)

3. Clear Communication

• Set accurate expectations with stakeholders
• Avoid terminology confusion in project documentation

8.2. For Organisations

Benefits of accurate classification:

1. Training Programs: Teach the right content in the right context
2. Certification Paths: Guide professionals toward appropriate credentials
3. Tool Implementation: Deploy approaches that actually fit organisational needs
4. Vendor Selection: Evaluate consultants based on an accurate understanding

8.3. For the PM Profession

Achieving terminology consensus:

1. Professional Credibility: Reduces amateur exploitation of vague terms
2. Educational Standards: Enables consistent curriculum development
3. Research Foundation: Provides a basis for empirical studies
4. Global Understanding: Facilitates international collaboration

9.   Final statement:

This research does not diminish Scrum, Agile, or any other approach. Rather, it seeks to place each tool in its proper context, enabling professionals to use them more effectively. Accurate terminology is not pedantry – it is the foundation of professional practice.

The project management community must decide: Will we continue to accept convenient fictions, or will we commit to the precision our profession deserves?

References

• Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Blue Hole Press.

• Association for Project Management. (2019). APM body of knowledge (7th ed.).
• Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., … & Thomas, D. (2001). Manifesto for Agile Software Development. https://agilemanifesto.org/
• International Project Management Association. (2015). IPMA individual competence baseline (Version 4.0).
• (2021). ISO 21500:2021 – Project, programme and portfolio management – Context and concepts. https://www.iso.org/standard/74947.html
• Kelley, J. E., & Walker, M. R. (1959). Critical-path planning and scheduling. Operations Research, 7(6), 347–360.
• Merriam-Webster. (n.d.). Methodology. In Merriam-Webster.com dictionary. Retrieved December 21, 2025, from https://www.merriam-webster.com/
• Oxford English Dictionary. (n.d.). Methodology. In OED Online. Retrieved December 21, 2025, from https://www.oed.com/
• Project Management Institute. (2021). A guide to the project management body of knowledge (PMBOK® Guide) (7th ed.).
• Project Management Institute. (2025). A guide to the project management body of knowledge (PMBOK® Guide) (8th ed.).
• Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. https://scrumguides.org/
• Womack, J. P., Jones, D. T., & Roos, D. (1990). The machine that changed the world. Free Press.
• Cambridge Dictionary. (n.d.). Methodology. In Cambridge Dictionary Online. Retrieved December 21, 2025, from https://dictionary.cambridge.org/
• (2017). Managing successful projects with PRINCE2.

Author Information: Amr Miqdadi, Project Management Professional

LinkedIn: https://www.linkedin.com/in/amrmiqdadi/

Email:      amiqdadi@pmlead.net

Website: https://www.pmlead.net

 

This paper is intended to stimulate professional discourse and welcomes constructive criticism and scholarly debate.

[1] Project Management Institute. (2017). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (8th ed.). Project Management Institute.

[2] https://www.iso.org/obp/ui/#iso:std:iso:21500:ed-2:v1:en

[3] https://www.axelos.com/certifications/prince2/what-is-project-management

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

[5] Association for Project Management. (2019). APM Body of Knowledge 7th Edition.

[6] International Project Management Association. (2015). IPMA Individual Competence Baseline, Version 4.0.

[7] A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition,” Project Management Institute, 2017

[8] APM Body of Knowledge 7th edition