When ERP freelancing works, and when it ends your reputation

Freelancing on ERP implementations differs from every other kind of freelance work in three respects: the project runs for months rather than days, the responsibility does not end at delivery, and failure does not leave an unhappy client — it leaves a company that cannot issue an invoice.

Which makes the real question not “how do I start freelancing?” but “am I ready to be the only person anybody can call when the business stops?”

Four conditions before going independent

Not advice. Anyone missing one of them starts with a project they will damage.

Condition	The honest minimum
Go-lives lived through end to end	At least three, from analysis to the first close
Two cycles you handle unaided	One of them finance
The ability to diagnose alone	There is no senior colleague to ask any more
Cash to cover months	The first payment is always late

The first condition is the dividing line. Someone who has performed tasks inside other people’s projects has not yet seen what happens when modules collide — and that is precisely what is being bought when they work alone.

Where an individual actually gets work — and where they do not

The market allocates work on a clear logic, and anyone ignoring it competes where they cannot win.

Works well in: small and mid-sized companies not served by a large partner at large-partner prices; short, bounded pieces of work — a report, an integration, a data migration; ongoing support after a go-live somebody else delivered; and rescuing a stalled implementation, which pays the most and is the hardest.

Does not work in: companies that require a certified partner; projects needing a team working in parallel roles; and any environment that mandates a formal accreditation for the implementing party.

An individual who competes with implementation partners for their projects loses twice. Usually they lose the tender. Occasionally they win something they cannot deliver alone, which is the worse outcome.

Pricing — the mistake everybody makes once

Charging by the hour on an implementation.

The effect is that every question from the client becomes an argument with a meter running, and your interest is explicitly opposed to theirs: the faster you work, the less you earn.

What works instead:

• A fixed price against a precisely written scope — only viable if the scope really is written.
• Stages with defined deliverables — a payment at each acceptance, and the fairest arrangement for both sides.
• A monthly support retainer — the only recurring income in this profession, and the most valuable thing you can build.

The rule that protects both parties: what is in scope is delivered at its price, and what falls outside it is priced separately without apology. The phrasing for that conversation is in the skills nobody teaches.

The projects to refuse

The ability to refuse is the difference between an independent who grows and one who burns out in two years.

Four signals to decline on:

• A client with no named decision-maker. A project without an owner extends indefinitely.
• A go-live date fixed before the scope was known.
• Chaotic data plus a refusal to allocate time to cleansing it — set out in data migration.
• A demand for heavy customisation to reproduce the old system entirely — that is a software development project wearing an implementation label.

Refusing one of these four is cheaper than accepting it at twice the price. A failed project of this kind does not only cost you its time; it costs you a negative reference in a small market where everybody talks to everybody.

The contract — four clauses you do not sign without

Independents concede this more readily than companies do, and pay for it alone.

Scope stated as deliverables, not intentions. A list of what is delivered, and an explicit sentence covering what it does not include.

The client’s data is the client’s responsibility. Cleansing and sign-off on accuracy from their side. Without that clause, errors in their files become your errors.

A written definition of the end of the project. What drains independents most is a project that has been “nearly finished” for four months.

Post-delivery support, with a duration and a price. Anything not priced is requested free, forever.

What to do today

• Measure yourself honestly against the four conditions and name what is missing.
• Choose your position in the market from the “works well” list, and do not compete where you cannot win.
• Write a scope template and a staged quotation template before your first client, not after.
• Write down your four refusal criteria, and hold to them at the first test.

Where to go from here

The three go-lives are built inside a job before independence, not after it. The ways in are in your first ERP job and the roles in ERP implementation roles.

Most of what you will be called in to repair is described in why ERP projects fail, and the logic of pricing starts from understanding what things actually cost, which lives in the cycles: procurement, inventory and the ledger and the close. The full path is on the learn ERP page, and the products with their markets are in the systems comparison.