ERP Migration & SelectionFree templatePDF, Excel, Word exportInfor M3

Infor M3 Implementation Statement of Work Template

A good statement of work keeps an M3 project from turning into an argument. This template gives you a balanced starting structure for scope, deliverables, assumptions, acceptance and change control.

Fill in

Live preview
Download:

Infor M3 Implementation Statement of Work Template

Parties and project

Customer: Acme Precision Ltd Service provider: Example Consulting Partner Project: M3 Phase 1: Order to Cash and Inventory Planned start: 2027-01-11 Planned go-live: 2027-06-14 Commercial model: Fixed price with change control

In scope

Customer order, delivery, invoicing, inventory, warehouse, item and customer master data, two facilities, five interfaces, 20 reports.

Out of scope

Manufacturing execution, HR and payroll, historical transaction migration beyond open items, hardware procurement.

Deliverables and acceptance

DeliverableAcceptance criteriaDueAccepted by
Solution design documentReviewed and signed by process owners
Configured test environmentSmoke tests passed
Data conversion, final mockReconciled within agreed tolerance
UAT completionNo open blockers, majors agreed
Go-liveGo or no-go criteria met

Milestones and payments

MilestoneDatePayment triggerAmount
Kick-off
Design sign-off
UAT sign-off
Go-live

Assumptions

Customer provides subject matter experts for workshops, test data and UAT. Environments are provisioned on time. Scope changes follow change control.

Change control

Any change to scope, schedule or price is requested in writing, assessed for effort and impact, and approved by both parties before work starts.

Signatures

Customer sponsor / Date
Service provider director / Date
Customer project manager / Date
Service provider project manager / Date

This is a starting point, not legal advice. Have your legal counsel review it, and align it with the master services agreement that governs your relationship.

Optional scope review

Share your draft SOW and get comments on scope boundaries and acceptance wording.

Optional. The tool and every export work without this. No spam.

How to use the template

Fill in the parties, project name, dates and commercial model. Write the in-scope list in terms of business processes, facilities and interfaces rather than software menus. State what is out of scope just as clearly. Complete the deliverables table with acceptance criteria that can be tested. Link milestones to payments in a way both parties accept. Export to Word and send to legal and procurement for review.

  • Count interfaces, reports and facilities explicitly
  • State who provides data, environments and test resources
  • Include a clear definition of done for each deliverable
  • Keep a short, written change control process

Scope clarity for M3

M3 projects commonly dispute the same items: number of custom reports, number of interfaces, depth of data conversion, level of testing, training and hypercare. Put a number on each. Say whether configuration of multiple companies, divisions, facilities and warehouses is included, and how many. Say whether the provider or the customer runs the UAT. If the project uses cloud tenants, say who provisions and who pays for non-production environments.

Commercial models

Fixed price suits a well defined scope with a completed fit-gap. Time and materials suits discovery or uncertain scope, preferably with a cap and regular forecasts. A hybrid is common: fixed price for design, time and materials for build until requirements stabilize. Whatever the model, the acceptance criteria and change control process decide whether the arrangement works in practice.

Common mistakes

Vague scope statements such as 'all standard processes' lead to disputes. Missing customer obligations cause delay claims. Acceptance based on opinion rather than criteria delays payments. Another mistake is leaving data quality to the provider alone, when the customer owns the data and must cleanse it. State these responsibilities directly.

Frequently Asked Questions

What is the difference between an SOW and a contract?

The contract or master services agreement sets legal terms. The statement of work defines the specific project: scope, deliverables, timeline, price and acceptance. Many organizations use a master agreement with a separate SOW for each project phase.

Should the SOW name the people?

It helps to name key roles such as project manager and solution architect, and to include a clause about replacement. Naming every consultant is rare. Focus on roles, responsibilities and the minimum experience required.

How do I handle change requests?

Use a written change request that describes the change, effort, cost, schedule impact and risks, approved by both sponsors. Work on the change should not start until approval. Keep a log so cumulative changes are visible at steering meetings.

Is this template legally binding?

Only if you adapt it, add the legal terms of your agreement and both parties sign. The text is a general starting point and not legal advice. Always involve your legal counsel before signing any statement of work.

If you need a second opinion on your M3 scope before signing, Netray partners can review the draft and point out gaps in assumptions and acceptance.