Six methods come up in almost every project management conversation: waterfall, the V-model, PRINCE2, Scrum, Kanban and Lean. They are not the opposing camps they are usually made out to be. They answer different situations, and what really separates them is one thing: what is fixed at the start, and what stays negotiable.
The traditional approach: decide everything, then execute
It is the oldest family, and still the most widely used. The project moves through ordered stages: definition, planning, execution, monitoring, closure. Each phase ends before the next begins.
What defines this family fits in one sentence: scope is fixed, time and budget adjust. The client knows what they want. You write it down, you price it, you build it.
The consequence follows directly. Going back is expensive, sometimes very expensive. The specification has to be solid before the first day of production, which assumes serious scoping up front.
The advantage is real and often forgotten: when the plan holds, overruns do not happen. A well scoped project executed in sequence ships on the announced date.
Waterfall: the original model
Waterfall is the pure form of the approach. Each phase depends entirely on the one before, and nothing flows back up.
Its rigidity has a name in the field: the tunnel effect. The client signs off a document in January, sees nothing for six months, and discovers the result in July. If their understanding of the need moved in between, nobody noticed.
It works well on small projects whose end product is known in advance. An office move, a compliance update, a build whose drawings are already approved.
The V-model: waterfall with tests
The V-model fixes waterfall's main defect: nothing gets verified until the end.
The project stops being a single block. It breaks into components. The descending branch repeats the waterfall phases, from requirements to build. The ascending branch validates each level in mirror image, through tests that involve the client.
Going back becomes possible, provided it stays local. You fix a component, not the architecture.
The V-model needs budget, a team that knows its trade, and a client able to state expectations and then sign them off in stages. It dominates industry and embedded systems, where a defect found late costs more than the entire test protocol.
PRINCE2: a governance framework, not a way of producing
PRINCE2 came out of the British public sector. PROMPT in 1979, renamed PRINCE in 1989, revised into PRINCE2 in 1996. The acronym stands for Project IN Controlled Environments.
It does not say how to build. It says who decides, on what criteria, at what moment. Three pillars: organisation, management, control. Seven processes, seven themes, seven principles, and a project board that authorises each stage.
That is useful when several entities are committed, when decisions have to be traceable, and when the question "who approved what" will eventually be asked. It is disproportionate for five people in one room.
PRINCE2 also combines with the others. Nothing prevents PRINCE2 governance sitting above teams working in Scrum.
The agile approach: fix the rhythm, not the content
The Agile Manifesto dates from 2001. Seventeen software practitioners, meeting in Utah, wrote four values on a single page.
- Individuals and interactions, over processes and tools.
- Working software, over comprehensive documentation.
- Customer collaboration, over contract negotiation.
- Responding to change, over following a plan.
The important word in those four lines is "over". The manifesto ranks, it does not delete. An agile project with no documentation and no contract is not agile, it is badly run.
The reversal is about what gets fixed. Here time and team are fixed, and scope adjusts. You work in short cycles, ship an increment at the end of each one, show it, listen, and correct what comes next.
That assumes a genuinely available client. It is the condition nobody writes into contracts and the one that decides the outcome. A client unreachable for three weeks turns a sprint into guesswork.
Scrum: the most widespread agile framework
Scrum organises work into sprints of one to four weeks. Three roles: product owner, scrum master, development team. A prioritised backlog, a review at the end of each sprint, a retrospective to adjust how the team works.
The framework is stricter than it looks. The ceremonies are compulsory, a sprint's scope does not move once it starts, and the product owner role assumes someone who actually decides.
Scrum suits projects whose content will change anyway, and where the team can ship something usable every two weeks. If the first workable deliverable arrives after six months, the framework runs empty.
Kanban: making the flow visible
Kanban means "signal card" in Japanese. The method comes from Toyota plants in the 1950s, where those cards triggered replenishment.
The principle fits on one board: columns for the stages of the work, cards moving from one to the next. Everyone sees where each task stands, without a meeting.
The rule most often dropped is the work-in-progress limit. A Kanban with no cap per column is a decorated task list. The limit is what reveals bottlenecks: when a column saturates, the problem becomes visible.
Kanban pairs well with other approaches. Plenty of teams run Scrum and visualise in Kanban. It suits continuous work, support, maintenance, anything that arrives without being planned.
Lean: removing what produces no value
Lean grew from the same Japanese industrial ground. Its subject is waste: waiting, rework, unnecessary movement, producing what nobody asked for.
The approach starts from the customer to define what counts as value, then works back up the flow to remove the rest. Problems get handled where they occur, with the people doing the work.
It is less a project method than a way of running an organisation. It needs commitment from management, and a culture where flagging a problem does not rebound on whoever flagged it.
Lean pays off best on processes that repeat from one project to the next. On a genuinely one-off project there is little identifiable waste, because there is no baseline to compare against.
What actually separates these methods
The dividing line is not agile against traditional. It runs through one question: what do you know at the start?
If the content is known and stable, a sequential approach delivers it faster and cheaper. If the content gets discovered as you go, an iterative approach avoids six months spent building something that will not be used.
Three factors weigh more than the choice of method itself: how available the sponsor really is, how experienced the team is, and what an error found late actually costs. A project whose client answers once a month will not be agile, whatever vocabulary gets used in the meetings.
What all these methods share
None of them excuses you from knowing what the project is made of.
Waterfall wants the breakdown before you start. Scrum wants it as you go, sprint after sprint. The moment changes, the work does not: identify the deliverables, understand what blocks what, estimate the durations.
That is why work breakdown structures and dependency networks outlive fashions and schools. They describe the project, not the way it is organised.
The Gantt chart shows the usual confusion well. It gets filed under traditional, when it is only a representation over time. The problem is how it is used: a Gantt drawn by hand with no dependency network behind it is a picture, and it goes stale within three weeks.
Structuring a project in Orchesia, whatever the method
Orchesia does not impose a method. It tools what they have in common.
The entry point is a mind map: the project breaks into objectives, then deliverables, then tasks. The breakdown is built with the team, on a view made for it. Whether you do it all up front or cycle by cycle, the tool is the same.
Then comes the dependency network. What blocks what is declared once, and the schedule follows from it. The critical path and the float are calculated, recalculated on every duration change, and tell you how far the date can slip.
Tracking then reads the way your team prefers: task list, Gantt, Kanban board, workload per person. These are views on the same structure, not four tools to keep in sync.
Two modes cover the two families. The structured mode starts from the content and computes the date. The simplified mode starts from an imposed date and works back up the chain, what we call backward planning.
Which leaves the question that decides everything, and that no software will settle for you: do you know, today, what your project has to produce? If you do, plan it. If you do not, iterate, and keep some room.
