Each module had a stakeholder who could say no.
Three separate groups, each expert in their own domain and each with legitimate authority over it. Any one of them could hold a release, and none of them could approve on the others' behalf.
Enterprise · ERP · 2022 — 2025
Three ERP modules, three sets of owners, one backlog.
An enterprise ERP spanning HR, Finance and Inventory — where every module has its own stakeholders, its own process logic and its own veto. I owned the backlog and process flows across all three, managed the API and third-party integrations between them, and ran sign-off module by module rather than betting the programme on one big approval.
- 3
- Modules owned — HR, Finance, Inventory
- 1
- Backlog across all three, not one per module
- Module
- By-module sign-off, not one programme-wide approval
- Integrations
- API and third-party connections owned across modules
Executive Summary
A multi-module ERP is a stakeholder problem wearing a software costume.
HR, Finance and Inventory each have their own owner, their own process logic, and their own ability to block a release. The software difficulty is real, but it is not what makes these programmes fail.
What makes them fail is a single programme-wide approval at the end, where three groups review everything at once and every objection lands simultaneously with no room left in the schedule.
I owned the backlog and the process flows across all three modules, managed the API and third-party integrations that connect them, and ran client sign-off module by module — so objections arrived while they were still cheap to act on.
At a glance
- Role
- Product Owner / Project Manager
- Product
- Versa Cloud ERP
- Modules
- HR, Finance, Inventory
- Owned
- Backlog, process flows, integrations
- Governance
- Module-by-module client sign-off
- Method
- Agile delivery, RAID-managed
Section 02 — The Problem
Three modules, and every dependency crosses a boundary.
The integrations sit exactly where the ownership does not.
Payroll touches Finance. Stock movements touch both. The connections between modules belong to nobody in particular, which is precisely why they need a single owner.
Everyone knows their process. Almost nobody has written it down.
Undocumented process logic is fine until two modules disagree about it. Then the disagreement surfaces in QA, as a defect, rather than in definition, as a conversation.
Section 03 — Research & Discovery
Requirements gathering was really process archaeology.
Most of the discovery work was getting existing processes out of people's heads and onto paper in a form all three groups could review. Business needs were translated into functional specifications and process flows — which sounds like documentation, but is mostly negotiation.
The value is in what the writing exposes. Two modules describing the same step differently is invisible in conversation and obvious on a page.
Each module described its own process, in its own words, first.
Gathering all three groups in one room at the start produces consensus theatre — the loudest domain wins and the others stay quiet. Documenting each module separately, then comparing, surfaces the disagreements while they are still cheap.
Contradictions were treated as requirements, not errors.
Where two modules described the same step differently, neither was wrong — they were describing the same event for different purposes. Each of those became an explicit reconciliation rule in the process flow rather than an argument to be settled.
Section 04 — Current State Analysis
What each module needed, and where they touched.
ModuleScope ownedTouchesSign-off
HRProcess flows, backlog itemsFinance (payroll)Module owner
FinanceProcess flows, backlog itemsHR, InventoryModule owner
InventoryProcess flows, backlog itemsFinance (valuation)Module owner
IntegrationsAPIs, third-party connectionsAll threeNamed owner per seam
Section 05 — Competitive Research
Enterprise buyers compare against what they already run.
Nobody evaluates an ERP against an abstract ideal. They evaluate it against the system their finance team has used for a decade and the workarounds they have built around its limitations — which means familiar module boundaries are worth more than better ones.
Where an established convention exists for how HR, Finance and Inventory divide responsibility, following it lowers the training cost and the objection count. Divergence has to earn its place, because every difference is something a stakeholder has to be argued into.
Conventional module boundaries were kept on purpose.
Finance owning the ledger and HR owning the employee record is not an arbitrary split — it matches how the teams are organised and audited. Keeping it meant training cost stayed low and objections stayed rare.
The seams got an owner the convention does not provide.
Standard ERP boundaries define what each module owns and leave the crossings implicit. Naming an owner for every integration was the deliberate addition, because that gap is exactly where these programmes fail.
Section 06 — Key Insights
Three things that kept three modules moving together.
One backlog, not one per module.
Three backlogs make cross-module dependencies invisible until they bite. A single ordered list forces the sequencing conversation to happen in planning rather than in a release.
Sign off in pieces so objections arrive early.
Module-by-module approval means each group reviews its own domain while there is still schedule left to respond. One programme-wide sign-off concentrates every objection into the worst possible week.
The integration needs an owner or it gets one by accident.
Work between two modules belongs to neither team by default. Naming an owner for it is the difference between a managed dependency and a surprise.
Section 07 — Design Strategy
Four rules for running three modules at once.
One backlog across all three modules.
Cross-module dependencies only stay visible if the work sits in one ordered list.
Write the process flow before the requirement.
Two groups describing a step differently shows up on a page and hides in a meeting.
Sign off module by module.
Objections arrive while the schedule can still absorb them.
Every integration has a named owner.
Otherwise the space between two modules belongs to nobody until it breaks.
Section 08 — The System
Every backlog item belongs to a module and declares its reach.
Module-local
Sits entirely inside HR, Finance or Inventory. One owner, one sign-off, no coordination cost.
Cross-module
Touches more than one module. Needs a named owner for the seam and agreement from both sides before build.
Integration
Reaches an API or third-party system. Carries external dependency risk and is tracked through RAID.
Classifying work this way is what makes a single backlog across three modules workable. The label determines who has to agree before it is built and how much coordination the estimate needs to carry.
Section 09 — The Features
What actually shipped.
Platform
Enterprise ERP delivered across HR, Finance and Inventory.
Backlog and process flows owned across all three modules, with client sign-off secured module by module through the build.
Integrations
API and third-party connections managed as first-class work.
The connections between modules and to outside systems tracked with named owners and governed through RAID rather than left to emerge during integration testing.
Section 10 — User Flow
A flow that crosses a module boundary is where the work actually lives.
The transaction originates inside one module.
Payroll starts in HR; a stock movement starts in Inventory. One owner, uncontroversial so far.
It crosses into a second module that values it differently.
Finance does not care about the HR record — it cares about the ledger entry. The two descriptions of the same event have to be reconciled explicitly.
Ownership of the seam is named before build.
Classified as cross-module work, which requires agreement from both sides rather than a decision by whichever team gets there first.
Both module owners sign off on their side of it.
The step that stops a cross-module flow being approved by someone with authority over only half of it.
Payroll is the crossing worth drawing first, because every stakeholder already has an opinion about it. Getting agreement there sets the pattern the other crossings can follow, and disagreement there surfaces the reconciliation rules the whole programme depends on.
Section 11 — End-User Experience
ERP users do not choose the software. That changes the job.
Nobody in HR or Finance picked this tool, and most of them will use it every working day for years. That removes delight as a goal and replaces it with something harder: not costing someone time on a task they perform two hundred times a month.
That is why module-by-module sign-off does double duty. It is a governance mechanism, but it is also the only structured moment where the people who will live in the software daily get to say whether it fits how they actually work.
Section 12 — Impact & Outcomes
Three modules delivered with sign-off held throughout.
- 3
- Modules delivered — HR, Finance, Inventory
- Module
- Sign-off secured per module, not deferred to the end
- Integrations
- API and third-party connections in place across modules
The outcome here is structural rather than numeric: three modules delivered, integrations in place, and client approval held module by module rather than gambled on a single review at the end.
Programme metrics are not published, so none are claimed. The number that would settle the argument is sign-off cycles per module — if by-module approval works, objections concentrate early and the final review is quiet, which is precisely the opposite of how these programmes usually end.
Section 13 — Reflection
What I would do differently, and what is still open.
Name the integration owners at kickoff, not on contact.
Cross-module ownership got resolved as it came up, which worked but reacted rather than anticipated. Assigning the seams at the start would have cost one meeting and saved several.
Module-by-module sign-off optimises for approval, not coherence.
Approving each domain separately gets objections early, but nobody reviews the whole system as one experience. Whether the three modules feel like one product to somebody who uses all of them is a question the sign-off structure does not ask.