Most of the work in an ERP project is not software. It is writing down how a company already operates, finding the places where two departments have been quietly disagreeing for years, and getting someone with authority to settle them. The code follows from that. When a project fails here, it is almost never because the developers could not build a screen.
This is what the work actually consists of, and what moves its cost.
The four drivers
How much of the business it covers. This is the big one, and it is the one most under your control. A single workflow — say, material issue and consumption against a production order — is a small piece of work. The same factory running stock, purchase, production, accounts and payroll on one system is a different project by an order of magnitude. The first release does not have to cover everything, and the companies that get the most out of these systems usually start narrow.
How many people use it, and in what conditions. Twelve people in one office is not the same build as two hundred across a factory floor, three outlets and a field team on phones. More people means more roles, more permissions, more screens that have to tolerate being used badly at the end of a shift, and training that is real work rather than a handover note.
What it has to connect to. A bank's disbursement format. A fingerprint attendance device. bKash or Nagad collections. The accounts package your auditor refuses to give up. Each connection is a piece of work in its own right. The ones with a documented interface are predictable; the ones where we have to exchange files on a schedule because the vendor has no API cost more and take longer, and you should be told which is which before the quote is signed.
How tight the date is. A deadline does not raise the price by itself. What it does is decide how much fits inside the first release. A very short date sometimes means more people working in parallel, which does raise cost — and there is a limit past which adding people makes a project slower, not faster. The honest response to an immovable date is to cut scope, not to promise the same scope faster.
What you have to supply
Every stage needs something from the client that cannot be bought:
- Access to the people who do the work. Not the department head's account of how it runs. The storekeeper, the accountant, the person who chases payments — and permission for them to be honest about the workarounds, because the workarounds are the requirements.
- One person who can settle a disagreement. At some point purchasing and accounts will want incompatible things. If nobody can decide, the build stalls, and the stall is usually blamed on the supplier.
- Someone who opens the weekly build. Correcting a module while it is being written is cheap. Correcting it after a year of data is in it is not. A weekly look is not a demonstration; it is the mechanism that keeps the two in step.
- Your existing records, however messy. The spreadsheet with the yellow column, the register, the exported trial balance. Cleaning them is part of the project, but they have to arrive first.
The migration is the risky part
Moving records is where implementations go wrong in a way that is expensive to undo. Your opening stock, your customer list, your outstanding balances and your ledger all have to arrive in the new system in a state you are willing to sign off, and some of them will disagree with each other on the way in.
Two things make this survivable. First, someone on your side has to be available to say which of two conflicting rows is the real one — that judgement cannot be delegated to the supplier. Second, the old system and the new one should run side by side through at least one full closing before the old one is switched off. If they disagree, you find out while there is still something to compare against.
Anyone who proposes a hard cut-over with no parallel run is optimising for their own schedule.
Why nobody can quote you from an email
A two-line brief — "we need an ERP for a 60-person factory" — does not contain any of the four drivers above. A figure produced from it is chosen to win the conversation, and it gets corrected later at your expense, usually as a change request in month three.
What you should expect instead is a written scope: what the first release contains, what it deliberately leaves out, which integrations are in and which are explicitly deferred, and what happens when you want something added. The figure sits against that scope. If the scope changes, the change is quoted on its own rather than absorbed quietly and recovered somewhere else.
What "done" means
It does not mean go-live. The week a system goes live is the week it starts being tested properly, because people who were not in any of the meetings begin using it. Plan for a support period that assumes this, and ask directly: who answers the phone in month four, in what language, and at what response time.
If a supplier cannot answer that question concretely, the rest of the proposal is worth less than it looks.
If you want to work through the four drivers against your own operation, our pricing section sets them out in more detail, and there is a scope band tool in it you can use without talking to anyone.