Project Proposal Template
The document that argues a project should happen, not one that assumes it already has. The problem, the approach, a cost and timeline estimate, and what success would look like.
Written to get a decision. Once it's a yes, it becomes a brief: a different page.
Why most project proposals get a verbal yes and then vanish
A proposal's job is to get a decision on record, along with what was actually agreed to. Most fail at the second half. The yes happens, but nothing durable is left behind to show what it was a yes to. Six months later, the project is judged against a memory of the pitch rather than what was actually written down at the time.
The case lives in a slide deck. It gets presented once, a room nods, and the deck goes into a folder nobody reopens, including the person who eventually has to build against whatever was in it.
The estimate gets treated as a commitment. A rough cost and timeline stated to make the case gets remembered, three months later, as a promise made with far more confidence than it actually had at the time it was written.
Nobody wrote down who approved what, or when. A verbal yes in a meeting has no paper trail. When the question "did we actually sign off on this scope" comes up later, there's no page to check, only competing memories of the meeting.
Rejected proposals disappear entirely. Without a record, a rejected idea has no history, so it resurfaces later with none of the earlier reasoning attached, and the same objections get raised, and answered, a second time.
Approval and scope get separated. A room approves the idea in principle, but the specific cost, timeline and outcome written down at the time never get individually confirmed, so "approved" ends up meaning something slightly different to everyone who was in the meeting.
The pitch and the plan blur together. A proposal written to persuade tends to state the approach with more confidence than a plan actually deserves at that stage, and if it's later reused as the plan without revision, that overconfidence carries straight through into the schedule.
The structure, and why each part is there
What's costing time or money right now, and roughly how much. The business case a reader can weigh, not a general sense that something should improve. A number here is what turns a hunch into something that can actually be evaluated.
What would actually get built, in a few sentences: enough to evaluate the idea, not a full plan. The detailed plan comes later, once it's approved, in the brief that follows.
Stated as a range, on purpose. Precision at proposal stage is invented, not measured, and a false-precise number is exactly what turns into an unwanted commitment later.
Same principle: a rough window, not a date. The detailed schedule belongs to the brief and the board, once the project actually exists as one.
What changes if this works, stated as something checkable later, so approval can eventually be judged against a result, not just a memory of a good pitch.
There's no dedicated approval workflow or e-signature step. The decision gets written into the proposal's wiki page, and page history records who wrote it and when.
A rejected proposal stays on its page with the reasoning attached, instead of being deleted, which turns out useful the next time a similar idea gets raised.
The proposal doesn't get repurposed into the brief by editing it in place. It stays as the historical case, and the brief starts fresh from what was actually approved.
Once approved, individual sentences in the proposed approach can become tasks directly: a starting point for the board, even before the brief is fully written.
How to use it
- 01Draft it as a wiki page before the project exists. There's no board yet. This page is only the case for building one, not a plan for running it.
- 02State cost and timeline as ranges, not commitments. If the range is uncomfortably wide, that's honest information about how early this is, not a reason to narrow it artificially.
- 03Get stakeholders to comment on the page itself, rather than in a separate email thread, so the discussion that shaped the decision stays attached to the proposal it's about.
- 04When a decision gets made, write it into the page. A sentence, approved, rejected, or approved with changes, dated by whoever wrote it. Page history is the record; there is no separate sign-off feature to route it through.
- 05Once approved, start a new project brief. The proposal argued for the project; the brief documents how the approved project will actually run. Keep them as two pages, not one that gets edited in place.
- 06Link the two pages to each other. The brief should say plainly which proposal it came from, so anyone questioning the approved scope later can trace it back to the number that was actually agreed to.
- 07Keep the tone of an estimate, not a promise. Words like "roughly" and "in the range of" belong in the cost and timeline sections on purpose. They're doing real work, not hedging.
Written this way, the proposal stops being a pitch that only exists in someone's memory of a meeting. It becomes the thing both sides can point back to when the project is judged against what it originally promised, including whether the eventual cost and timeline were close to the estimate or not. That's really what a wiki page with history is good for here: it's not a fancier document, it's just one that can't quietly reshape itself in everyone's memory the way a slide deck does.
- A proposal argues a project should happen; a brief documents one that already has
- Cost and timeline belong stated as ranges, not as commitments made too early
- There's no approval workflow: the wiki page and its history are the record
Common questions
No. There's no dedicated approval or e-signature feature. The proposal lives as a wiki page, stakeholders comment on it directly, and the decision gets written into the same page. Page history records who wrote it and when, which is what stands in for a formal sign-off trail rather than a routed workflow. For most teams that's enough; it's a record, not a legal signature.
Leave it as-is. Write "rejected" and the reason into the page rather than deleting it. A rejected proposal with its reasoning attached is genuinely useful the next time a similar idea comes up, since it saves re-litigating the same objections from memory a second time.
A proposal exists to get a yes: it makes the case, with a cost and timeline estimate attached. A brief assumes the yes has already happened and defines the goal, scope and success criteria for how the approved project will run. Different purpose, different page, written at different points in the project's life, and a project generally needs both, in that order.
Free covers up to 5 users and 2 projects, forever, with every template included, so drafting a proposal costs nothing before there's even a project to charge for. Team is ₹299 per user per month for up to 40 users. Business is ₹599 per user per month. See the pricing page for the rest.
Related pages
See it on your own work.
A workspace your whole company will actually use is 60 seconds away. No card, no risk, nothing to install.
14-day full-access trial · sample project included · no card required