How to create a proposal for a project that gets approved

A project proposal has exactly one job: get a single defined project a yes from the one person who controls the budget. It is not a service brochure, and it is not the project plan. The thing that wins approval is not nicer formatting or a longer list of deliverables. It is proving you understand the decision-maker's problem in their own words, then writing every section as a direct answer to a question that person will actually ask. Most proposals lose because the writer skipped the discovery conversation and wrote about the work instead of the outcome the sponsor is buying.

This guide gives you the structure, the section-by-section approver questions, copy-pasteable objective examples, and the mistakes that get good projects rejected. If you want the broader agency-sales-pitch angle (winning new clients, not greenlighting one project), read how to create a proposal instead and cross-reference. This page stays narrow on purpose: one defined project, one approval.

What a project proposal actually is (and the three documents people confuse it with)

A project proposal is a persuasive pre-approval document. It sits in the initiation phase, before the project formally exists. Its whole purpose is to convince a sponsor, client, or budget holder that this project should go ahead. Once it gets a yes, three other documents take over, and confusing the proposal with any of them is the fastest way to write a bad one.

The project charter authorizes the project after approval and grants the project manager formal authority over resources, per PMI guidance. The project plan describes how the work gets executed. The statement of work (SOW) is the binding contractual document with legal terms, payment schedules, and acceptance criteria, as Asana lays out. A proposal is none of those: it is non-binding and persuasive, and it comes first.

Document	Purpose	Timing	Audience	Binding?
Project proposal	Persuade, win approval	Pre-approval	Sponsor / client / budget holder	No
Project charter	Authorize the project	Post-approval	PM and stakeholders	Internal authority
Project plan	Execute the work	Post-approval	Delivery team	No
Statement of work	Define binding terms	Post-approval	Both parties / legal	Yes

Why this matters in practice: if you treat the proposal as the plan, you bury the pitch under task lists nobody asked for yet. If you treat it as the SOW, you put binding legal and payment terms into a document meant to persuade, which creates both legal exposure and a trust problem. Know which document you are writing. For comparing dedicated tools that generate these documents, see proposal software.

Pick your proposal type before you write a word

The type changes your tone, your length, and what you lead with.

A solicited proposal answers a request that already told you the structure. The clearest model is the federal one. Under FAR 15.203(a), a competitive Request for Proposals must, at minimum, describe four things: the requirement, the anticipated terms and conditions, the information the offeror must include, and the factors and significant subfactors used to evaluate the proposal plus their relative importance. That is the canonical shape of any solicited proposal. The requester told you the requirement, the terms, the required content, and the evaluation criteria, so answer those four things in that order. Do not invent your own structure when they gave you one.

An unsolicited proposal is harder. Nobody asked, so you carry the burden of creating urgency and framing the problem yourself. The problem statement does more work here, and the executive summary has to earn attention in the first paragraph. Informal, renewal, continuation, and supplemental proposals are variations on the same axis: how much the reader already agrees there is a problem worth funding.

The practical rule: if there is an RFP or a stated set of evaluation criteria, mirror them exactly. If there is not, you must manufacture the structure and the urgency, and discovery becomes even more important.

Do the discovery first: the step that decides whether the proposal lands

The proposal is won or lost in the conversation before you write it. Everything else is transcription of what you learned. Skipping discovery is the number one reason an approver reads a proposal and thinks "this does not get us."

In a discovery call, extract six things:

1. The real problem, in the stakeholder's own words.
2. What success looks like to them, in measurable terms.
3. The budget reality (a range, a ceiling, or "we have not decided" is all useful).
4. Constraints: timeline, compliance, existing tools, internal politics.
5. Who actually signs off, and who can veto.
6. What a "no" looks like, so you can preempt it.

Run the discovery call against a real agenda so you do not miss the budget or sign-off questions. Start from a client meeting agenda template and the top 10 objectives for a first client meeting. Both are built to surface exactly the inputs a proposal needs.

