Project Proposal Template: What to Include and a Copyable Outline

A project proposal is a short document that asks a specific person to approve a specific project. A good one answers seven questions in order: what problem you are solving, what will be different when it is solved, what is in and out of scope, roughly when it will happen, what it will cost and how that cost is set, what could go wrong, and exactly what you are asking the reader to decide. An internal proposal goes to your manager or the owner and can be a page; a client proposal goes to a customer and adds why you, what they need to provide, and the terms. A copyable outline, a short filled example and the difference between the two are below.

What a project proposal is for

A proposal exists to get a decision, not to describe a project in full. California’s state project management framework calls the internal version a business case: its concept guidance↗ (opens in a new tab) says “A business case captures the reasoning for initiating a project or task,” and warns that “A vague project objective risks the project’s ability to deliver measurable benefits.” Those two sentences are most of the advice you need: give the reasoning, and make the objective specific.

The proposal is the first of three short documents. Once it is accepted, the agreement is recorded in a project charter, and the work is planned from there. Write the proposal knowing that its scope section will be copied into the charter almost word for word.

What to include in a project proposal

1. Problem: what is wrong today, in the reader’s words, with one piece of evidence. “We missed four catering orders last month” beats “ordering is inefficient.”
2. Outcome: what will be true when the project is done, and how the reader will check it.
3. Scope: what you will deliver, and a list of what you will not. The out list protects both sides.
4. Timeline: three to five milestones with a target week or month for each, and anything the dates depend on.
5. Cost, in words: how the price is set (a fixed fee, time and materials, or internal time only), what it covers, what it does not, and when it is paid. Put your actual figures in your own proposal; describe the basis here so nobody is surprised later.
6. Risks and assumptions: the few things most likely to change the cost or the date, and what you will do about each.
7. The ask: the decision you need, from whom, and by when.

For scope and timeline, describe results, not activity. Federal contracting has a rule for this: the FAR’s performance-based work statement guidance↗ (opens in a new tab) says to “Describe the work in terms of the required results rather than either ‘how’ the work is to be accomplished or the number of hours to be provided.” “Customers can order and pay online” is a result; “forty hours of development” is not.

For risks, rate each by likelihood and impact, which is how the NIST glossary defines risk↗ (opens in a new tab): a function of the adverse impact if an event occurs and the likelihood of it occurring. Three to five lines is plenty. A proposal with no risks reads as either naive or hiding something.

Internal vs client project proposals

Internal proposals

• The reader knows the business, so the problem section can be short and specific.
• The cost is mostly people’s time, so say whose time, for how long, and what they will stop doing to make room.
• The ask is usually approval and a sponsor: someone who will decide scope once the project starts.
• One page is normal. If it needs more, the project is probably two projects.

Client proposals

• Add why you: relevant work you have done and who will actually do this job.
• Add what the client must provide, such as content, access, approvals and a named contact, with when you need each. Late client inputs are the most common reason a client project slips.
• Add how changes will be handled. A sentence such as “Requests outside this scope get a short written change note with the cost before any work starts” prevents most arguments about scope creep.
• Add acceptance, payment terms in words, and how long the proposal is valid.

A client proposal is the start of a working relationship as much as a price. The Agile Manifesto↗ (opens in a new tab) values “Customer collaboration over contract negotiation,” and a proposal that says how you will share progress, take requests and make decisions together does more for that than a longer list of terms.

A copyable project proposal outline

# Proposal: [Project name]
For: [reader, and their role]     From: [you]     Date: [Month day, year]

## Summary
[Three sentences: the problem, what you propose, what you are asking for.]

## The problem
[What is wrong today, in the reader's words, with one piece of evidence.]

## The outcome
[What will be true when this is done, and how the reader will check it.]

## Scope
In:
- [Deliverable, described as a result]
Out:
- [What this proposal does not include]

## Timeline
1. [Milestone]                     Target: [week or month]
2. [Milestone]                     Target: [week or month]
Depends on: [inputs or approvals the dates rely on]

## Cost
Basis: [fixed fee / time and materials / internal time only]
Covers: [what is included]
Does not cover: [what would cost extra]
Payment: [when, in words]

## Risks and assumptions
- [Risk] | Likelihood: H/M/L | Impact: H/M/L | Response: [ ]
- Assumption: [ ]

## Client provides (client proposals only)
- [Content, access, approvals, a named contact], by [when]

## Changes
[How requests outside the scope are handled.]

## The ask
[The decision you need], from [name], by [Month day, year].

A short project proposal example

Northside Web Studio, a fictional two-person studio, is proposing online catering orders to a fictional bakery. The amounts live in the estimate attached to the real proposal; here the cost is described in words.

# Proposal: Online catering orders
For: Dana, owner, Harbor Street Bakery
From: Northside Web Studio     Date: September 29, 2026

## Summary
Catering orders arrive by phone, email and text, and some are missed.
We propose an online order form with a card deposit. We are asking
for approval by October 3 to launch before the holiday rush.

## The problem
Four catering orders were missed or entered late in August.

## The outcome
Customers order and pay a deposit online; the kitchen sees every order
in one list at least 48 hours ahead.

## Scope
In: order form for the six catering trays; card deposit; sales tax at
checkout; pickup or delivery within your current ZIP codes; emails to
the customer and the kitchen.
Out: wedding cakes and custom orders; retail menu changes; a loyalty
program.

## Timeline
1. Menu, ZIP codes and deposit rules agreed      Target: week of Oct 6
2. Ordering works on a test site                 Target: early November
3. Live                                          Target: November 20
Depends on: menu photos and delivery ZIP codes from you by October 10.

## Cost
Basis: fixed fee for the scope above, in the attached estimate.
Covers: design, build, testing and one round of changes.
Does not cover: card processing fees, new photography, later changes.
Payment: deposit at signing, balance at launch.

## Risks and assumptions
- Late menu photos | L: M | I: M | Response: launch with text only.
- Assumption: your point-of-sale system can export the menu.

## Changes
Requests outside this scope get a written change note with the cost
before any work starts.

## The ask
Approve this proposal by October 3, 2026.

How to write a project proposal in an afternoon

1. Talk to the reader first. Ask what problem they would describe and what a good result looks like. Use their words in the problem section.
2. Write the out list before the in list. It is faster, and it shows where you and the reader disagree.
3. Set milestones as results, then check every date against what you need from someone else.
4. Write the cost basis and what it excludes, then the risks that could change it.
5. Write the summary last, in three sentences, and put it at the top.
6. Read it aloud as the reader. Anything they would ask about is a line you have not written yet.

After the yes

An accepted proposal turns into a charter, a kickoff and a board. On a fenbs board, record the acceptance on the Decisions and rules page with who decided and when, and attach the signed proposal to that decision. Record each out-of-scope line as a rule; every connected AI assistant reads the rules first. Add the client with the Client role, which sees the board and comments but cannot change anything, or the Reporter role if they should add their own requests. Turn the milestones into tasks with Add many. fenbs has no invoicing and no due dates, so payment terms and target dates stay in the proposal and the charter.