Topic
Delivering Enterprise Finance Systems
How complex finance-systems work actually gets delivered: turning vague demands into clear, reviewable decisions, defining problem, outcome, scope and ownership, and getting through fit-gap, UAT, cutover and hypercare without losing control.
This is the thinking behind Delivery Sheet, grounded in leading real finance-transformation programmes.
27 articles · ~120 min, in 6 sections — each in reading order
Foundations
1 article · ~6 minAgile vs Waterfall for Finance-Systems Delivery
How to choose a delivery approach for finance systems — why pure agile strains against a hard cutover, and why a hybrid spine usually wins.
Intake
5 articles · ~20 minProject Intake Process for Finance and Engineering Teams
How a team receives, shapes and decides on incoming work before committing people: the stages, the fields that matter, and four honest decisions.
Problem Statements vs Solution Requests
A solution request tells you what to build; a problem statement tells you why. Converting solutions back to problems is the highest-leverage move in intake.
How to Define a Measurable Outcome
A measurable outcome states what will be true when the work is done, in a way you can verify — a result, not an activity. How to write one, and the traps.
How to Write Scope In and Scope Out
Scope defines what work includes and — crucially — excludes. The 'out of scope' list is the half that prevents scope creep. How to define it from the outcome.
How to Write Good Requirements for Finance Systems
How to write good requirements: state what the system must do, clearly and testably, without prescribing the solution. Bad requirements are why delivery fails.
Execution
13 articles · ~65 minFit-Gap Analysis for Finance Systems
A fit-gap analysis compares what a standard system does against what the business needs — fit, gap, or change the process. Avoiding the customization trap.
Solution Design and Blueprint for Finance Systems
How to turn agreed requirements into a signed solution design before build starts — and why skipping the blueprint is what quietly buys you months of rework.
Configuration vs Customization in Finance Systems
Configuration fits your process using shipped settings; customization builds bespoke — a permanent liability paid at every upgrade.
Testing Strategy for Finance Systems: SIT, UAT, Regression
A testing strategy defines how you prove a finance system works before go-live — unit, SIT, UAT and regression. In finance, the numbers must reconcile too.
Decision Log & Change Control for Finance Systems
Finance-system projects fail on forgotten decisions and uncontrolled change. Running a decision log and change control: choices traceable, changes deliberate.
User Acceptance Testing for Finance Systems
UAT is where the people who'll use a finance system verify it does what they need, with real scenarios and reconciling numbers. Why finance UAT is different.
Finance Systems Environment Strategy: Dev to Prod
How to design the environment landscape for a finance-system rollout — Dev to Prod — what data lives where, how config is promoted, and who owns each gate.
Test Data Management for Finance-System Projects
Tests are only as good as their data. How to build test data for a finance-system rollout — representative volume, edge cases, anonymization, golden datasets.
Cutover and Go-Live for Finance Systems
Finance system cutover is the tightly-planned transition from old to new — migration, switchover, go-live — in a short, high-stakes window.
Data Migration for Finance Systems
Finance data migration — extract, cleanse, map, load and reconcile into a new system — is the riskiest part of a cutover. Source data is always dirty.
Defect Triage & Exit Criteria for Finance Go-Lives
How to run defect triage on a finance-system project: severity vs priority, blockers, accepted defects and workarounds, and the exit criteria that gate go-live.
Change Management for Finance System Rollouts
A technically perfect finance system fails if the team won't adopt it. Change management wins that adoption — why finance resists, and how to get it.
Operational Readiness & Acceptance for Finance Systems
Passing go-live isn't being ready to run. How to prove operational readiness — support, monitoring, runbooks, ownership — and get acceptance before handover.
Post Go Live
2 articles · ~10 minHypercare and Post-Go-Live Stabilization
Hypercare is the intensive, time-boxed support period right after go-live — and cutting it to save money is a false economy that moves the cost downstream.
Benefits Realization for Finance Systems
Benefits realization confirms a system actually delivered the outcomes it was justified on — not just that it went live. The step almost everyone skips.
Governance
2 articles · ~11 minRAID Logs: Risks, Assumptions, Issues and Dependencies
A RAID log tracks a programme's risks, assumptions, issues and dependencies — and works only when you actually mitigate and chase them, not file them.
Governance and Steering for Finance Programmes
Programme governance steers a large finance-systems programme — the decision structure, cadence and escalation. Good governance keeps a big programme unblocked.
Field Notes
4 articles · ~8 minThe friction tax on finance teams
Finance teams move slowly not because the math is hard, but because every number has to be defended. The real bottleneck is provenance, not compute.
Why teams commit before the request is clear
The pressure that turns a one-line ask into a commitment before anyone knows the scope — and the bill that shows up weeks later.
Turning a Slack request into a decision-ready initiative
How to take a one-line ask and shape it into something a team can commit to (or decline) in a few minutes, not a few meetings.
The cost of unclear ownership in enterprise delivery
When no one owns the outcome, delivery slips in the seams — invisibly on every status report, until it's too late to fix cheaply.
Free tools for this topic
Frequently asked questions
What is a project intake process?
A project intake process is the defined way a team receives incoming requests, shapes them into something clear enough to decide on (problem, outcome, scope and owner), and then makes an explicit decision: commit, shape further, pause or decline. It sits before delivery and before commitment, and its job is to turn vague demands into decisions rather than letting work start on a half-understood ask.
Full article →What is a testing strategy?
A testing strategy is the plan for how a system's correctness will be proven before go-live — which layers of testing will run (unit, system integration testing, user acceptance testing, regression, and often performance), what each layer proves, what data they use, and the entry and exit criteria for each. It ensures testing is deliberate and complete rather than an ad hoc scramble, and that the different kinds of defect — component bugs, integration failures, wrong business outcomes, and breakages of existing function — are each caught by the layer designed to find them.
Full article →What is user acceptance testing (UAT)?
User acceptance testing is the phase where the people who will actually use a system verify it does what they need, using real business scenarios — the final check before go-live that the system is fit for purpose, not merely technically working. Unlike system or technical testing, which confirms the software functions as built, UAT confirms it solves the business problem, and it ends in an explicit sign-off from an accountable business owner.
Full article →What is cutover in a system implementation?
Cutover is the tightly-planned transition from the old system or process to the new one — migrating the data, switching over, and going live — usually within a short, high-stakes window. It's the sequence of steps that takes you from 'the new system is built and tested' to 'the new system is live and the old one is retired,' and it's governed by a detailed runbook of tasks, timings and owners.
Full article →What is the difference between SIT and UAT?
System integration testing (SIT) verifies that the connected systems work together correctly — that interfaces move data intact between the ERP, the TMS, the banks and other systems, end to end. It's a technical test of the integrated landscape. User acceptance testing (UAT) verifies that the system does what the business actually needs, run by the real users against real scenarios. SIT proves the plumbing works; UAT proves the result is fit for purpose. You need both — a system can pass UAT in isolation and still fail because an interface silently drops data.
Full article →Follow the build → — one practical finance-systems pattern, product decision or build lesson every two weeks.