From spreadsheets and swivel-chair work to operational clarity.
One worked example, end to end. The Problem we'd hear, the Capability we'd design, the Outcome we'd commit to, and the Benefit Realization Plan we'd sign.
The problem. The finance function is running on spreadsheets.
The finance team knows the month-end close takes eleven business days. They've averaged it over six quarters — someone counted the calendar, not a system. The forecast has been ±35% off actuals for the past four quarters, not because the team is poor at forecasting, but because the inputs are assembled by hand from three disconnected sources every month.
This is not a technology problem. It's a traceability problem. The business has the data; the data has no path to the decision. The close is eleven days because nobody has ever owned the problem with enough specificity to redesign it.
This is what a Problem Register names. Nine problems in the language the business already uses, each traced to the capability that would retire it, plus one raised and refused. Nine problems don't become nine tools. They converge into five capabilities, and those into four committed outcomes.
That thread is highlighted in blue across all three exhibits below — one clean line to follow while the full set converges around it.
| ID | Owner | Felt cost | Current workaround | Named outcome |
|---|---|---|---|---|
| P-01 | FP&A lead | Forecast variance averages ±35% over four quarters. The forecast meeting is the argument. | Rebuilt by hand each month from CRM exports, controller estimates, and last quarter's actuals. | Forecast variance under ±10%, rolling six months. |
| P-02 | Controller | CRM and accounting hold different customer numbers. Neither is fully trusted. | Cross-checked from memory; reconciled by hand whenever they diverge. | One trusted set of customer numbers across systems. |
| P-03 | Controller | Month-end close runs eleven business days. Past the 10th. Decisions in weeks 1–2 rest on stale data. | Manual sign-offs chased across the team each period. | Month-end close in four business days. |
| P-04 | Controller | Five subledgers reconciled by hand every close. | Spreadsheet reconciliations on the controller's laptop. | Reconciliations off the critical path; close holds at four days. |
| P-05 | Controller | The close calendar has no owner's view. Status is a guess until someone asks. | Calendar kept as a Google Doc, chased over email. | Close calendar owned; signed pack ready day five. |
| P-06 | Treasurer | Cash position takes two business days to verify. Short-term borrowing stays conservative. | Daily manual export from three banks into a spreadsheet. | Cash position verified within the hour. |
| P-07 | Treasurer | AR aging reconciled by hand. Collections work largely blind. | Manual aging reconciliation against AR/AP each week. | AR aging current; collections work from live data. |
| P-08 | CFO | Board pack assembled from three disconnected sources every month. | Hand-built deck, numbers re-keyed from each system. | Board pack from one source, not three. |
| P-09 | COO | Operational metrics lag a week behind the business they describe. | Weekly manual report pulled from each function. | Operational metrics current — same-day. |
| P-10 | COO | Raised during elicitation, then scope-gated out by the architect when the named outcome couldn't be measured under the engagement's review-trigger window. | Scope-gated out | |
The capability. Five capabilities, sequenced in one direction.
The dependency runs one direction. Phase 1 sets the spine: master-data alignment and the month-end close everything else reads from. Phase 2 builds forecasting and cash visibility on top of it. Phase 3 closes the loop with reporting. The close (C2) is the spine. Follow it highlighted through each exhibit.
Set the spine
Master data and the month-end close — the foundations everything else reads from.
Build on the spine
Forecasting and cash visibility — workflows the Phase 1 spine makes possible.
Close the loop
Board and operational reporting, current across the new system.
A Benefit Realization Plan, illustrated.
Each outcome gets a lagging metric, a baseline, the leading indicators we watch, a named owner — and a review trigger. The trigger is the gate: cross it, and the engagement stops to be re-examined.
| Outcome | Lagging metric | Baseline | Measured | Review trigger | Owner |
|---|---|---|---|---|---|
| Move cash position to real-time | Elapsed time from latest cash transaction to verified position, sampled across treasury inquiries. | Two business days to verify; AR aging reconciled by hand. | Phase 1 + 30 days | Verification exceeds four hours for two consecutive days, or AR auto-reconciliation drops below 90%. | Client treasurer + CF architect |
| Compress month-end close | Business days from period end to signed close pack, from the close calendar and approval workflow. | Eleven business days, averaged across the prior two quarters. | Phase 2 + 90 days | Close duration exceeds six business days for any single period in the first two quarters post-go-live. | Client controller + CF architect |
| Tighten forecast accuracy | Absolute variance between published monthly forecast and GL actuals, rolling six-month window. | ±35% variance across the prior four quarters; rebuilt by hand monthly. | Phase 3 + 6 months | Variance exceeds ±15% for two consecutive months, or publication lag exceeds two business days post-close. | Client FP&A lead + CF architect |
| Bring operational reporting current | Lag between period activity and the operational report that reflects it, sampled weekly. | One week behind; metrics hand-pulled from each function. | Phase 3 + 60 days | Reporting lag exceeds two business days for two consecutive weeks. | Client COO + CF architect |
The plan is the commitment, not the pitch. It's instrumented and signed before the first sprint — every metric sourced from a system, every trigger a real stop. The review trigger is the tolerance gate, not the target — e.g. forecast variance targets ±10%, and the ±15% trigger is the line that, if crossed, pauses the engagement for review.
Friday demo log. Six weeks of cadence proof.
A Friday demo is the unit of the engagement. The log is the durable record: date, what was shown, who saw it. Demos aren't status reports — they're the moment the work either earns the next sprint or doesn't.