Project management methodologies: a practical field guide

"Project management methodology" gets used as if it names one kind of thing, but it spans several different kinds. Some are full delivery philosophies you run an entire project inside. Some are frameworks that implement a philosophy with concrete roles and rituals. And some aren't methodologies in that sense at all — they're scheduling techniques that slot in underneath whichever method you've already chosen. Waterfall and PRINCE2 are methods. Agile is a set of values, not a method you can "run" — Scrum and Kanban are the frameworks that implement it. The critical path method and critical chain are techniques for scheduling a network of tasks, indifferent to whether the project around them is Waterfall or Agile. Mixing up these levels is where most "which methodology should we use?" arguments quietly go wrong.

This guide walks through all eight in plain terms: what each one actually is, and the kind of project it earns its keep on. None of them is universally correct — adopting a methodology because it's fashionable, rather than because it fits the work in front of you, carries about as much risk as having no methodology at all. The comparison table near the end gives the short version; the sections give the reasoning.

Waterfall

Waterfall is the original sequential model: requirements, design, build, test, and deploy, with each phase finished and formally signed off before the next one begins, usually against a full work breakdown structure drawn up before a single task starts. The name traces to a 1970 paper by Winston Royce — ironically, a paper that mostly described the model's problems, though the industry adopted the diagram anyway and ran with it for decades. Its strength is discipline: nobody starts building until the design is agreed, and nobody ships until testing has signed off, so everyone downstream knows exactly what they're building against. That same discipline turns into its weakness the moment requirements weren't actually settled, because reopening an earlier phase after sign-off is disruptive and often political — Waterfall punishes a late discovery far more than an iterative method would. It earns its keep on projects with stable, well-understood requirements and heavy compliance needs: construction, manufacturing, hardware, and other regulated work where a documented, gated trail of approvals matters almost as much as the deliverable itself.

Agile

Agile isn't a method at all — it's a set of values, set out in the 2001 Agile Manifesto, favouring individuals and interactions over rigid process, working software over exhaustive documentation, customer collaboration over a fixed contract, and responding to change over a plan drawn up in advance. Instead of committing to a complete plan upfront, Agile teams deliver in small increments, gather feedback on each one, and let it reshape what comes next — a different bet from Waterfall's assumption that you can specify everything correctly before you start. Agile itself doesn't say how to run a stand-up or size a backlog; that's the job of the frameworks built on top of it, chiefly Scrum and Kanban, covered next. It earns its place on product and software work where requirements are expected to move as users react to what gets built, with feedback on a short cycle. It earns nothing where no one can give that feedback, or where the deliverable's shape is fixed by physics, contract, or regulation.

Scrum

Scrum is the most widely used way of putting Agile values into practice. Work happens in fixed-length iterations called sprints — most commonly two weeks — pulled from a single prioritised backlog, structured around a small and deliberately rigid set of ceremonies: sprint planning at the start, a daily stand-up, a review that demonstrates what got built, and a retrospective on how the team worked together. Three roles anchor it: a Product Owner who owns the backlog and its priority, a Scrum Master who protects the process, and a development team who commits to what genuinely fits inside the sprint. Its strength is cadence — a demoable increment every couple of weeks keeps scope realistic and progress visible to everyone, not just the team. Its cost is discipline: skip the retrospective, let priority get reshuffled mid-sprint, or let stand-ups drift into status theatre, and you're left with the ceremonies but none of the benefit. Scrum earns its keep on a reasonably stable product team working off one backlog, with enough predictability in the work to commit honestly to a fixed-length sprint.

Kanban

Kanban drops fixed iterations altogether in favour of continuous flow. Work is visualised as cards moving through columns — typically To Do, In Progress, Review, and Done — and the defining rule is a hard cap on how many cards can sit in any column at once. That work-in-progress limit is the whole mechanism: a new card is pulled in only once an existing one is finished, which stops a team starting more than it can finish and exposes a bottleneck the moment a column fills. Kanban's lineage runs through Toyota's manufacturing floor, later adapted for knowledge work in the mid-2000s. There's no sprint boundary, no fixed backlog commitment, and no ceremony beyond keeping the board honest — the lighter-weight of the two Agile frameworks, and the better fit where priorities shift daily rather than fortnightly. It earns its keep on continuous operational work with an unpredictable arrival of tasks — a support queue, a content pipeline, ongoing maintenance — anything without a natural start and end. It offers comparatively little where tasks depend on each other in a fixed order or a hard deadline is looming, because a board shows the state of the work, not its sequence or dates. (Our full Gantt chart vs Kanban comparison goes deeper on that gap.)

