Agile vs Waterfall for Finance-Systems Delivery

For finance-systems delivery, the honest answer to "agile or waterfall?" is almost always "both, deliberately." A finance programme has a hard cutover that behaves like waterfall whether you want it to or not, and a build phase that benefits enormously from iteration. The failures I've watched over eighteen years rarely come from picking the wrong method — they come from applying one method to the whole thing because it was the house religion, instead of choosing per phase with eyes open.

Before you argue methodology, it's worth being clear on what you're actually delivering and why — the same discipline that a good project intake process forces early. Method follows the work, not the other way round.

The two paradigms, honestly

Waterfall sequences the work into phases — requirements, design, build, test, deploy — each largely completed before the next begins. Scope is fixed up front, the plan runs to hard dates, and delivery lands as a planned big-bang cutover rather than a stream of small releases. Its strength is predictability and a clear, signed baseline; its weakness is that it assumes you can specify everything correctly at the start, and defers the moment of truth — does this actually work for real users? — all the way to the end.

Agile works the opposite way: iterative and incremental, delivering working increments frequently, with scope allowed to evolve as you learn. Requirements are discovered and refined rather than fixed, feedback comes early and often, and the plan adapts. Its strength is that it surfaces reality fast and lets you change course cheaply; its weakness is that "evolving scope" and "frequent delivery" are exactly the two things a hard external deadline and a reconciled ledger are least forgiving of.

Why finance programmes lean waterfall-ish at the macro level

Finance systems don't ship into a vacuum — they ship into a calendar. Month-end, quarter-end, year-end and regulatory dates are fixed by the outside world, and the programme bends to them, not the reverse. That alone pushes the macro shape toward sequenced phases converging on a chosen date.

Then there's the cutover itself. A general-ledger or close migration is inherently a planned event, not an iterative trickle. You move to the new system on a date, with a reconciled opening balance, and you cannot run half the ledger on the old system and half on the new across a single month-end and still reconcile it. Add the integration surface — a finance core touches sub-ledgers, treasury, tax, payroll, consolidation and reporting, and those interfaces have to be consistent at once — and the case for a controlled, coordinated cutover only hardens.

Finally, reconciliation and audit want a stable, signed baseline. Auditors check against a fixed set of numbers, and reconciliation compares old to new at a defined point. Continuously shifting scope under a live ledger is the opposite of what that assurance needs.

"

You cannot iterate your way into a live general ledger. The build that leads up to go-live can be incremental; the go-live is a controlled event with a plan, a rehearsal and a signed set of numbers.

Where agile genuinely helps — inside that spine

None of the above means the whole programme should be a two-year waterfall plan drawn once and marched to. Inside the build and test phases, iteration is where the real work gets de-risked.

Configuration and build are far better done iteratively — stand up a chart of accounts, a posting rule, a reporting hierarchy, show it to the people who'll live with it, correct it, move on. Delivering the solution as sprint-based increments means finance sees something real early instead of a specification they can't visualise. Early and repeated UAT matters more here than almost anywhere: finance users find the edge cases — the odd intercompany posting, the currency revaluation, the accrual reversal — that no requirements document ever captured cleanly. And that points at the deeper reason to iterate: on genuinely uncertain requirements, you discover what's needed by building and testing, because the users couldn't have specified it up front even with perfect intentions.

The realistic answer is hybrid

Put those together and you get the shape that actually works: a waterfall spine — design, build, test, one controlled cutover — with agile execution inside the build and test phases. The spine gives the finance and audit side the predictability, the coordinated cutover and the signed baseline they need. The iteration inside gives delivery the fast feedback and requirement discovery it needs. This isn't a compromise nobody wanted; it's the correct decomposition of a problem that genuinely has both characters.

The important word is deliberately. Decide per programme — and per phase within it — which character each part has, rather than adopting one label for the whole thing. That decision belongs in governance, made explicitly, not defaulted into by whichever method the delivery org happens to brand itself with. And whatever the method, you still owe the programme a measurable outcome it's steering toward — method is how you get there, not what "there" is.

Docs versus reality

The most expensive failure I've watched is "we're agile now" applied to a close-the-books migration. A team, proud of its transformation, treated a general-ledger cutover as something to release incrementally — and discovered at the worst possible time that you cannot half-migrate a ledger across a month-end and reconcile it. The opening balance has to be one reconciled number on one date. No amount of sprint velocity changes that; the close is an event, and pretending it's a backlog just moves the reckoning to the night of go-live.

The opposite failure is just as real and I've seen it more often than people admit. Rigid waterfall applied to genuinely uncertain requirements doesn't remove the uncertainty — it defers it. Every ambiguity you waved through in a design signed twelve months ago comes due in UAT, all at once, at the point in the plan with the least slack to absorb it. You didn't avoid the discovery; you postponed it to the most expensive moment to have it.

So the skill isn't picking a side. It's seeing which parts of a finance programme have a hard, event-shaped, baseline-hungry character — and running those as a spine — and which parts are genuinely uncertain and better discovered by building — and running those iteratively inside it. Get that decomposition right and the methodology argument mostly dissolves. Get it wrong in either direction and you pay, either on go-live night or in a UAT that was quietly loaded with a year of deferred questions.

Part of the Finance Systems Delivery guide. See also cutover and go-live for finance systems and governance and steering for finance programmes. The newsletter sends one finance-systems pattern every two weeks.