How Many Project Management Methodologies Are There, Really

The short version: there are around 12 methodologies most consultants, PMI, and business schools would recognise by name, but if you count every hybrid, certification, and "framework" a software vendor has trademarked, the real number runs into the hundreds. Most businesses only ever need two or three of them. The rest is noise sold to you as expertise.

I get asked this question a lot, usually by a client who's just come out of a meeting where someone senior said the words "we should try Kanban" without knowing what Kanban involves. So let's answer it, then let's talk about the bit nobody wants to say out loud.

The straight count: 12 major methodologies

If you sit down and list the methodologies that have their own body of literature, their own certifications, and their own communities, you land at roughly twelve:

• Waterfall
• Agile (the umbrella term, not a single method)
• Scrum
• Kanban
• Lean
• Six Sigma
• Lean Six Sigma
• PRINCE2
• PMI/PMBOK
• Critical Path Method (CPM)
• Critical Chain Project Management (CCPM)
• SAFe (Scaled Agile Framework)

Twelve. That's the honest, commonly cited number, and it's the one I'd give a client on a call if they wanted a quick answer. I've written a longer breakdown of what each of these means in practice in the main project management methodologies explained in plain English, because knowing the name Scrum and knowing how a daily standup runs are two very different things.

Why the real number is closer to 200 than 12

Here's where it gets messy. Once you go past the twelve "core" methods, you hit an enormous pile of hybrids and rebrands:

• Scrumban (Scrum plus Kanban)
• Extreme Programming (XP)
• Feature-Driven Development (FDD)
• Dynamic Systems Development Method (DSDM)
• Adaptive Project Framework (APF)
• Crystal (and its sub-variants: Crystal Clear, Crystal Yellow, Crystal Orange)
• PRiSM (sustainability-focused)
• Event Chain Methodology
• Process-Based Management
• Rational Unified Process (RUP)
• LeSS (Large-Scale Scrum)
• Nexus (from Scrum.org, for scaling Scrum across teams)
• Disciplined Agile (DA)

That's another thirteen, and I've barely scratched the surface. Add in every consultancy's proprietary "framework" (and there are dozens, because a named framework is easier to sell than an hourly rate), and you get to a genuine estimate of somewhere between 150 and 300 named methodologies floating around business literature, LinkedIn posts, and PMI's own extended reading lists. Nobody has an exact count because nobody's counting the internal frameworks that agencies build, rename, and pitch as unique intellectual property. I've seen three different consultancies present me with what was, functionally, Kanban with a new logo.

A real example: the client who spent 40,000 pounds chasing the "right" methodology

A few years back I worked with a mid-size marketing agency, 45 staff, decent revenue, chaotic delivery. Over eighteen months before I got involved, they'd gone from Waterfall to Scrum, then brought in a consultant who convinced them SAFe was the answer because they had "multiple teams," then abandoned that eight months in when a different senior hire preferred Kanban.

Total cost across certifications, consultant day rates, and the internal time lost retraining project managers three times: just over 40,000 pounds. Delivery times had not improved. If anything they'd got worse, because every switch meant a few weeks of nobody knowing which board to update or which meeting mattered.

What fixed it wasn't a fourth methodology. It was three things: a single shared task board (they picked Kanban and stuck with it), a rule that no project started without a written scope, and a weekly quarter-hour review where the project lead flagged anything at risk. None of that is a methodology. It's discipline dressed up as one.

The uncomfortable bit: methodology rarely matters as much as people are told

I'll say the thing most guides on this topic dance around: the methodology you pick is usually not the reason your projects are late. I've watched teams run textbook-perfect Scrum, standups on time, sprints planned, retros held religiously, and still miss every deadline because the actual problem was that the client kept changing scope and nobody had the authority to say no. I've also watched teams with a scruffy shared spreadsheet and no named methodology at all hit every date, because the team was small, communicated constantly, and had one person who owned decisions.

The consulting industry has a financial reason to keep pushing "which methodology is right for you" as the central question. Certifications, workshops, and framework licensing are a business. A Scrum Master certification alone runs 400 to 1,500 pounds depending on the provider, and PMI's PMP certification costs around 555 US dollars for members and 750 for non-members, plus the study time. That's a real industry built on the promise that the right label fixes delivery. It mostly doesn't. What fixes delivery is clear ownership, honest scoping, and a communication rhythm the team keeps to, regardless of what you call it on the slide.

