8 Project Management Methodologies Compared: How to Choose

A retail replatform ran as strict Waterfall: nine months of requirements, one go-live date, a change board for every amendment. By month four the business had rethought checkout, the specification was frozen, and the team shipped the document rather than the product. The rework cost more than the original build. Waterfall was not the problem; it was the wrong fit. There is no best project management methodology, only the one that matches your scope, your rate of change and your governance.

That mismatch is the real question hiding behind “which methodology is best”. This guide maps eight approaches – Waterfall, Agile, Scrum, Kanban, Lean, Six Sigma, PRINCE2 and hybrid – and for each one explains what it actually changes about how work is planned, controlled and handed over, where it breaks, and which credential proves you can run it. Treat it as a decision aid rather than a ranking.

What separates one project management methodology from another?

Strip away the vocabulary and the eight approaches differ on one thing above all: when the scope is decided. Everything else – the ceremonies, the documents, the roles, the reporting – follows from that single choice. Decide the scope once at the start and you need change control, stage gates and a detailed plan. Decide it repeatedly as you learn, and you need short cycles, a prioritised backlog and someone empowered to say what comes next.

That gives three families, plus a deliberate blend:

• Predictive, or plan-driven. Waterfall and PRINCE2. Scope is fixed early, the plan is the contract, and change is an exception that has to be approved.
• Adaptive, or empirical. Agile, Scrum and Kanban. Scope is refined continuously against working output, and the plan is a forecast rather than a promise.
• Improvement-led. Lean and Six Sigma. These do not govern a project at all; they improve a process that already runs, by removing waste or by reducing variation.
• Hybrid. A predictive envelope with adaptive delivery inside it – now the most common shape in large organisations, and the one PMI builds its exams around.

A second distinction saves a lot of argument, and the old version of this article got it only half right. These eight things are not the same kind of object. Agile is a philosophy. Scrum and Kanban are frameworks that put a philosophy into practice. PRINCE2 is a method, with prescribed processes and roles. The PMBOK Guide is a standard, not a method at all. Lean and Six Sigma are improvement disciplines. Comparing them as if they were seven interchangeable products is the reason so many teams end up running ceremonies they cannot justify.

Approach	Family	Works best when	Breaks when
Waterfall	Predictive	Scope, regulation and sequence are all known up front	Requirements are still being discovered
Agile	Adaptive (philosophy)	Learning fast is worth more than certainty	Nobody on the customer side can decide
Scrum	Adaptive (framework)	One small team can deliver something usable every few weeks	Scope and price are both contractually fixed
Kanban	Adaptive (framework)	Work arrives unpredictably and must keep flowing	Work in progress is never limited
Lean	Improvement	A repeatable flow of work carries obvious waste	Applied to a one-off build with no flow to study
Six Sigma	Improvement	A measurable defect rate needs to come down	There is no baseline data to work from
PRINCE2	Predictive (method)	Governance, roles and business justification must be provable	A two-person team is made to carry full process
Hybrid	Blend	Funding is staged but delivery must stay flexible	Nobody agrees which decisions are actually locked

Three questions settle most of it. How stable is the scope – genuinely, not as stated in the business case? How quickly and cheaply can you find out you were wrong? And how much of the governance is imposed on you by a regulator, a funder or a contract rather than chosen by you? Answer those honestly and the shortlist usually comes down to two.

When is Waterfall still the right way to run a project?

Waterfall runs a project as a sequence of phases – requirements, design, build, test, deploy – where each phase is signed off before the next begins. It is the oldest approach here and the most maligned, and it is still the correct answer more often than the internet suggests.

The case for it is simple. When the cost of changing something later is very high, and the cost of getting the requirements right early is comparatively low, planning in detail pays for itself. That describes a lot of real work: a building, a production line, a hardware product with tooling costs, a data-centre migration with a single cutover weekend, a fixed-price contract where the scope is the thing being bought. In those settings, the traceability Waterfall produces – a requirement that maps to a design that maps to a test – is not bureaucracy, it is the evidence a regulator or an auditor will ask for.

