Fixed-Fee vs Time-and-Materials: Who Really Carries ERP Project Risk

Most distributors evaluating an ERP replacement spend their energy on features. They build a requirements matrix, sit through six demos, and score the software. Then they sign a contract whose commercial structure they discussed for about twenty minutes — and that structure, not the feature matrix, is what determines whether the project lands near the number in the board deck.

There are really only two models here; everything else is a variation. Knowing which party carries the risk in each is the most useful thing a finance or operations leader can learn before a selection starts.

Two contracts, two different risk holders

Time-and-materials (T&M) means you buy hours. The vendor gives you an estimate — often a range, often labelled "for budgeting purposes only" — and then invoices for consultant time actually worked, plus expenses. If the work takes 900 hours instead of the estimated 600, you pay for 900. The estimate is not a commitment. It is a forecast, and forecasts are the vendor's opinion, not the vendor's obligation.

Fixed-fee means you buy an outcome. The vendor commits to delivering a defined scope for a defined price. If the work takes 900 hours instead of 600, the vendor absorbs the difference. The estimate is the commitment.

Everything else follows from that one difference. Under T&M, the buyer carries scope risk (the work turned out to be bigger than anyone thought) and estimation risk (the vendor was wrong about how long a known piece of work would take). Under fixed-fee, the implementer carries both. That is not a marketing distinction. It is a balance-sheet distinction, and it changes how both parties behave for the entire project.

A T&M estimate is a prediction. A fixed fee is a promise. Distributors routinely treat the two as interchangeable during selection, then discover the difference in month seven.

Why time-and-materials projects drift

T&M projects do not overrun because consultants are lazy or dishonest. They overrun because of three structural features that are present in nearly every one of them.

Discovery happens after the contract is signed

On a T&M engagement the vendor has no commercial reason to do deep discovery before you sign, and a strong reason not to: discovery costs money, delays revenue, and surfaces uncomfortable facts that slow deals down. So the real discovery — someone opening your item master, counting how many items carry an unvalidated unit-of-measure conversion, asking who actually owns pricing approval — happens in weeks four through ten, billed at the standard rate. Every surprise found in that window is one you pay to find and pay again to fix.

Change orders for things you assumed were included

The second driver is the gap between what a buyer heard in a demo and what the statement of work enumerates. A distributor sees customer-specific contract pricing working in a demo and assumes contract pricing is in scope. The SOW says "configuration of standard pricing functionality". Migrating years of negotiated price agreements out of a legacy system, reconciling the ones that conflict and testing them against live orders is not standard configuration. It is a change order. Nobody lied — the scope was simply never written down at the level of detail where the disagreement lives.

The incentive structure points the wrong way

This is the uncomfortable one. On T&M, more hours means more revenue. That does not make a vendor corrupt, but it removes the pressure that keeps a project tight. There is no commercial cost to a two-week detour, to a consultant learning your business on your dime, or to a "let's revisit that in phase two" conversation that quietly adds a phase two. Under fixed-fee every one of those decisions costs the vendor money, so the vendor argues about them — usually in the direction of finishing.

Where the risk actually sits

Written out side by side, the difference is easier to hold in your head during a negotiation.

Read the last row twice. Alignment of incentive is worth more over a nine-month project than any single line item in a feature comparison.

The honest case against fixed-fee

Fixed-fee is not magic, and any vendor presenting it as risk-free is selling you something. It carries three real limitations.

• It only works if scope was defined honestly. A fixed fee quoted against a vague scope is not protection — it is a delayed argument. The vendor prices the ambiguity in, or prices it out and fights you about it later.
• It contains a risk premium. Someone is carrying the uncertainty and charges for carrying it. A well-run T&M project with a disciplined buyer can finish cheaper. The question is how often that happens, and whether you want to bet the go-live on it.
• It makes mid-project change harder. A genuinely new requirement becomes a formal change with a price attached. That friction is the point — it protects the budget — but you cannot casually redirect the team in month five.

The corollary matters more than the objections: fixed-fee shifts work forward. The scoping effort that a T&M project defers until after signature has to happen before signature instead. And a meaningful share of that work is yours.

What you have to bring to scoping