That's not to say methodology is irrelevant. If you're building physical infrastructure with fixed sequential dependencies, Waterfall suits you better than Agile, because you cannot pour foundations after you've built the walls. If you're shipping software in small increments to real users, an agile approach helps because it shortens the feedback loop. The method should match the shape of the work. But past that basic fit, the marginal gain from picking exactly the right named framework, versus picking a reasonable one and running it with discipline, is small.

How to pick, without wasting a year on it

If you're a small or mid-size business trying to decide, here's the process I run with clients, and it takes one afternoon, not a quarter:

• Step 1: Write down whether your work is sequential and fixed-scope (construction, compliance, one-off big launches) or iterative and evolving (software, marketing campaigns, product development). This alone eliminates about eight of the twelve major methodologies.
• Step 2: If sequential, use Waterfall or PRINCE2. If iterative, use Scrum or Kanban., for 80 percent of small businesses, the decision is that simple.
• Step 3: Pick one tool to run it in (Trello, Asana, Monday, Jira, whatever your team will open every day) and commit to it for a minimum of three months before judging it.
• Step 4: Assign one person as the decision-owner per project. Not a committee. One name.
• Step 5: Review the method itself once a quarter, not every time a project has a bad week.

If you're scaling past a few teams and coordination breaks down, that's when frameworks like SAFe or LeSS earn their complexity. Below that size they usually just add meetings. I've written more on the practical side of rolling agile principles across departments in how to bring agile to the whole organization, which covers the politics of it as much as the process.

Where this connects to bigger business decisions

The methodology question tends to surface at the same moment as another one: do you build your delivery team internally or bring in outside help. I've seen founders assume that hiring an outsourced dev shop will automatically bring methodology and discipline with it. Sometimes it does. Often the outsourced team runs its own internal process and you never see the mechanics, which can be fine or can leave you blind to why things slip. If you're weighing that decision, I've laid out the real cost and control trade-offs in internal vs outsourced software development team, what's more affordable, and the honest version is that methodology maturity should factor into that hire as much as day rate does.

On the marketing side specifically, project chaos is one of the most common reasons campaigns underdeliver, and it's rarely the strategy that's wrong. I pulled together the scale of that problem, and plenty of adjacent numbers on how marketing teams operate, in B2B marketing stats unzipped, and the pattern holds: teams with clear process outperform teams with better ideas but no delivery structure.

What I'd tell you if you only read one paragraph

There are twelve methodologies worth knowing by name and roughly two hundred worth ignoring unless a consultant is trying to sell you a workshop. Pick based on whether your work is fixed-sequence or iterative, commit to it for a proper stretch, put one person in charge of decisions, and stop treating the framework as the fix for problems that are about scope, ownership, and communication. I've rebuilt my own business twice in the last five years and the projects that went well were never the ones with the fanciest board. They were the ones where somebody picked up the phone when something went wrong instead of waiting for the next scheduled standup.

Frequently asked questions

How many project management methodologies are there in total?

Around 12 major methodologies are widely recognised by name and certification (Waterfall, Agile, Scrum, Kanban, Lean, Six Sigma, PRINCE2, PMBOK, CPM, CCPM, SAFe, and Lean Six Sigma), but including hybrids, sub-variants, and consultancy-branded frameworks, the total named methodologies in circulation runs to somewhere between 150 and 300.

What is the most commonly used project management methodology?

Agile, and specifically Scrum, is the most widely used approach in software and marketing teams, while PRINCE2 and PMBOK-based traditional project management remain dominant in construction, government, and large fixed-scope programmes.

Do small businesses need a formal methodology at all?

No, not a certified one. Most small businesses do fine with a simplified Kanban-style board, one clear decision-owner per project, and a weekly check-in, without ever paying for a certification or naming their process after a framework.

Is it worth getting certified in a specific methodology like PRINCE2 or Scrum?

It's worth it if you're job hunting in a sector that filters CVs by certification, such as government contracting or large enterprise programmes, but for running your own business's projects well, the certification teaches less than three months of running a project with discipline.