The project proposal structure, section by section

Build the proposal as a series of answers. Each section answers one question the approver will ask. Write the executive summary last but place it first, because many approvers read only that page and skim the rest.

1. 1

   Discovery (done before writing)

   Capture the problem, success criteria, budget, constraints, and who signs off.

2. 2

   Executive summary

   Answers: why should I care, and what are you asking me to approve? Written last, placed first.

3. 3

   Problem statement and background

   Answers: do you understand my problem? Use the stakeholder's own words from discovery.

4. 4

   Goals and SMART objectives

   Answers: what specific, measurable result do I get? Each objective is time-bound.

5. 5

   Proposed solution and approach

   Answers: how will you solve it? Tie the method back to the problem, not to your service menu.

6. 6

   Scope, deliverables, exclusions

   Answers: what exactly do I get, and what do I not get? List what is out of scope.

7. 7

   Timeline and milestones

   Answers: when, and how will I see progress? Name dated checkpoints.

8. 8

   Budget (itemized)

   Answers: what does it cost and why? Tie line items to scope so finance can defend it.

9. 9

   Team, roles, risks

   Answers: who does the work, and what could go wrong? Pair each risk with a mitigation.

10. 10

    The decision ask

    Answers: what do I do next? Sign, schedule kickoff, or reply by a specific date.

A few notes on the order. The problem statement comes before your solution on purpose, because an approver who agrees with your framing of the problem is already halfway to yes. The budget sits after scope so the numbers read as a consequence of the work, not an arbitrary figure. And the proposal ends with a single, explicit decision ask. A proposal that does not tell the approver exactly what to do next stalls in limbo while they "circle back."

Write objectives that are approvable: SMART, and tied to the budget

Vague objectives give the approver nothing to say yes to and give your team nothing to be held to later. The fix is the SMART framework: Specific, Measurable, Achievable, Relevant, and Time-bound. It was first proposed by George T. Doran in the November 1981 issue of Management Review, in an article titled "There's a S.M.A.R.T. Way to Write Management's Goals and Objectives" (Management Review, vol. 70, pp. 35-36), and federal grant guidance still recommends it today.

Vague

• "Improve the client onboarding process."
• Specific? No, what part of onboarding?
• Measurable? No baseline, no target.
• Time-bound? No deadline.
• The approver cannot tell what success looks like, so they cannot commit budget.

SMART

• "Cut average new-client onboarding time from 21 days to 10 days by Q4, by rebuilding the intake form and automating account setup."
• Specific: intake form + account setup.
• Measurable: 21 days to 10 days.
• Time-bound: by Q4.
• Now it doubles as acceptance criteria for the eventual charter and SOW.

Measurable objectives protect you after approval, too. The numbers you write here become the project's acceptance criteria and feed directly into the charter and the SOW. Tie each objective to a slice of the budget and the timeline so the spend reads as defensible, not invented. A single round number invites rejection; line items tied to outcomes survive finance review.

Scope, exclusions, and the line that prevents scope creep

The scope section answers two questions, and most proposals only answer one. "What will be done" is the easy half. "What will not be done" is the half that prevents disputes. Spell out deliverables, then list explicit exclusions, assumptions, constraints, and dependencies.

Omitting exclusions is the seed of scope creep. It is also why approvals stall on "but does this include..." A reader who cannot find the boundary assumes the boundary is wherever they want it. Draw it for them. A simple structure:

In scope
  - Deliverable 1: [what it is, in one line]
  - Deliverable 2: [what it is, in one line]

Out of scope (explicitly excluded)
  - [Thing people will assume is included but is not]
  - [Work that requires a separate proposal]

Assumptions
  - [Client provides X by date Y]
  - [Existing system Z is available and documented]

Constraints
  - [Budget ceiling, fixed launch date, compliance requirement]

Dependencies
  - [Work that cannot start until a prior task or third party completes]

