How do you write a project proposal that gets approved?

What a project proposal is and is not

A project proposal explains what you want to do, why it matters, and roughly how you plan to do it, with enough detail on goals, timeline, budget, and resources that a stakeholder can decide whether to approve it. It is written before any real work begins, which is exactly what makes it powerful: it creates alignment while everyone can still change their mind cheaply.

It is worth doing properly. According to PMI's Pulse of the Profession report, projects that follow project management best practices are 2.5 times more likely to succeed, and a clear proposal is usually the first of those practices. So this is not paperwork for its own sake. It is the moment you force fuzzy enthusiasm into something concrete enough to commit to.

The confusion usually comes from three lookalike documents. A proposal persuades stakeholders to approve a new initiative, focusing on goals, benefits, and what it takes to begin. A project plan takes over once it is approved and describes how the work gets done, who owns what, and how progress is tracked. A business case comes later still, when an active project needs more time, budget, or people. The proposal gets the green light. The plan keeps things on track. The business case keeps it alive when priorities shift.

One more distinction shapes the tone. Proposals can be internal, for your own leadership or another team, or external, aimed at clients, investors, or partners. They can also be solicited, meaning someone asked, often through a brief or an RFP, or unsolicited, meaning you are pitching an idea nobody requested. An unsolicited external pitch has to earn attention before it earns approval, so it leans harder on the problem and the timing. The goal never changes: get a yes and move the project forward.

Which sections a proposal needs

You do not need a fifty-page template. You need five sections, each answering a question the decision-maker is already asking. Here is what belongs in each, and the trap that quietly sinks proposals at that step.

Notice that nothing here is about format. A proposal can be a polished slide deck for a client or a one-page memo for your manager. The five sections are what the reader is actually weighing; the wrapping just needs to make them easy to find.

How to write one, step by step

Writing a proposal is not about being perfect, it is about being clear. Work through the five sections in order, because each one sets up the next, and the reader follows the same path.

Step 1: Write the executive summary last

Open the document with the summary, but write it after the rest is done. It should state the background, the main goal, and what success looks like in a few sentences. If your project solves a real problem or unlocks something new, make that obvious in the first line. People often decide here whether to keep reading, so this is where your sharpest sentence belongs.

Step 2: Establish the background

Give the reader context. Has this issue come up before? Were there earlier attempts that failed or succeeded, and what changed? Then describe the current problem or opportunity in specific terms, and connect it to your team, your users, or a business outcome. This is where you draw the line between a pain point and the need to act. An honest project scope here also stops the proposal from promising more than it can deliver.

Step 3: Present the solution

Now explain what you are actually proposing. Describe the approach and break it into phases if it helps, with a rough schedule showing when the key parts happen. Name who is involved and what their roles are. If you will rely on tools for tracking, reporting, or collaboration, say which ones; mentioning that the team will run the work on a shared board in Breeze, for example, helps stakeholders picture the project running rather than living in a document. The more concrete the picture, the less risky the ask feels.

Step 4: Define deliverables and goals

Be clear about what success means. Start with a short vision statement to set direction, then turn it into goals using the SMART framework: specific, measurable, achievable, relevant, and time-bound. Vague goals are where proposals quietly die, because a stakeholder cannot approve an outcome they cannot verify. List the major deliverables, and for each one note what it requires, who owns it, and how you will know it is done.

Step 5: List the required resources

Finish with an honest estimate of what the project needs: time, people, tools, and money. Break the budget down and tie each cost to a specific deliverable or milestone rather than presenting one round figure. If certain resources are non-negotiable, such as a particular platform, contractor, or integration, call that out plainly. The more grounded your ask, the more trust you earn, and trust is what carries the proposal past the inevitable "is this worth it" moment.

Once approved, the proposal hands off to execution. A short implementation plan turns those five sections into who does what by when, so the momentum from a yes does not stall before the first task moves.

Why some proposals get approved and others stall

Structure gets you a readable document. Persuasion gets you a yes. You are asking someone to spend time, money, or attention, so the proposal has to meet them where they are. Two proposals with identical sections can land completely differently, and the difference is almost always in these five habits.

• Know your audience. Understand who you are writing for and what they care about. A CFO weighs cost and risk; a department head weighs disruption and effort. Tailor the message to their goals, pain points, and constraints, and speak their language rather than yours.
• Define the problem clearly. Be direct about what is wrong or what opportunity is slipping away. Add urgency by spelling out what happens if nothing is done. A problem the reader can feel beats a solution they have to imagine a use for.
• Use plain language. Skip the buzzwords. Simple, natural writing builds trust and removes confusion. If someone has to reread a sentence to understand it, you have already lost a little of their patience, and patience is what approval runs on.
• Back it up. Support the case with data, a short case study, or an example from past work. Even one credible stat makes the idea feel grounded rather than hopeful, and gives a cautious approver something to point at when defending the decision upward.
• Explain why now. Timing matters. If the project is urgent or aligns with a current priority, say so and show why waiting is the more expensive option. "Why this" gets attention; "why now" gets a signature.

The pattern under all five is the same: specific and relevant beats broad and impressive. Focus on what matters to this reader, back it with real examples, and make the timing clear. That is what turns a thoughtful document into an approved one.

Common questions before you send it

How long should a project proposal be?

As short as it can be while still answering the five sections. For an internal project, one to three pages is often plenty. A large external pitch needs more detail, but every extra page should earn its place. Length signals nothing; clarity signals everything.

What is the single most important section?

The executive summary, because it is the part most likely to be read in full and it frames everything after it. If a busy approver reads only that paragraph, they should still understand what you want, why, and what it costs.

What if the answer is no?

Ask which section lost them. A no usually traces back to one of the five: an unconvincing problem, a fuzzy solution, unprovable goals, or a budget that felt like a guess. A rejected proposal is a precise map of what to fix before the next attempt.

The short version

A project proposal earns approval when it answers what, why now, and how much in clear language, backed by specifics a decision-maker can verify and defend. Build it from the five core sections, write the executive summary last, and tie every cost to a concrete deliverable. Then reread the opening paragraph alone and ask whether someone who reads nothing else would still say yes. If not, that is the part to rewrite first.