The case against it is equally simple, and it is about feedback. Nothing usable exists until late, so a misunderstanding written into the specification survives until testing. Requirements decay while the build runs. And because testing sits at the end, every schedule overrun upstream is paid for by squeezing the one phase that finds defects. The replatform in the opening paragraph failed in exactly that pattern.

How to tell you are pretending

The honest test is whether the specification could be written by someone who has never built this before. If your team is producing a detailed, signed-off design for something genuinely novel, the document is a guess dressed as a plan, and the stage gates will enforce the guess. Sequential phases are for work whose shape is already known.

What do Agile, Scrum and Kanban each actually change?

These three are frequently treated as synonyms, and they are not. One is a set of values, and the other two are different ways of living by them.

Agile: values before process

Agile sets a direction rather than a procedure: favour people and conversation over process and tooling, working output over exhaustive documentation, collaboration over contract negotiation, and responding to change over following the plan. None of that says how to run a Tuesday. It says what to optimise for when a decision is close.

The hidden cost is customer availability. Adaptive delivery only works when someone with authority is in the room often enough to answer questions and re-order priorities. Teams that adopt Agile without that person get all the ceremony and none of the feedback, and end up planning in two-week slices with the same frozen scope they had before. Agile is also not the absence of a plan; it is a plan with a shorter horizon and an honest label on its uncertainty.

Scrum: a fixed cadence and clear accountabilities

Scrum gives the shape Agile leaves out. A small team – ten or fewer is the usual guidance – works in a fixed timebox called a sprint. A Product Owner owns the ordered product backlog and decides what matters next. A Scrum Master coaches the team and clears impediments. The developers own how the work gets done and commit to a Definition of Done that does not move. Each sprint ends with a review of the working increment and a retrospective on how the team worked, and starts with planning the next slice. Scrum's own reference, the Scrum Guide published by Scrum.org, is short enough to read in one sitting and settles most of the arguments teams have about roles and events.

Scrum fails in two recognisable ways. The first is a Product Owner who cannot actually decide – a proxy who has to take every question back to a committee, which turns the sprint into a queue for approvals. The second is a fixed-price, fixed-scope contract underneath: if both scope and price are locked, there is nothing for the backlog to trade against and sprints become status reporting.

Kanban: limit the work, watch the flow

Kanban changes less and asks for less. There is no timebox, no prescribed roles and no big-bang adoption; it starts from how you work today and improves it. The practices are to visualise the workflow, limit work in progress, manage flow, make process policies explicit, put feedback loops in place, and improve collaboratively through small experiments.

The limit on work in progress is the part that does the work, and the part most often skipped. Capping how many items can sit in each column forces the team to finish before it starts, which is what shortens cycle time. Kanban measures itself on lead time and cycle time rather than on velocity, so it suits work that arrives unpredictably: support, maintenance, operations, infrastructure, anything interrupt-driven. A Kanban board with no limits is a wall of sticky notes, not a method.

Scrum or Kanban?

Choose Scrum when the team can carve work into slices that are worth reviewing every couple of weeks, and when a regular planning rhythm helps. Choose Kanban when priorities change faster than a sprint boundary, when the work is a stream rather than a project, or when the team is already overloaded and needs to finish things before it can plan anything. Many teams end up with a blend: a visible board with limits, plus a planning session and a retrospective on a regular cadence.

How do Lean and Six Sigma fit when they are not project methods?

Lean and Six Sigma sit on a different axis from the other six. They do not tell you how to govern a project or how to schedule delivery. They improve a process that already exists, and they are chosen because something measurable is wrong with it.

Lean: remove everything the customer would not pay for

Lean starts by defining value from the customer's point of view, maps the value stream that delivers it, makes the work flow without queues, lets demand pull work through rather than pushing it, and then repeats. Its diagnosis is three-part: muda, activity that adds no value; mura, unevenness that creates firefighting; and muri, overburden on people or equipment. Most of Lean's practical power is in the second and third of those, which teams routinely ignore in favour of hunting waste.

Lean is where Kanban came from, which is why the two feel related. The difference is scope: Lean looks at the whole value stream, including the parts your team does not own, while Kanban manages the flow through one team's board.

Six Sigma: reduce variation with evidence