Lean

Lean isn't a project scheduling method either — it's a set of principles for cutting anything that doesn't add value for the customer, drawn from the Toyota Production System and later generalised well beyond manufacturing. Its five moves: define value from the customer's point of view, map the full value stream so waste becomes visible, redesign the work so it flows without stalling, let real demand pull work through the system rather than pushing it in ahead of need, and pursue improvement continuously rather than as a one-off fix (kaizen). Applied to project work, Lean shows up as fewer handoffs, less work sitting idle, and a habit of asking whether a step earns its place at all rather than just doing it faster. It's frequently paired with Kanban, which supplies the visual, flow-controlling mechanism Lean's principles call for — Lean is the why, Kanban is one of the hows. It earns its keep in manufacturing, operations, and any process-heavy environment where cycle time and waste are the real enemy, less so on a one-off project with no repeating process to improve.

PRINCE2

PRINCE2 — PRojects IN Controlled Environments — is a structured, process-based method that originated with the UK government in 1989 and is now used well beyond it, especially in Europe's public sector. It organises a project into defined stages, assigns clear roles (a Project Board holding overall authority, a Project Manager running day-to-day work), and requires formal management documents at each stage, chief among them the Business Case — which, under PRINCE2's own principles, must be revisited and shown to still be worthwhile at every stage, not signed off once and forgotten. Seven principles, seven themes, and seven processes give it a reputation for being paperwork-heavy, and it can be — but the rigour is exactly the point where accountability and an audit trail matter as much as delivery. It's commonly paired with Agile delivery underneath it — formalised as PRINCE2 Agile — so governance sits at the project level while Scrum or Kanban runs the actual work. It earns its keep on larger, governance-heavy projects, particularly in the public sector or other regulated settings where "who decided this, and why" needs a documented, defensible answer.

Critical Path Method

The critical path method (CPM) isn't a project management methodology in the sense the previous six are — it's a scheduling technique that slots in underneath almost any of them. Once you have a set of tasks with durations and dependencies, CPM maps them as a network and finds the longest chain running from start to finish. That chain is the critical path: it sets the shortest possible duration for the whole project, and every task on it has zero room to slip without delaying the end date. Tasks off the critical path carry spare time, called float, before their own slippage starts to matter. CPM doesn't care whether the surrounding project is Waterfall or Scrum; wherever a genuine network of dependent tasks with knowable durations exists, the technique applies, and a Gantt chart is usually how the result gets drawn and communicated. It earns its keep on any project — construction, engineering, product launches, event planning — where tasks genuinely depend on one another and you need to know the earliest date the whole thing can finish. It has little to offer continuous-flow work like a Kanban queue, where there's no fixed network of dependent tasks to analyse.

Critical Chain

Critical Chain Project Management (CCPM), developed by Eliyahu Goldratt in his 1997 book Critical Chain, starts from a complaint about CPM: task estimates are usually padded with private safety margin, and that padding gets wasted anyway, because people start late and rarely finish early even when they could. CCPM's fix is to strip the padding out of individual estimates and pool it into shared buffers placed strategically: a project buffer at the very end of the schedule, and feeding buffers wherever a non-critical chain merges back into the main one. It also accounts for resource contention, not just task order — the "critical chain" is the longest chain once you've made sure the same person isn't quietly double-booked across two supposedly parallel tasks, something plain CPM ignores. That resource-aware view is where it earns its keep: organisations running several projects off one shared, scarce pool of people or equipment, where multitasking and hidden padding quietly eat the schedule. It asks more of the organisation than CPM does, since the buffers only work if people report progress honestly — so it pays off in resource-constrained, multi-project settings and less on a simple, single-project team with slack to spare. (For more, see slack and float explained.)

How they compare at a glance