If you want a fixed price you can trust, you have to make it possible to quote one. Five inputs do most of the work.

1. A data quality assessment, not a data inventory

Every distributor can produce a record count. Far fewer can say how many customer records are duplicates, how many items carry a unit-of-measure conversion that nobody has validated since the last system change, how many open POs have receipts that never matched, or which historical transactions actually need to come across versus which just feel unsafe to leave behind. Dirty data is the most common cause of migration overrun. Assess it early, and be willing to hear a bad answer.

2. An integration inventory

List every system that will exchange data with the ERP, and for each one name the direction, the frequency, the owner, and whether an API exists or somebody currently drops a CSV on a shared drive at 6am. EDI trading partners, freight rating, credit card processing, a warehouse system, a tax engine, a customer portal, the sales commission spreadsheet that three people depend on. The spreadsheet counts. It is always the spreadsheet that surfaces in week nine.

3. True customisations separated from preferences

This is the hardest internal conversation and the most valuable. A customisation is something your business genuinely cannot operate without and the software cannot do. A preference is a habit inherited from the system you are leaving. "Our customers require a specific carton label format under a supply agreement" is a customisation. "The order screen should have the fields in this order because that's where they've always been" is a preference. Preferences are where budgets go to die, because they arrive one at a time and each one looks small.

4. Named decision-makers with authority

Not a committee. For each functional area — finance, purchasing, warehouse, sales, IT — one named person who can decide on the call and have it stick. Projects stall in the gap between "we discussed it" and "someone decided", and under fixed-fee that stall costs the implementer margin. Which is exactly why the implementer will push you to name people up front.

5. A go-live window that respects your season

Every distributor knows their own peak. Do not cut over during it, and do not cut over in the four weeks before it either, because that is when you will still be stabilising. Pick your quietest window, work backwards, and treat the date as a constraint on scope rather than a wish.

Distributors who want to see how this scoping discipline maps onto a real implementation plan can walk through it with our team on the services page, or look at how the platform is organised across the wholesale distribution workflow before scoping starts.

How Centerprism prices implementations

Centerprism prices implementations as fixed-fee. That is our model — a statement about how we contract, not a claim about how anyone else does. We say it plainly because it explains why our sales process asks for more from you earlier than you may expect: the data conversation, the integration list, the customisation-versus-preference triage and the named-owner list all happen before a number is issued, because the number is a commitment and we intend to hold it.

It also explains why we are direct about what is out of scope. A fixed fee with a fuzzy boundary helps nobody. Where a requirement is genuinely new it gets priced as a change and you decide whether it is worth it — with the rest of the project still landing on the original number.

The functional side of that conversation is easier when you have read the module documentation in advance. Every module has a datasheet in the datasheet library, and the reporting layer most finance leaders ask about first is PrismView™ and business intelligence. Clients who have been through the process describe it in their own words on our testimonials page, and the thinking behind how the firm was built is on the founder story.

Ten questions to ask before you sign

Ask every vendor on your shortlist. Write the answers down. The pattern in the answers will tell you more than the demos did.

1. Is this price a fixed fee for a defined scope, or an estimate against hourly rates? Say which, in one sentence.
2. If the work takes 50% more hours than you estimated, who pays for the extra hours?
3. What discovery have you done on our data before issuing this number, and what did you find?
4. Which of our integrations are in this scope, named individually? What happens to one we forgot to mention?
5. Show me the list of customisations you have priced. Which items on our wish list did you classify as preferences, and why?
6. What is your change-order process, what triggers one, and what is the approval path before work starts?
7. Who specifically will be on our project — names, roles, and how many other clients they are serving at the same time?
8. What do you need from us, by when, and what happens to the timeline and the price if we are late?
9. What is your definition of go-live, and what support is included in the stabilisation period after it?
10. Give me two references who went through a scope dispute with you. Not two happy references — two hard ones.

Question ten is the one that separates vendors. Every implementer has had a project go sideways. The ones worth hiring can tell you what happened, what it cost them, and what they changed afterwards.

If you want to see what a fixed-fee scope for a distribution ERP actually looks like on paper, request a demo and ask us to walk through a scoping document rather than a feature tour. It is a less exciting hour and a considerably more useful one.