Six Sigma attacks a different problem – not waste, but inconsistency. It runs improvement projects through a defined cycle, DMAIC: define the problem and its customers, measure the current performance, analyse the causes, improve the process, and control it so the gain holds. Designing something new rather than fixing something existing uses a variant, DMADV. The discipline is statistical: you establish a baseline, prove the cause, and prove the improvement.

That dependence on data is also its boundary. Six Sigma needs a process that repeats often enough to measure and a defect that can be defined. Applied to a one-off software build or a first-of-its-kind construction project, it has nothing to sample, and the effort goes into building a measurement system for something that will never run again.

Lean Six Sigma and the belt ladder

In practice the two are usually taught together as Lean Six Sigma, with Lean supplying flow and waste analysis and Six Sigma supplying the statistical rigour. Certification follows a belt ladder, and ASQ is the body most employers recognise. ASQ's Certified Six Sigma Green Belt page sets out the role a Green Belt is expected to fill: a practitioner who leads smaller improvement projects and supports Black Belt work while still doing a day job.

The ASQ Certified Six Sigma Green Belt exam has 110 questions, with an exam time of 258 minutes inside a total appointment time of 270 minutes, and a passing score of 550/750. The fee is ASQ MEMBERS - $383, NON-MEMBERS - $483, RETAKES - $283. The Certified Six Sigma Black Belt exam is the larger commitment: 165 questions, the same 258 minutes of exam time within a 270-minute appointment, the same 550/750 passing score, and a fee of ASQ MEMBERS - $485, NON-MEMBERS - $585, RETAKES - $385. Choose Green Belt if you will lead improvement projects alongside another role, and Black Belt if improvement work is the role.

Why do PRINCE2 and the PMBOK Guide govern projects differently?

Both come up in every methodology discussion, and they answer different questions. One tells you how to run and govern a project. The other tells you what good project management consists of and leaves the running to you.

PRINCE2: governance you can evidence

PRINCE2 – PRojects IN Controlled Environments – is a method, and a prescriptive one. Version 7, examined by PeopleCert, is built on seven principles, seven practices and seven processes. The principles are the part worth knowing even if you never sit the exam, because they are what the rest hangs from: continued business justification, learning from experience, defined roles and responsibilities, managing by stages, managing by exception, focusing on products, and tailoring the method to suit the project.

Two of those do most of the heavy lifting. Manage by stages breaks the project into authorised chunks, so the project board re-confirms the business case before releasing the next tranche of money rather than at the end. Manage by exception sets tolerances for time, cost, scope, quality, benefit and risk, and only escalates when a tolerance is about to be breached – which is what keeps a governance board from turning into a weekly status meeting. PeopleCert's PRINCE2 7 Practitioner page covers the current version and its prerequisites; if you want to see how the method is broken down topic by topic before committing, our breakdown of what PeopleCert tests at Practitioner level lists the areas in order.

The common complaint – that PRINCE2 is heavy – is usually a tailoring failure. Tailoring is one of the seven principles, not an escape hatch bolted on afterwards. A small project that produces every management product in full has misapplied the method.

The PMBOK Guide: a standard, not a methodology

You cannot run a PMBOK project, and PMI does not claim you can. The PMBOK Guide is a standard: a shared vocabulary, a body of accepted practice and guidance on tailoring. Master lists PMP against the PMBOK Guide – Seventh Edition, and the seventh edition matters because it reorganised the standard around principles and performance domains rather than the five process groups that earlier editions were known for. The practical effect is that PMI stopped describing one way to run a project and started describing what has to be true however you run it.

That makes PRINCE2 and the PMBOK Guide complementary rather than rival. PRINCE2 tells you who decides what and when; PMI's standard tells you what competent delivery looks like across predictive, agile and hybrid work. Plenty of organisations hold both.

What is a hybrid approach, and why do PMI's exams now assume one?

Hybrid is not a compromise or a failure to commit. It is a deliberate structure: a predictive envelope around adaptive delivery. Funding, governance and the major milestones are staged and approved in the traditional way; inside each stage, the team works in sprints or pulls from a limited board.

The shapes that recur are worth recognising:

