Topic
Delivering Enterprise Finance Systems
Finance systems delivery is the work of getting an ERP, treasury or finance application from a vague demand to a system the business actually runs on: intake, scope and ownership, fit-gap and design, testing and UAT, cutover, hypercare and governance. Control is usually lost early — in a request nobody clarified, an outcome nobody defined, a decision nobody owned — long before the technology gets a chance to fail.
This hub follows that path in the order a programme meets it: turning a request into a reviewable decision, executing through fit-gap, build, test and go-live, then stabilising and governing what shipped. Start with the intake process, or jump to execution if you are already mid-programme. It is the thinking behind Delivery Sheet, grounded in leading real finance-transformation programmes.
26 articles · ~116 min, in 6 sections — each in reading order
Foundations
1 article · ~6 minThe delivery approach itself — agile, waterfall or a hybrid spine — chosen before intake, because it shapes everything that follows.
Agile 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 · ~19 minTurning a request into something reviewable: the intake process, problem statements vs solution requests, measurable outcomes, scope in and out, requirements.
Project 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
12 articles · ~60 minFit-gap, solution design, configuration vs customisation, then testing (SIT, UAT, regression), environments, test data, cutover, defect triage, readiness.
Fit-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.
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 minAfter the go-live: hypercare and stabilisation, then benefits realization — checking the programme delivered what the business case promised.
Hypercare 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 · ~13 minThe programme controls: RAID logs (risks, assumptions, issues, dependencies) and governance and steering for finance programmes.
RAID 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 minShorter notes on why finance work stalls: the friction tax, committing before the request is clear, turning a Slack ask into an initiative, unclear ownership.
The 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
Also from me: Delivery Sheet — Turn vague leadership asks into clear, reviewable delivery decisions — before your team commits.
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 →Work with me → — the workflows this hub documents are exactly the kind I redesign with AI: slow, manual, exception-heavy, and still answerable to a control review.