Laid side by side, the difference in kind between a full method, a framework, a philosophy, and a scheduling technique becomes easier to see:

Methodology	What it is	Structure	Best for
Waterfall	Sequential method	Fixed phases, gated sign-off	Stable requirements, regulated or compliance-heavy work
Agile	Values / umbrella	Iterative increments, continuous feedback	Evolving requirements with real user feedback available
Scrum	Agile framework	Fixed-length sprints, defined roles and ceremonies	Product teams building incrementally off one backlog
Kanban	Agile / Lean method	Continuous flow, WIP limits, no fixed iterations	Ongoing operational work with shifting daily priorities
Lean	Improvement philosophy	Value-stream mapping, pull, continuous improvement	Cutting waste in manufacturing or repeating processes
PRINCE2	Process-based method	Staged, defined roles, formal management documents	Governance-heavy or public-sector projects
Critical Path Method	Scheduling technique	Network diagram, forward and backward pass	Finding minimum duration and slack in any task network
Critical Chain	Scheduling technique	Resource-aware chain, pooled buffers	Multi-project teams sharing scarce resources

How to choose

Start from two questions about the work itself, not a personal preference. How well do you actually know the requirements, and how likely are they to change? And does the work run as a one-off project with a real end date, or a continuous stream with no natural finish line? The answers do most of the choosing.

• Requirements are stable and getting it wrong is costly — construction, hardware, regulated work — Waterfall's rigidity is worth what it costs, and PRINCE2 adds formal governance where accountability and an audit trail matter as much as delivery.
• Requirements will move as users react to what you build — Agile fits better than a fixed plan. Pick Scrum if the work chops into a backlog and the team can commit to a sprint cadence; pick Kanban if work arrives unpredictably, like a support queue.
• A process repeats and waste is the enemy — bring in Lean principles alongside whichever cadence you've chosen; Lean isn't a rival to Scrum or Kanban, it's a lens applied inside either one.
• There's a real network of dependent tasks, whatever else is running the project — compute the critical path. It costs nothing and tells you the earliest finish date and exactly which tasks can't afford to slip.
• Several projects share one scarce pool of people or equipment, and multitasking is visibly costing you time — that's the case critical chain was built for; it demands more discipline than plain CPM and isn't worth it for a single, simply-resourced project.

None of these are mutually exclusive, and effective teams borrow freely across them: PRINCE2 governance around Scrum delivery, Lean principles inside a Kanban board, a Gantt chart built on the critical path method whether Waterfall or Agile runs the work above it. The real mistake isn't picking "the wrong one" — it's adopting a methodology because it's fashionable and forcing the work to fit it, instead of starting from how the work actually behaves. Whichever combination you land on, turning it into a working schedule — breaking the work down, sequencing it, estimating it, setting a baseline — is the same craft regardless; see how to plan a project for that walkthrough.

Frequently asked questions

Is Agile the opposite of Waterfall?

Not exactly opposites so much as different bets. Waterfall bets that you can specify requirements correctly upfront and plans a fixed sequence around that bet; Agile bets that requirements will change and builds iteration and feedback in from the start. See our full Agile vs Waterfall comparison for the detail.

What is the difference between Scrum and Kanban?

Scrum works in fixed-length sprints with defined roles and ceremonies around a single backlog. Kanban is continuous flow controlled by work-in-progress limits, with no fixed iteration at all. Scrum suits stable teams delivering on a cadence; Kanban suits work that arrives unpredictably with shifting priorities.

Can PRINCE2 and Agile be used together?

Yes — this is common enough to have its own name, PRINCE2 Agile. PRINCE2 supplies the governance layer (stages, business case, roles, formal sign-off) while Scrum or Kanban runs the actual delivery work underneath it.

Are the critical path method and critical chain full project management methodologies?

Not in the same sense as Waterfall, Agile, or PRINCE2. Both are scheduling techniques for analysing a network of dependent tasks, and both slot in underneath whichever broader methodology is actually running the project.

Do I have to choose just one methodology?

No, and most effective teams do not. It is common to run PRINCE2 governance around Scrum delivery, apply Lean principles inside a Kanban board, or schedule a Waterfall plan with the critical path method underneath it. Pick the combination that matches how the work actually behaves.