• Fixed date, flexible scope. The deadline is real – a regulatory cutover, a trading season – so the backlog is ordered so that the most valuable slice is always shippable.
• Predictive hardware, adaptive software. Tooling and manufacturing run to a plan because they cannot be re-cut; the firmware and apps iterate against it.
• Adaptive build, predictive submission. Common in regulated industries: the product is developed iteratively while the evidence pack for the regulator is assembled to a fixed sequence.
• Staged governance, flowing delivery. A project board approves stage by stage while the delivery team runs Kanban underneath, reporting cycle time instead of percentage complete.

PeopleCert recognised the pattern formally with PRINCE2 Agile, which keeps PRINCE2's governance and swaps its delivery layer for agile working. And when several teams have to deliver against one cadence, scaling frameworks take over: SAFe is the most widely adopted, organising teams into trains that plan together on a shared rhythm.

Hybrid has a real cost, and it is worth naming. You are running two vocabularies, two reporting rhythms and two definitions of done at once. It works when everyone can say, without checking, which decisions are locked at a stage boundary and which stay open inside the stage. It fails when that line was never drawn, and the project gets change control and sprint planning arguing over the same decision.

How do you choose a methodology for the project in front of you?

Run the project through six questions before you run it through a framework. The answers point at a family, and the family usually leaves two candidates.

1. Can the scope be described completely, by someone who has done this before? Yes points predictive. No points adaptive, whatever the business case claims.
2. How fast and how cheaply can you discover that you were wrong? If feedback is weeks away and expensive, plan more. If a working slice can be shown in two weeks, iterate.
3. Who imposes the governance? A regulator, a funder or a fixed-price contract sets a floor on documentation and stage gates that no amount of agility removes.
4. How many teams, and where are they? One co-located team can run Scrum or Kanban directly. Five teams delivering one product need a scaling framework or a hybrid structure.
5. Is there a decision-maker available weekly? If not, adaptive delivery will stall no matter how good the team is.
6. Is this a project at all, or a process? Recurring work with a measurable defect rate is an improvement problem. Reach for Lean or Six Sigma, not for sprints.

Three worked calls

A regulated medical device. Scope is constrained by a submission, the evidence trail must be complete, and a design change late in the cycle is expensive. Predictive, with PRINCE2-style stage gates and a project board – and, realistically, hybrid, with the embedded software iterating inside the stages.

A subscription product's feature stream. Priorities shift with customer behaviour, releases are cheap, the team is nine people. Scrum if the team wants a planning rhythm, Kanban if interruptions outnumber planned work. Both, if the board carries limits and the retrospective stays.

A contact centre missing its resolution targets. This is not a project. The process runs thousands of times a month and the defect is measurable. Map the value stream, cap the queues, then run a DMAIC cycle on the biggest contributor. A Green Belt leads it; nobody needs a sprint.

The mistakes that cost the most

• Adopting ceremonies without the principle behind them. Daily stand-ups with no ordered backlog produce a meeting, not flow.
• Running Scrum under a fixed-scope, fixed-price contract. There is nothing to trade, so the sprint becomes a reporting unit.
• A Kanban board with no work-in-progress limits. Visibility without a limit changes nothing.
• Six Sigma on a one-off build. No repetition means no baseline, and the measurement system outlives the project.
• Full PRINCE2 documentation on a two-person project. Tailoring is a principle; ignoring it is the reason people call the method heavy.
• Changing methodology mid-project to fix a people problem. An absent decision-maker or an unclear sponsor is not solved by a different framework.

One more, which is really the theme of this article: choosing a methodology because it is the one the team already has a certificate in. The credential should follow the work, not the other way round.

Which certification follows the methodology you use?

Each family has a credential that employers actually recognise, and the figures below come from our exam records for each one. Use them to cost the route before you commit to it.

