What belongs in an ERP scope document

A scope document exists to make one question answerable: is this thing we are now discussing included or not? Most proposals cannot answer it.

What it must contain

Requirements with references. Every requirement numbered, so it can be quoted later. SL-01, HR-04. Without references you argue about descriptions.

A fit-gap position on each one. Is it standard, configuration, or custom development? This is what turns a wish list into an estimate.

An explicit exclusion list. The most valuable section in the document, and the one most often missing. Anything not listed as in scope is out — say so, in those words.

Deliverables with acceptance criteria. Not "training" but "four sessions, maximum three hours, at your office, attendance sheets signed".

Client responsibilities with dates. Data by a stated date, users available for testing, a single authorised decision-maker.

A change control process. How new requirements are raised, who prices them, who approves, and confirmation that verbal requests do not count.

The clauses worth having

• Supersession. This document replaces all prior proposals, demos, emails and messages.
• Deemed acceptance. Deliverables are accepted if no written objection arrives within five working days.
• Revision cap. Two rounds of revision per print format or report, then it is chargeable.
• Scope freeze date. After this date, new requirements move to the next phase.

Why it protects the client too

A clear scope is not a way to say no. It is how a client knows what they are paying for, avoids being billed for things they never agreed, and can hold a delivery date to account. Vague scopes hurt whoever is less organised, and that is usually the client.

Write it before you start. Writing one a year in, as we have had to do, works — but it is a great deal harder.