This is the section that later becomes the SOW, so getting it right now saves a fight later. For the post-approval discipline that keeps scope from drifting, see how to prevent scope creep and how to manage client expectations.

Common mistakes that get good projects rejected

• It is about the work, not the outcome. "Here is everything we will do" reads as a task list. Every section should map to a question the decision-maker is actually asking. If a section does not answer one, cut it.
• No discovery. Proposals built on your assumptions instead of the stakeholder's words feel generic and miss the real priority.
• Objectives that are not measurable. No baseline, no target, no date means nothing to approve and nothing to deliver against.
• A scope section with no exclusions. Missing "out of scope" is the most common reason approvals stall and the most common origin of scope creep.
• Confusing the proposal with the SOW. Binding legal and payment terms do not belong in a persuasive pitch. The proposal is non-binding; the SOW comes after the yes.
• A budget pulled from thin air. A single round number invites rejection. An itemized budget tied to scope survives finance.
• No clear next step. End with one explicit ask: sign, schedule kickoff, or reply by a date.
• A generic template ignoring the requester's evaluation criteria. If they gave you criteria (an RFP does), mirror them. A polished template that ignores the stated evaluation factors loses to a plainer one that answers them in order.

After the yes: turning the proposal into a charter, plan, and kickoff

Once the proposal is approved, it stops being a pitch and becomes the source of truth for the next three documents. The approved objectives and scope feed the charter (which authorizes the work) and the plan (which schedules it). Do not rewrite them from scratch; copy them forward so the project you deliver matches the project that got funded.

Then run a kickoff that reads the proposal's scope and objectives back to the room and gets sign-off. Use a project kickoff meeting agenda or this agenda for a project kick off meeting, and capture every commitment as a tracked action item with an owner using an action items template. Recording the kickoff and the approval call means the decisions become a durable record instead of something three people remember three different ways. For PMs running several of these at once, Scribbl for project managers and the broader agencies page show how the discovery-to-kickoff record holds together. For software-specific delivery, see software development project management.

1981

SMART framework first proposed by George T. Doran

4

minimum elements an RFP must describe under FAR 15.203(a)

15/mo

Google Meet calls on the free Scribbl plan, no card

Frequently asked questions

How long should a project proposal be?

As long as it takes to answer the approver's questions and no longer. A short internal project might fit on two pages: problem, objectives, scope, budget, ask. A large solicited bid follows whatever length the RFP allows. Length is not what wins; specificity is. If a section does not answer a question the decision-maker will ask, it is padding.

What is the difference between a project proposal and a statement of work?

A proposal is a non-binding, persuasive document that comes first and exists to win approval. A statement of work is a binding contractual document that comes after the yes, with legal terms, payment schedules, milestones, and acceptance criteria. Putting binding terms in a proposal, or treating a proposal as a contract, creates legal and trust problems. The scope section of a strong proposal becomes the backbone of the eventual SOW.

Do I need a discovery call before writing a proposal?

For anything beyond a trivial internal request, yes. The discovery conversation is where you learn the real problem, the budget reality, and who actually signs off. Proposals written without it use your assumptions instead of the stakeholder's priorities, which is the most common reason an approver feels the document does not understand them. Recording the call (Scribbl does this for Google Meet with no bot) lets you quote their exact words back to them.

How do I write the executive summary?

Write it last, after every other section exists, then place it first. It should answer two things in a few sentences: why the approver should care, and exactly what you are asking them to approve. Assume it is the only page some people read. If the rest of the proposal disappeared, the summary alone should be enough to get a tentative yes.

What makes an objective "approvable"?

It is SMART: specific, measurable, achievable, relevant, and time-bound. An approvable objective names the metric, the baseline, the target, and the deadline, so the approver can see what success looks like and the team can be held to it. Vague objectives like "improve onboarding" give nobody anything to commit to. Tie each objective to a slice of budget and timeline so the numbers read as defensible.