What large implementations teach you.
Four series on the craft of enterprise programs — how you carry the work, how the systems behave, where the numbers land, and everything that isn't the software. Written in the firm's voice, from the work itself.
Series 01
The long program
How you carry a long, contested, multi-party program — from the first decision to the go-live nobody is sure of.
5 pieces
The long program
How you carry a long, contested, multi-party program — from the first decision to the go-live nobody is sure of.
Lead the room, don't rule it
Earned authority on an implementation: lead, listen, and be decisive without becoming the bottleneck every decision has to route through.
Drift is not progress
Scope creep is rarely a decision. It's the slow, unchosen expansion that quietly turns a sharp project into a long one.
Start small, grow on purpose
The discipline of deliberate incrementalism: ship something small that works, then build on it by choice rather than by drift.
There's never a right answer, only the right questions
On a large program, the answer is rarely the scarce resource. Knowing what to ask, and who to ask, is.
Doubt loses to a shared goal
What actually steadies a room before a go-live: confidence built on a goal everyone shares, not a feeling summoned on demand.
Series 02
What systems understand
The handful of truths an ERP and its integrations actually obey, whatever dialect you make them speak.
4 pieces
What systems understand
The handful of truths an ERP and its integrations actually obey, whatever dialect you make them speak.
An ERP only understands what reconciles
Strip away the modules and the screens and an ERP understands one thing: a posting that balances. Every dialect it speaks resolves to that.
A good integration runs twice
Idempotency in plain terms: a retry that never double-posts, and a failure that recovers without turning into a cleanup project.
Two systems, one customer
Master data and translation tables: why value leaks at the exact seam where one system's customer is another system's account.
AI drafts the numbers, the ledger owns them
Deterministic math as a discipline: AI can draft and check, but the dollars are calculated in SQL, never guessed.
Series 03
Where the numbers land
What configuration and integration choices do to the financials downstream — reconciliation, reporting, the close, and audit readiness.
5 pieces
Where the numbers land
What configuration and integration choices do to the financials downstream — reconciliation, reporting, the close, and audit readiness.
Reconciliation is not a checkbox
What won't tie out is the system telling you something true. Treat a break as a finding, not a formality.
A posting rule is an accounting policy
Account determination and posting logic are accounting decisions in technical clothing. Finance should own them, not inherit them.
Reporting can't fix what posting broke
Dashboards inherit every upstream shortcut. A wrong number is usually a mapping decision, not a BI bug.
The close is where shortcuts come due
Month-end exposes every compromise made during config. A clean close is designed in, not forced at the deadline.
Auditors read your configuration
Controls live in the system, not the binder. “Audit-ready” is a configuration choice.
Series 04
Everything that isn't the software
The disciplines that decide a program and have nothing to do with configuration — people, stakeholders, vendors, resourcing, and the constraints you can't remove.
5 pieces
Everything that isn't the software
The disciplines that decide a program and have nothing to do with configuration — people, stakeholders, vendors, resourcing, and the constraints you can't remove.
Lead the people you don't employ
On a program, most of the people you depend on don't report to you. Authority is borrowed; influence is the instrument.
Alignment is not agreement
Stakeholders want genuinely different things. Alignment isn't agreement — it's making the tradeoff explicit and committing to it.
The vendor is solving for the contract
A vendor optimizes for its contract, not your outcome. Manage to outcomes and write the incentive you actually want.
More people is not more progress
Throughput is governed by one constraint at a time. Staffing everywhere but the bottleneck just makes it busier.
The constraint is the design
The fixed date, the capped budget, the system you can't touch — not obstacles to the design, but its parameters.
Running a program that should reconcile and doesn't?
Tell us what you are running and where it breaks. We'll give you a straight read on fit, and the questions worth asking first.