Key takeaways
- Open with the client's problem in their own words, not with your company history.
- Split the work into deliverables with an acceptance line for each one — "done" must be testable.
- Price against the deliverable list, never against a vague phase name.
- Write assumptions and exclusions explicitly; every exclusion you skip becomes free work later.
- Attach the validity period and the approval mechanism — signature, purchase order or written acceptance.
The sections a project proposal needs
Read the proposal as a procurement officer would: they are looking for eligibility, scope certainty, price basis and risk. Everything below earns its place because its absence produces a question.
| Section | What it must fix | Typical failure |
|---|---|---|
| Executive summary | The problem, the outcome, the price and the duration in one paragraph | A company introduction with no numbers |
| Understanding / background | Restates the client's requirement and constraints | Skipped, so the client cannot see they were heard |
| Scope and deliverables | Numbered deliverables with acceptance criteria | "Full implementation support" as one line |
| Approach and methodology | How the work is sequenced and who does it | Generic methodology diagram with no roles |
| Timeline and milestones | Dates or week numbers tied to deliverables | Total duration only, no intermediate dates |
| Commercials | Price per deliverable, taxes, payment schedule, currency | A single lump sum with no breakdown |
| Assumptions and exclusions | Client inputs, access, approvals, out-of-scope items | Omitted entirely |
| Terms and validity | Validity date, change-control route, acceptance method | No expiry, so old pricing is accepted months later |
Writing a scope that cannot expand quietly
Scope creep is almost always a drafting failure, not a client failure. If a deliverable cannot be marked complete by pointing at something, it will be argued about.
- Give each deliverable a number, a one-line description and an acceptance line ("accepted when the report is delivered in PDF and reviewed in one session").
- State quantities: how many pages, sites, drawings, revisions, training sessions, test cycles.
- Cap revisions per deliverable and say what a further revision costs.
- List client dependencies with the date each is needed — access, data, drawings, approvals, single point of contact.
- Add a short change-control clause: changes are priced in writing before work continues.
The strongest single sentence in a proposal is usually an exclusion. "Civil works, permits and third-party licence fees are excluded" prevents a month of argument.
Pricing a project so finance can approve it
Finance teams do not approve prices, they approve price bases. Show how the number was built and the approval moves faster.
- Price each deliverable or milestone separately, then total.
- Show tax as its own line at the correct rate for the country of supply, or state the zero-rating.
- State the payment schedule as triggers, not dates: on signature, on acceptance of deliverable 2, on completion.
- Name the currency in ISO form and say who bears bank charges on cross-border transfers.
- Give a validity period — 15 to 30 days is normal — and reissue rather than edit an accepted proposal.
A worked GCC example
A Dubai fit-out contractor proposes a warehouse office refurbishment: five deliverables (survey and drawings, approvals submission, partitions and ceiling, MEP modification, handover with as-built drawings), each priced separately, 5% VAT shown on its own line, 30% on signature and the balance across two acceptance milestones, validity 21 days, with permits and landlord fees excluded and a named client approver required within three working days per submission.
What happens after approval
An approved proposal should turn into working documents the same week, otherwise its detail is lost. The natural sequence is a project plan, then a scope of work for the delivery team or subcontractor, then timesheets and progress reports, and finally a completion certificate that releases retention or the final payment.
How to write a project proposal
Step 1: Restate the requirement
Write the client's problem and constraints in plain language and confirm the outcome they want.
Step 2: Define deliverables
Number each deliverable, describe it in one line and add a testable acceptance criterion.
Step 3: Sequence the work
Set milestones with dates or week numbers and name who is responsible for each.
Step 4: Price the deliverables
Cost each deliverable, add tax correctly, and turn the payment schedule into triggers.
Step 5: Fix the boundaries
List assumptions, exclusions, client dependencies and the change-control route.
Step 6: Issue and track
Export a PDF, state validity and the acceptance method, and record the approval date.
Frequently asked questions
How long should a project proposal be?
Long enough to make scope and price unambiguous, and no longer. Four to twelve pages plus annexes covers most SME projects; the deliverable table and the exclusions do more work than extra narrative.
What is the difference between a project proposal and a quotation?
A quotation prices a defined request. A proposal defines the request first — problem, approach, deliverables, risks — and then prices it. Where the client has already specified everything, a quotation is enough.
Should a proposal include a contract?
Include the commercial terms that must be agreed before work starts, and reference the agreement that will govern delivery. For anything long-running, follow the accepted proposal with a service agreement or scope of work signed by both sides.
How do I stop a client from expanding the scope?
Number the deliverables, cap the revisions, list exclusions, and add a change-control clause requiring written pricing before extra work proceeds. Then use progress reports to record when a change was requested.