How a fixed-scope written proposal works, and how to compare two
A fixed-scope proposal states in writing what will be delivered, in which milestones, what is excluded, what you must provide, how changes are handled and what support follows. To compare two, put them under the same headings. Price differences are often differences in what is excluded or assumed.
What is in a fixed-scope proposal?
A fixed scope means the list of deliverables is agreed and written before work starts, so both sides can tell whether something is in or out. A useful proposal has these parts.
| Part | What it should say |
|---|---|
| Scope | Modules, users, languages, integrations, data migration, reports and documents delivered, each named. |
| Exclusions | What is not included, as a list. |
| Milestones | Each one ends in something you can test, with the acceptance test written beside it. |
| Timeline | Dates tied to your inputs: data, decisions, access. |
| Your responsibilities | People, data, approvals and environments you provide. |
| Hosting and data | Where the system runs, who has access, backup arrangements. |
| Support | Channels, hours, response targets, what is covered, how updates are delivered. |
| Ownership and licence | Who owns configuration, custom work, documents and data; what you may do after the agreement ends. |
| Change handling | How a change is requested, priced and approved. |
| Payment schedule | Tied to milestones that you have accepted. |
Why is the scope fixed before the price?
A price is only meaningful against a scope. If the scope is open, the price can only be an estimate, and the real cost is discovered along the way. Fixing the scope first moves the discovery work to the start, where changing your mind is cheap.
This is also why a proposal usually follows a scoping session rather than a form. The vendor needs to meet the people who will use the system, see a sample of their documents and understand the data to be brought across.
What does a good milestone look like?
A milestone is a promise you can check. Three things make one useful.
- It names what you can see and try: a screen, a document, a report, a posted invoice, not "phase one complete".
- It names the data and the person: which of your records are used to test it, and who on your side accepts it, by when, and what happens if nobody answers.
- It is small enough to review in days: a milestone that takes months to inspect is a surprise waiting to happen.
How are changes handled after you sign?
Needs will change. A fixed scope does not forbid change; it makes change visible. The usual rule is that a change is written down, the vendor states its effect on cost and dates, and nothing starts until you approve it.
Ask in advance what counts as a clarification, which stays inside the agreed scope, and what counts as a change, which is new scope. Disagreements about this are a frequent source of friction in projects, and one sentence in the proposal prevents many of them.
How do you compare two proposals fairly?
- Build one list of headings from the table above and place each proposal's content under them. Gaps become visible at once.
- Normalise the assumptions: the same users, modules, languages, hosting and support hours. If one proposal assumes fewer users than the other, they are not comparable.
- Read the exclusions first. The extra cost in one proposal often covers something the other one left out: migration, training, integration or reports.
- Check how acceptance works: who decides a milestone is done, and against which test.
- Compare support as terms, not as a word: hours, channels, response targets and who answers.
- Ask both vendors to price the same list. Send the list you built and ask each to fill the gaps.
- Look at the exit: data export, ownership and what happens if you stop.
What should you provide, and what happens if it is late?
Fixed-scope work depends on your inputs: a named decision-maker, sample documents, data extracts, access to users for testing, and timely feedback. A proposal should state them and say that dates move if they arrive late. If it does not, ask, because otherwise the dates are fiction.
When is a fixed scope the wrong tool?
When you cannot yet describe the problem. In that case, buy the discovery on its own: a short, defined piece of work that produces a scope and a prototype you can test. Then fix the scope for the build.
The four stages used in custom development, which are discover, design, build and run, follow this logic. The earlier stages exist to make the later ones fixed.
Short answers.
Is a fixed scope the same as a fixed price?
No. A fixed scope is the list of what will be delivered. A fixed price is only possible once the scope is fixed. Ask the proposal to say what is fixed and what the price depends on.
What if we realise halfway that we need something else?
You raise a change. The vendor writes its effect on cost and dates, and you approve or decline it. Work inside the agreed scope continues meanwhile.
Who owns what we pay for?
It depends on the agreement. Ask which parts you own, such as your data, your documents and your configuration, which are licensed to you, and what you receive if the relationship ends. Have it written.
Can a large project be phased?
Yes, and it often lowers risk: a first milestone that goes live, then the next. The proposal should say what each phase delivers and whether later phases are committed or optional.
Want this applied to your company?
Tell us what you run today. A consultant from our Riyadh team replies with next steps, and a written proposal follows before any work starts.