Certification	Vendor	Questions	Duration	Fee (USD)	Passing score
Project Management Professional (PMP)	PMI	180	240 minutes	Member Price: USD $425 / Full Price: USD $675	Above Target / Target / Below Target / Needs Improvement
Certified Associate in Project Management (CAPM)	PMI	150	180 minutes	Member Price: USD $225 / Full Price: USD $300	Above Target / Target / Below Target / Needs Improvement
PRINCE2 7 Foundation	PeopleCert	60	60 minutes	338	60
PRINCE2 Practitioner (Version 7)	PeopleCert	70	150 minutes	500	60
Certified Six Sigma Green Belt (CSSGB)	ASQ	110	Exam time 258 minutes (total appointment 270)	ASQ MEMBERS - $383 / NON-MEMBERS - $483 / RETAKES - $283	550/750
Certified Six Sigma Black Belt (CSSBB)	ASQ	165	Exam time 258 minutes (total appointment 270)	ASQ MEMBERS - $485 / NON-MEMBERS - $585 / RETAKES - $385	550/750
Certified SAFe Agilist (SA)	SAFe	45	90 minutes	First attempt included in the course registration fee if taken within 30 days of course completion; each retake or attempt past the 30-day window is $50	80

If you work across predictive, agile and hybrid

PMP is the broad credential, and it is deliberately not tied to one methodology: PMI describes it as covering predictive, agile and hybrid approaches, which is the clearest signal that the industry has stopped treating those as rival camps. PMI's PMP certification page carries the current eligibility requirements, which include documented experience leading projects – so it is a mid-career credential, not a starting point. CAPM is the entry-level route for the same body of knowledge when you do not yet have the hours.

If your governance is the thing being assessed

PRINCE2 is the stronger fit wherever a board, a funder or a public-sector framework needs to see how decisions were authorised. Foundation proves you know the method; Practitioner proves you can tailor it to a scenario, which is the part the exam actually tests.

If you improve processes rather than deliver projects

Green Belt or Black Belt, depending on whether improvement is part of your job or the whole of it. Both assume you will bring real data from a real process, which is why they transfer so well between industries.

If you are scaling agile across teams

SAFe credentials follow the role you hold on a train rather than the methodology in the abstract; the Certified SAFe Agilist sits at the leadership end. Scaled Agile's SAFe Agilist page sets out the course requirement, which is worth checking early because the exam is bundled with attendance rather than bought separately.

Whichever route fits, the useful next step is the same: before you pay for training, find out which parts of the body of knowledge you already know from the way you work. Sitting a timed PMP practice test against the 180-question, 240-minute format is a cheap way to see whether your experience already maps onto PMI's vocabulary or whether the gap is bigger than it feels.

Pick the methodology the project needs, tailor it honestly, and let the certificate follow. That order is what the replatform in the first paragraph got wrong, and it is the one decision on this page that costs nothing to get right.

Frequently Asked Questions

What are the main project management methodologies?

The eight most widely used are Waterfall, Agile, Scrum, Kanban, Lean, Six Sigma, PRINCE2 and hybrid. They fall into three families: predictive approaches that fix scope early, adaptive ones that refine it continuously, and improvement disciplines that fix a running process rather than govern a project.

Which project management methodology is best?

None is best in general. The choice follows three things: how stable your scope genuinely is, how quickly and cheaply you can discover a mistake, and how much governance a regulator, funder or contract imposes on you. Stable scope and heavy governance point predictive; fast, cheap feedback points adaptive.

What is the difference between Agile and Scrum?

Agile is a set of values about favouring working output, collaboration and response to change. Scrum is one framework that puts those values into practice with a fixed sprint timebox, three accountabilities, a prioritised product backlog and a Definition of Done. You can be agile without Scrum, but not the reverse.

Is PRINCE2 or PMP better for a project manager?

They prove different things. PRINCE2 shows you can run a method with defined roles, stage authorisation and management by exception, and is stronger where governance is audited. PMP covers predictive, agile and hybrid delivery across a broader body of knowledge and requires documented experience leading projects.

Are Lean and Six Sigma project management methodologies?

Not strictly. Both improve a process that already runs rather than governing a one-off project. Lean removes waste, unevenness and overburden from a value stream; Six Sigma reduces variation through the DMAIC cycle using measured data. Use them when work repeats often enough to have a measurable defect rate.

Select ratingPoorOkayGoodGreatAwesome

Rating: 5 / 5 (81 votes)