A fixed-price contract is reassuring: a defined scope, a budget, a date and a supplier committing to delivery. Yet in an ERP project, this apparent certainty can hide the central risk: the company discovers what it truly needs during implementation, while the contract assumes those needs were already known.
The real choice is therefore not simply fixed price versus time and materials. It is whether the company has the governance required to make decisions, manage changes without permanent conflict and retain control of the business outcome.
The promise everyone hears
The fixed-price ERP promise is straightforward: you describe the expected result, the systems integrator estimates the work and assumes the effort required to deliver it. Your budget is protected, and operational risk is supposedly transferred to the supplier.
This proposition has genuine merits. A properly prepared fixed-price agreement can provide:
- contractual commitments tied to identified deliverables;
- a shared reference schedule;
- a formal acceptance process;
- better budget visibility than a fully time-based engagement.
It also makes it easier for a managing director to compare proposals on a common basis. A specification prepared with the appropriate method supports that comparison.
The problem starts when “fixed price” is interpreted as “risk removed”. The contract only allocates certain responsibilities. It cannot guarantee the quality of the company’s data, the availability of internal teams or the suitability of undecided business processes.
What is true
When the scope is stable, testable and documented, a fixed-price model usefully forces the supplier to state its assumptions. The proposal should explain what will be configured, developed, migrated and excluded.
This discipline can prevent informal requests from gradually expanding the project. It also gives the steering committee a reference for distinguishing between a defect — the delivered solution does not meet the agreement — and a change — the company now wants a different outcome.
Fixed pricing works well for observable deliverables such as an environment, a defined workflow, an identified dataset, an interface or an operations handbook. It is less reliable when delivery still depends on unresolved business choices.
The European Commission’s PM² methodology reflects this distinction. Its artefacts separate the project charter, work plan, deliverables acceptance plan, requirements management, change plan, risk log and decision log. The templates are available through the Commission’s official PM² project artefacts.
A fixed price does not replace project management. It works when project governance keeps the contractual baseline under control and changes it deliberately when required.
What is false, or only true under certain conditions
The first misconception is that the integrator carries all the risk. The supplier does not control the availability of your finance manager, the quality of your product master data or the ability of department heads to resolve conflicting procedures.
The second is that requirements stop changing after signature. Implementation workshops frequently reveal exceptions, parallel spreadsheets, verbal approvals and different rules across business units. These are not always specification failures. Some realities only become visible when the future ERP is compared with day-to-day work.
The third misconception is that “included in scope” means “fit for use”. A function can comply with the contract while requiring excessive manual operations, producing difficult-to-use information or transferring work to another department. Contractual compliance alone does not establish operational value.
A fixed-price agreement also provides little protection when its assumptions are vague. A requirement such as “customer data migration” does not explain:
- who removes duplicate records;
- which history must be retained;
- how incomplete records will be treated;
- who approves matching rules;
- what happens when the source does not use the expected format.
Without those answers, the risk has merely been postponed until a later discussion about what was supposedly “implicit”.
This is why selecting the project leadership model remains separate from selecting the software integrator. Our comparison of a shared CIO, freelance project manager and integrator explains the different responsibilities involved.
What it costs when you proceed unprepared
The first cost is decision time. If nobody has the authority to approve a business rule, the integrator must wait, proceed on an assumption or configure several alternatives. Each response consumes resources without removing uncertainty.
The second cost is repeated contract variation. Every discovery becomes a commercial negotiation, including issues that could have been addressed during framing. The steering committee eventually spends more time debating whether requests are included than discussing the business outcome.
The third cost is technical debt. To protect the announced go-live date, teams may accumulate custom developments, manual imports and temporary interfaces. These components must later be maintained, tested during upgrades and explained to new employees.
The fourth cost is supplier dependency. If decisions, configuration rules and migration logic are not documented on the client side, changing integrators becomes difficult. The company may legally own the project while being unable to explain precisely how its system works.
Consider an illustrative scenario: during configuration, the sales department requests different discount controls for each sales channel. Without a named business owner, decision log and impact assessment, the integrator may block the request, implement a partial rule or propose additional development. The issue is not merely technical; the company lacks a mechanism for making the decision.
A functional acceptance process prepared before signing the acceptance report can identify some of these gaps. It still comes too late if the project’s structural decisions were never made.
The reasonable way forward
Frame the project before requesting a firm price
The executive sponsor should commission a discovery phase led by the project manager with the relevant process owners. The GOV.UK Service Manual states that discovery typically lasts four to eight weeks, with the actual duration determined by the problem.
The deliverable should not be a generic presentation. It should contain the approved scope baseline, exclusions, affected processes, interfaces, data sources, pricing assumptions and unresolved decisions. Only sufficiently defined work should receive a firm price.
Assign every decision to a named owner
The sponsor names an accountable owner for each relevant domain: finance, sales, procurement, inventory, data or infrastructure. These people do more than attend workshops. They approve rules, accept compromises and document decisions throughout implementation.
The project manager maintains a decision log recording the question, options, impact, accountable person and final choice. PM² explicitly includes decision, change, risk and issue logs among its project governance artefacts.
On Monday morning, ask for the current list of open decisions and the person authorised to resolve each one. Any item without an owner is already a project risk.
Manage changes instead of pretending to prevent them
Throughout delivery, each new request should be captured in a short document: original requirement, reason for change, affected users, impact on data, cost, schedule, risk and available workaround.
The steering committee can then approve, reject, postpone or group the request into a later release. This mechanism does not exist to slow the project down. It prevents a workshop conversation from silently becoming a delivery commitment.
The European Commission defines change management as identifying, documenting, assessing, approving, planning, controlling and communicating changes in its PM² guidance on project change management.
Run data migration as its own workstream
A client-side data owner, rather than the integrator alone, must approve the mapping between the legacy and future systems. This owner arbitrates duplicates, missing values, useful history and archiving rules.
Expected deliverables include a data dictionary, mapping file, rejection report, reconciliation procedure and rehearsal migration results. The workstream remains active from design through post-go-live stabilisation.
Leaving cleansing until final migration means discovering the condition of the fuel when trying to start the engine.
Tie payments to accepted evidence
The sponsor and project manager should connect contractual payments to verifiable deliverables: approved design documentation, configured and tested processes, reconciled migrated data, executed acceptance scenarios, resolved critical defects and completed operating documentation.
Reported progress is not acceptance. Payments should reflect results that the company can inspect under an acceptance plan agreed before implementation.
If the company has no internal CIO, our article on managing an IT project without an IT department identifies the responsibilities that must nevertheless remain under client control.
Our position at D1 Consulting
A fixed-price agreement is a useful contractual tool but a poor risk-transfer strategy. The more an ERP project affects business rules, data and working practices, the less it can be managed through the contract alone.
Our position is to separate the stable scope, which can be priced firmly, from unresolved decisions, which must be assessed and arbitrated. Through our IT Project Management and shared CIO service, we represent the client during framing, governance, estimate reviews, change control, acceptance and transition into operations.
👉 Book a free 30-minute diagnostic to identify the risk areas in your ERP project before freezing its scope, budget or contract.
