Perspectives · Standards & Practice

Clearing Up One of the Profession’s
Most Persistent Confusions.

Somewhere up there, Bill Duncan is smiling. I channeled my inner Duncan while writing this.

Search the internet for “project management methodologies” and a familiar list appears: Agile, Waterfall, Scrum, Kanban, Lean, Six Sigma, Critical Path Method. Sometimes even A Guide to the Project Management Body of Knowledge (PMBOK Guide) is included. Most of those are not methodologies. They are useful practices, tools, frameworks, or philosophies. But they do not define how projects are governed. When they are described as methodologies, several different types of project practices get collapsed into a single category. Organizations then try to run projects using tools that were never designed to provide governance or decision structure.

This article covers three things:

The Structural Problem

Project work happens inside layered systems. At the top are governance structures that determine how decisions are made. Beneath them are delivery systems that determine how work is executed. Supporting those are frameworks, tools, and improvement practices. When those layers are confused, people begin describing any recognizable practice as a “methodology.” Over time the word becomes a marketing term rather than a structural one.

Several forces perpetuate this confusion:

What a Project Management Method Actually Is

A project management method is a complete system for governing and executing projects. It specifies how projects move through their lifecycle, how decisions are made, who holds authority, and what information must be produced.

A true method typically defines:

Examples of genuine project management methods include:

What the Commonly Listed “Methodologies” Actually Are

When structural tests are applied, most commonly listed methodologies turn out to be something else entirely.

How to Tell If Something Is a Method

Instead of debating labels, practitioners can apply a simple structural test. A genuine project method must answer five questions.

Why This Confusion Persists in the Agile Era

In the early decades of modern project management, most environments relied on structured project methods that emphasized governance, stage control, documentation, and formal decision authority. Beginning in the late 1990s, the software industry began challenging these approaches. Many teams found that highly structured methods were poorly suited to environments where requirements changed rapidly. This led to the creation of the Manifesto for Agile Software Development.

Agile did not attempt to create a single method. It introduced a set of guiding principles intended to shape how work was approached. Frameworks such as Scrum and practices such as Kanban emerged to operationalize those principles. Over time, however, because Agile minimized formal governance structures, many organizations began treating frameworks and practices as if they were complete project systems. The terminology spread through training materials, blogs, and search engines until the idea that Scrum or Kanban were “project methodologies” became common language.

The irony is that Agile itself never claimed this. In many environments, Agile frameworks operate most effectively inside an existing governance method, rather than replacing it entirely. Project governance answers questions such as who authorizes a project, how decisions are escalated, and how accountability is maintained. Delivery frameworks answer a different set of questions: how the team organizes work, how frequently increments are delivered, and how feedback is incorporated. Both are important. But they operate at different levels of the system.

Our Profession Needs Better Language

Project management has matured significantly as a profession. It has developed standards, bodies of knowledge, governance models, and increasingly sophisticated delivery practices. Yet one of its most basic concepts — what constitutes a method — remains widely misunderstood. This confusion is harmful.

When tools are mistaken for methods, organizations attempt to govern projects using practices that were never designed for governance. Delivery may improve, but authority becomes unclear. Decisions drift. Accountability weakens. The project becomes a collection of activities rather than a controlled system.

Frameworks, philosophies, and techniques are valuable. Scrum helps teams organize work. Kanban improves flow. Lean reduces waste. Six Sigma improves quality. The Critical Path Method improves scheduling. But these tools work best when they operate inside a coherent method, not when they are mistaken for one. If the profession is to continue maturing, it must become more precise in its language. The difference between a method, a framework, and a tool is not academic. It is structural. It determines how projects are governed, how decisions are made, and how organizations manage risk.