A project proposal should make one decision easier: whether to give a piece of work the time, attention, money, and authority it needs. It is not a project plan, a meeting transcript, or a promise that every estimate will hold. It is a bounded case for a specific change.
A strong proposal is shorter than the work it describes. It names the problem, shows the change, sets the limits, and makes the next decision clear. If a reader has to schedule a meeting just to discover what you are asking for, the proposal is not ready.
Use this six-part structure: context, proposed change, proof, boundaries, trade-offs, and decision path. It works for a small internal project, a client engagement, a creative build, a research idea, or a side project that needs someone else to commit resources.
Start with the decision, not the idea
An idea invites discussion. A proposal asks for a responsible commitment. Put the decision near the top so the reader can understand the document's job before reading the detail.
Write one sentence that answers four questions:
- What are you asking to approve?
- Who needs to decide?
- What is the first bounded period of work?
- What will be visible at the end of that period?
For example: Approve a four-week pilot to test one intake flow, with one owner, a defined review date, and a decision about whether to continue. That sentence does not pretend the whole future is known. It gives the reader a clear commitment to evaluate.
The six parts of a decision-ready project proposal
1. Context: name the problem in observable terms
Start with the situation that makes the project worth considering. Describe what is happening now, who is affected, and what remains difficult. Keep the language concrete. "The process is bad" is a judgment. "Requests arrive in three places, no owner is named, and the same questions are answered more than once" gives a reader something to assess.
Include the cost of leaving the situation as it is, but do not inflate it. The cost may be time, confusion, missed work, a delayed decision, an avoidable handoff, or a customer experience that does not match the promise. If you do not know the size of the cost, label it as a question to test rather than inventing a number.
2. Proposed change: describe the new state
Explain what will be different if the proposal is approved. Lead with the change a person will see, not a list of activities or features.
A weak proposal says, "Build a new dashboard." A clearer proposal says, "Create one weekly view that shows the three signals the owner needs before deciding what to work on next." The second version gives the project a job. It also leaves room to choose the simplest way to do that job.
Keep the promise narrow enough to review. A proposal can be ambitious in purpose while staying modest in its first proof. That is how you avoid turning an interesting direction into an unbounded commitment.
3. Proof: separate what is known from what is assumed
Show the evidence that supports the proposal. This might be a repeated request, an existing artifact, a measured delay, a customer question, a failed handoff, or a small test that exposed a larger opportunity. The point is not to build a case out of volume. It is to let the reader see why this work deserves a decision now.
Label each important statement as one of three things:
- Known: something you can point to directly.
- Estimated: a range or forecast that may change.
- Assumed: a condition that still needs to be tested.
Connect assumptions to a test and an owner. The Journal's project assumption log is useful when a proposal depends on conditions that are not yet verified. A proposal becomes more credible when uncertainty is visible and assigned, not hidden inside confident language.
4. Boundaries: define the work before it expands
State what the project includes and what it does not include. Name the first deliverable, the time window, the owner, the resources required, and the dependencies that could block it.
Out-of-scope work is not a sign that you forgot something. It is a way to protect the decision. If the first phase does not include a full rollout, ongoing support, a second audience, or a new reporting layer, say so. Someone can approve a bounded project honestly. They cannot approve a moving target.
Use the existing project brief guide after the direction is clear and the delivery team needs a shared agreement about purpose, audience, boundaries, proof, and ownership. The proposal earns the commitment. The brief helps the work stay clear once it begins.
5. Trade-offs: make the cost of the choice visible
Every project uses something: hours, budget, attention, access, or the capacity to do other work. A proposal that only describes the upside asks the decision-maker to discover the cost later.
Write down what the project requires and what it displaces. Include the meaningful risks, but keep them connected to a response. If the work needs a specialist for two sessions, say that. If choosing this project means delaying another request, name the delay. If the first phase trades breadth for speed, make that a deliberate choice.
Clear trade-offs let a team approve the work for the right reason instead of discovering the real commitment through friction.
6. Decision path: end with a usable ask
Finish with the decision in a form someone can answer. Use a short list:
- Decision: approve, decline, or approve with a stated condition.
- Decider: the person with authority to make the call.
- Decision date: when the work needs an answer.
- Next move: what happens after approval.
- Review point: when the team will inspect the first proof.
Do not end with "Let me know what you think" when you need a commitment. Ask the actual question: Can you approve this four-week pilot, with the named owner and review date, by Friday? A direct ask creates a direct response.
A simple project proposal template
Use the following as a starting page. Add detail only when it helps the reader make or execute the decision.
| Section | What to write |
|---|---|
| Decision requested | The commitment you want, the decider, and the answer date. |
| Context | The observable problem, who it affects, and the cost of leaving it unchanged. |
| Proposed change | The new state and the first bounded result the project will produce. |
| Proof and assumptions | What is known, what is estimated, what is assumed, and how each open question will be tested. |
| Scope and ownership | In scope, out of scope, owner, resources, dependencies, and review point. |
| Trade-offs | Time, budget, attention, risks, and the work that will wait or change. |
| Next move | The first action after approval and the person responsible for starting it. |
Read the page once as the person who must approve it and once as the person who must deliver it. The first reader should be able to understand the commitment. The second should be able to start without translating vague language into a new project.
Know the difference between a proposal and the other project records
Small teams lose time when one document is asked to do four different jobs.
- Project intake decides whether a request deserves attention. The Journal's small-team intake guide shows how to screen the work before a full commitment.
- Project proposal makes the case for a specific commitment and asks for a decision.
- Project brief aligns the people doing approved work around purpose, boundaries, proof, and ownership.
- Project plan sequences the work, dependencies, dates, and responsibilities needed to deliver.
- Status update reports what changed, what is true now, and where a decision or intervention belongs.
These records can link to one another, but they should not be merged into a single document that nobody can scan. Keep the proposal focused on the commitment. Once the project is approved, move the useful facts into the delivery record and keep the proposal as the honest record of what was agreed.
Keep the proposal honest after approval
Approval is not the end of the proposal's usefulness. It is the point where its boundaries become a reference.
Keep the original version, record the approval, and update the plan when conditions change. If the project needs more time, money, or scope, return to the decision instead of quietly absorbing the change. A revised commitment deserves a visible revision.
Use ranges when precision would be false. Give estimates a review date. Name the signal that would cause a pivot, pause, or close. When the first proof arrives, compare it with the proposal's original question. The goal is not to defend the first draft. The goal is to improve the next decision.
Before you send it
Run five final checks:
- Can the reader state the decision in one sentence?
- Is the problem supported by something observable?
- Are scope, owner, resources, and trade-offs visible?
- Are assumptions and estimates labeled instead of disguised as facts?
- Does approval lead to one clear next move and one clear review point?
If the answer to all five is yes, the proposal has done its job. It has not guaranteed the result. It has made the commitment clear enough to choose, start, and review.
The work still has to be earned in the days after approval. If you want a quiet uniform for those days, the Oversized Heavyweight Tee is built around a heavyweight, garment-dyed, oversized cut with a boxy drop shoulder and the ascending mark across the chest. For more practical systems for building, keep reading The Self Made Journal.
0 comments