How to write a scope of work suppliers can actually price.
A scope of work should reduce ambiguity without dictating unnecessary implementation detail. The goal is to tell suppliers what must be delivered, where the boundaries sit, how acceptance will be judged and which assumptions they may rely on.
1. Define the required outcome
Start with the business or operational result, not a list of disconnected tasks. Explain what problem the procurement is intended to solve and what successful completion looks like.
2. Define the deliverables
List tangible outputs: equipment, software, drawings, reports, installation, training, commissioning, documentation, support, testing or other agreed products. Where possible, make each deliverable independently identifiable.
3. State quantities and locations
Provide quantities, dimensions, sites, addresses, user counts, asset counts, operating areas or other scale information needed to price. If the quantity is estimated, say so and explain how final quantities will be treated commercially.
4. Describe interfaces
Identify systems, equipment, utilities, people and other contractors the supplier must interface with. Ambiguous interfaces create duplicated cost or unpriced work.
5. Specify standards and constraints
List applicable technical standards, safety requirements, compatibility constraints, approved materials, environmental conditions, access rules, working hours and operational limitations.
6. Distinguish mandatory requirements from preferences
If something is genuinely non-negotiable, write it as such and make the evidence requirement clear. If an alternative is acceptable, explain the performance basis on which it will be assessed.
7. Define what the client will provide
State whether the client supplies power, network access, lifting equipment, storage, drawings, licences, test environments, escorts, permits, data or existing equipment. Suppliers need these facts to avoid pricing duplicate enabling work.
8. Define exclusions
Explicit exclusions help prevent the scope growing invisibly. If civil works, electrical reticulation, data migration, after-hours work, travel or consumables are outside the requirement, state that clearly.
9. Define acceptance criteria
Acceptance should be observable. Examples include passed functional tests, specified tolerances, installed quantities, signed delivery notes, approved drawings, completed training, data reconciliation or formal commissioning.
10. State the required programme
Give the desired start date, completion date, milestone dates, shutdown windows, dependencies and required sequence. If dates are flexible, indicate the decision rule rather than leaving bidders to guess.
11. Clarify documentation and handover
Specify what must be handed over at completion: as-built drawings, manuals, certificates, test results, source files, warranties, asset registers, credentials, training records or other closeout material.
12. Define the change process
State that work outside the approved baseline must be identified, priced and authorised through the agreed variation process. This protects both buyer and supplier from disputes caused by informal instructions.
13. Use schedules for complex requirements
For large procurements, separate the scope into structured schedules: bill of quantities, technical data sheet, responsibility matrix, deliverable register, milestone schedule and pricing template. This makes responses easier to compare.
14. Test the scope with a pricing review
Before publishing or issuing the request, ask an independent person to price it conceptually. Every time they have to ask “who provides this?”, “how many?”, “which site?” or “what counts as complete?”, the scope probably needs another sentence.
A good scope improves both price and delivery
Clear scope reduces hidden contingencies, makes technical evaluation fairer and gives the eventual project team a usable baseline. Once work begins, manage departures through formal scope and variation control.