Chapter 20: Proposals and Business Cases: Persuading Decision-Makers to Act

"The purpose of a proposal is not to describe what you want to do. It is to make the reader want you to do it." — a principle widely taught in business and grant writing; treat as illustrative, not a verified quotation.

Chapter Overview

A regional logistics company once needed to replace the software that scheduled its delivery trucks. The old system was fifteen years old, crashed weekly, and required a single retiring engineer to keep it alive. The operations manager who understood the risk wrote a twenty-two-page proposal. It was thorough. It described the current architecture in loving detail, surveyed six replacement vendors, included a feature comparison matrix with forty rows, and ended—on page nineteen—with a recommendation. The executive committee gave it eight minutes on a Thursday agenda. Nobody reached page nineteen. The proposal was tabled "pending further discussion," the discussion never happened, and four months later the old system failed during the holiday peak and cost the company more in one weekend than the new system would have cost in a year. The manager was not wrong. The manager was unread—and this time it was avoidable, because unlike the engineers we met in Chapter 4, the manager had time, attention, and a willing audience. They simply organized the document for themselves instead of for the eight-minute reader.

This chapter is about the writing that asks an organization to spend money, time, or political capital on something that does not yet exist. Proposals and business cases are persuasion documents aimed at people who decide. And the central fact about those people—executives, committees, clients, funders—is that they are time-poor and risk-averse, and they read your careful document the way Chapter 4 said all readers read: by scanning, hunting for the bottom line, and leaving the moment they have it or conclude they won't find it. The theme that runs through everything here is theme 2, audience is everything: a proposal is not a description of your idea; it is a tool built for a specific reader to make a specific decision. Get the reader wrong and the best idea on earth dies on page nineteen.

You have already built the two skills this chapter stands on. Chapter 4 taught you to put the conclusion first and structure for a scanning reader; a proposal is that lesson with money on the line. Chapter 19 (Emails) taught you to make a clear request with one action and a deadline; a proposal is a request scaled up to a budget. This chapter adds what is new: the standard shape of a proposal and a business case, the discipline of turning features into benefits and risks into mitigations, the arithmetic of ROI, and—above all—the executive summary, the half-page that does most of the persuading because for most decision-makers it is the only part they read. By the end of this chapter, you will be able to assemble a proposal or business case from its standard parts, write an executive summary that stands alone and leads with the ask, and diagnose why a persuasion document fails—and fix it.

In this chapter, you will learn to:

• Choose between a proposal and a business case, and assemble either one from its standard parts so each part answers a question the decision-maker is already asking.
• Write an executive summary that stands completely on its own, leads with the ask, and carries the decision in half a page.
• Turn a list of features into an argument about benefits, and a list of risks into a risk–mitigation table that builds confidence instead of fear.
• Calculate and state an ROI, a payback period, and a cost-of-inaction so the money argument is concrete, not hand-waved.
• Adapt the document for an internal sponsor versus an external client, and for an executive who will give you three minutes.

📘 Business/Professional track: This is one of your core chapters. The executive summary (§20.4), writing for executives (§20.8), and the features-to-benefits move (§20.6) are the difference between a proposal that gets funded and one that gets "tabled." Read the whole chapter; it is built for you. 📕 Engineering/Science track: Two of these skills transfer directly to the work in Chapter 17 (Grant Proposals): the executive-summary logic maps onto the Specific Aims page, and the problem–significance framing is the same move grant reviewers reward. You will be tempted to lead with the technical approach because it is the part you find most interesting; resist it, and read §20.8.

20.1 Proposal vs. Business Case: Two Documents, Two Jobs

Start with a distinction people blur constantly, because using the wrong document is the first way a good idea fails.

A proposal answers the question "Will you let us do this?" It is forward-looking and action-oriented: here is a problem, here is what we propose to do about it, here is how, when, for how much, and why we are the right people. A vendor pitching a client writes a proposal. An engineer asking for budget to rebuild a system writes a proposal. A team requesting headcount writes a proposal. The reader's decision is go or no-go on this specific plan.

A business case answers a question that comes one step earlier: "Is this worth doing at all, and if so, which way?" It is an analysis that compares options—including the option of doing nothing—and recommends one, justified primarily by the numbers. A business case for migrating to the cloud lays out the current state, the desired state, three or four ways to get there (including "stay put"), the cost and benefit of each, and a recommendation. The reader's decision is which path, and is the return worth the spend.

The practical difference: a proposal is mostly about the plan; a business case is mostly about the comparison and the money. The two often live together—a strong proposal contains a business case inside it (the section that proves the investment pays off), and a business case usually ends by proposing a path. But knowing which one is the primary job tells you what to lead with and what your reader will scrutinize. If the decision is "should we, and which way?" lead with the options and the ROI. If the decision is "should we let you do this?" lead with the problem and your solution.

Here is the same situation framed both ways, so you can feel the difference:

As a proposal (the job is to win approval for a plan): We propose to replace the legacy dispatch system with CloudRoute over six months for $240,000. The current system fails roughly weekly and depends on a single engineer who retires in March. Below: our approach, timeline, budget, and team.

As a business case (the job is to justify the investment and choose among options): The dispatch system is a single point of failure with rising risk and a knowledge holder retiring in March. We evaluated four options—do nothing, extend support, build in-house, and buy CloudRoute. Buying CloudRoute has the lowest three-year total cost ($310,000) and the shortest payback (14 months). We recommend it.

Both are about the same project. The proposal foregrounds the plan and the team; the business case foregrounds the options and the return. A polished package for a major decision often delivers both: a business case that establishes "yes, and this way," followed by a proposal that says "here is exactly how we'll execute."

🔄 Check Your Understanding Your manager says, "The leadership team already agrees we need a new analytics platform—they just need to pick a vendor and approve the spend. Write me a one-pager." Is your primary document a proposal or a business case? Why?

Answer

A business case, leaning on options analysis and ROI. The "should we do this at all" question is already settled ("they already agree we need one"); the open decision is which vendor and is the spend justified. So lead with the comparison of vendors and the numbers, not with a problem statement re-arguing a point everyone already accepts. Re-litigating the settled question would waste the reader's scarce attention—a Chapter 2 audience failure.

20.2 The Anatomy of a Business Proposal

A proposal has a conventional skeleton, and conventions exist to help the reader. When parts appear where the reader expects them, the reader navigates by habit and spends attention on your content instead of on finding it. Here are the standard parts, each defined by the reader question it answers. You will not always use every one, and the order can flex, but skip a part only when you can name why your reader doesn't need it.

Notice what every column on the right has in common: it is about the reader, not about you. A proposal organized around your reader's questions reads as helpful; a proposal organized around your project's internal logic reads as homework you're making them grade.

Two parts deserve a closer look here, because they are where proposals most often go soft.

The problem statement is where you win or lose the reader's attention. The temptation is to describe the problem the way you experience it ("the dispatch system's codebase has accumulated significant technical debt and the database schema is denormalized"). But the decision-maker doesn't feel technical debt; they feel cost, risk, and consequence. State the problem in the currency they care about.

❌ Before (problem stated in the writer's terms): The current dispatch system was built on a deprecated framework and suffers from significant technical debt. The codebase is poorly documented, and institutional knowledge is concentrated in a single team member. Database queries are unoptimized and the system experiences periodic instability under load.

✅ After (problem stated in the reader's terms): The dispatch system fails about once a week, and each failure stops deliveries until one specific engineer—who retires in March—personally restarts it. Last quarter, outages delayed 1,900 shipments and triggered $84,000 in service-credit refunds. When that engineer leaves, we have no one who can bring the system back up.

Why it's better: The "before" is true but inert—the executive cannot tell whether "technical debt" is a crisis or a grumble. The "after" converts every technical fact into a consequence the reader feels: weekly failures, a single point of failure with a retirement date, 1,900 delayed shipments, $84,000 in refunds. Same situation; one version makes the reader want to act and one makes them want to delegate it to someone technical. This is theme 2 in action: you didn't change the facts, you changed the reader you were writing for.

The budget is a trust test, not just a number. A budget that is suspiciously round ($250,000 flat) or suspiciously low signals that you haven't thought it through. Itemize. Include the costs people forget—training, migration, the productivity dip during transition, a contingency line. A budget that openly accounts for the hard parts is more persuasive than a smaller one that pretends they don't exist, because it tells the reader you will not surprise them later.

💡 Tip: For every line in your budget, ask "what question is the reader going to ask about this number?" and answer it in the proposal before they have to ask. A budget that pre-empts the obvious objection ("why is training $30,000?" → "120 dispatchers × 2 days × backfill cost") reads as competence.

🔄 Check Your Understanding A proposal's "Qualifications" section reads: "Our team is highly experienced and committed to excellence, with a proven track record of delivering world-class solutions." What's wrong with it, and what would fix it?

Answer

It's all adjectives and no evidence—"highly experienced," "world-class," "proven track record" are claims the reader can't verify and every competitor also makes. The fix is specific, checkable evidence: "We've migrated dispatch systems for three logistics firms of similar size; our last project cut system downtime by 96% and finished two weeks early. The lead engineer, Priya Nair, spent six years building routing systems at FedEx." Concrete beats superlative. This is the features-vs-benefits problem (§20.6) applied to your team: don't assert you're good, show the result.

[📍 Good stopping point]

20.3 The Anatomy of a Business Case

A business case has its own conventional shape, organized around a comparison rather than a plan. Its spine is five moves:

1. Current state — where we are now, and why it's a problem. (Same discipline as the proposal's problem statement: state it in the reader's currency.)
2. Desired state — where we want to be; what "solved" looks like, ideally with a measurable target.
3. Options — the realistic ways to get from current to desired, including "do nothing."
4. Analysis — the cost, benefit, and risk of each option, compared on the same axes.
5. Recommendation — which option, and why, justified by the analysis.

The move that separates a real business case from a sales pitch is option three: always include "do nothing." Executives are trained to ask "what happens if we don't?" If you've already answered it—and quantified the cost of inaction—you look rigorous and you neutralize the cheapest objection in the room ("let's wait and see"). Often the cost of doing nothing is the most persuasive number in the whole document.

Watch the difference between a one-sided pitch and a genuine options analysis:

❌ Before (a pitch dressed as a business case): We should adopt the CloudRoute platform. It is the market leader, it has the features we need, and it will modernize our operations. The investment is $240,000 and the platform will pay for itself through improved efficiency. We strongly recommend moving forward.

✅ After (a real options analysis): We evaluated four options against three-year total cost and operational risk:

Option	3-yr total cost	Risk if chosen	Note
Do nothing	"$0" upfront, **~$420K expected**	High	Failures + the March retirement; one bad peak could exceed this.
Extend legacy support	$180K	High	Buys time, fixes nothing; still a single point of failure.
Build in-house	$390K	Medium-High	Full control, but 14-month build and we'd own maintenance.
Buy CloudRoute	$310K	Low	Fastest to stable; 14-month payback; vendor owns uptime.

We recommend buying CloudRoute: it has the lowest realistic three-year cost once the cost of inaction is counted, the lowest operational risk, and the shortest payback.

Why it's better: The "before" asks the reader to take the recommendation on faith—"it will pay for itself" is an assertion with no arithmetic. The "after" earns the recommendation: it shows the alternatives were genuinely considered, puts every option on the same two axes (cost and risk), and—crucially—prices the "do nothing" option at ~$420K, which reframes the $310K spend as the cheaper path, not an expense. A reader who scans only the table reaches the right decision. That is a business case doing its job.

🔍 Why Does This Work? Why does including options you don't recommend make your recommendation more persuasive, not less? Think about it before reading on.

Answer

Three reasons. First, it signals rigor: a recommendation that survived a comparison is more trustworthy than one that arrived alone, because the reader can see you weren't just selling your favorite. Second, it pre-empts objections: the executive who was about to say "but what about building it in-house?" finds you already costed it—you've answered the question before it's asked, which is the same move the budget section makes (§20.2). Third, it gives the reader agency: people resist being railroaded; showing the alternatives lets them feel they chose, and people defend choices they made. A recommendation with no visible alternatives reads as a sales pitch, and decision-makers have antibodies against sales pitches.

A note on scope. The depth of a business case should match the size of the decision. A $5,000 tool needs a paragraph and a back-of-envelope ROI; a $5,000,000 platform migration needs the full five-move treatment with a real financial model. Matching effort to stakes is itself a sign of judgment—a thirty-page business case for a small purchase wastes the reader's time as surely as a one-line pitch for a major one under-serves it.

20.4 The Executive Summary: The Only Part Most People Read

Here is the single most important idea in this chapter, and it is a threshold concept—once you cross it, you can never write a long document the same way again.

🚪 Threshold Concept: The executive summary is not a preview of the document; it is the document.

How most writers think of it: the executive summary is an introduction, an appetizer, a teaser that goes on top of the "real" document to tell the reader what's coming. You write the real thing first, then summarize it. The reader reads the summary, gets interested, and continues into the body where the actual content lives.

How decision-makers actually use it: the executive summary is the only part most of them will read. The committee member skims it before the meeting. The executive reads it, makes the decision, and forwards your document to a subordinate with "looks fine, handle it." The body is reference material for the one person who has to implement, not narrative the decider consumes. So the summary cannot preview the decision—it must contain it. Everything the reader needs to say yes has to be in those half-page: the problem, the recommendation, the cost, the return, and the ask.

Once you cross this threshold, you stop writing executive summaries last and writing them like introductions. You write them as the complete, stand-alone case, and you assume the rest of the document will go unread by the very person whose signature you need. The body exists to survive scrutiny if someone digs in—but the summary exists to win the decision whether or not anyone digs in.

An executive summary that requires the reader to consult the body to understand it has failed at its one job. The test is brutal and simple: if the reader reads only the executive summary and nothing else, can they make the decision? If not, rewrite it.

What goes in a stand-alone executive summary, in roughly this order:

1. The situation / problem — one or two sentences, in the reader's currency.
2. The recommendation / the ask — what you want them to approve, stated plainly. This is the sentence everything else serves.
3. The key justification — the one or two facts that make the ask obvious (the ROI, the payback, the cost of inaction).
4. What it costs — the number, and the timeframe.
5. The next step — exactly what you need from the reader, and by when.

That is the whole job, in five sentences if you're disciplined. It belongs at the very top, before any background, and it must be readable in under a minute.

Here is the chapter's anchor: a real-feeling executive summary that does what most drafts do—buries the ask under throat-clearing and context—rewritten to lead with it. (This is the same before/after you'll work through in depth in case-study-01.md.)

❌ Before (the ask is buried):

In recent years, our customer support organization has grown substantially in response to increased product adoption. As our customer base has expanded, the volume of incoming support tickets has risen correspondingly, placing pressure on our existing support infrastructure and tooling. The current ticketing system, which was implemented in 2017, was appropriate for our scale at the time but has not kept pace with our growth. Various stakeholders across the support, engineering, and operations teams have raised concerns about response times, agent productivity, and customer satisfaction. After conducting a thorough evaluation of available solutions over the past two quarters, including reference calls and trial deployments, and weighing a range of factors including cost, integration capability, and scalability, we have arrived at the conclusion that adopting the HelpHub platform would address many of the challenges outlined above. We therefore recommend that the company consider proceeding with the procurement of HelpHub at an annual cost of $96,000.

That is 165 words and the reader has to reach the last sentence to learn what's being asked. The recommendation ("consider proceeding") is buried under four sentences of context the executive already knows (the company is growing; the old system is old) and hedged into near-meaninglessness ("would address many of the challenges," "consider proceeding"). Now lead with it:

✅ After (the ask leads):

We recommend replacing our 2017 ticketing system with HelpHub, at $96,000/year. The current system can't keep up with our ticket volume: average first response has slipped to 14 hours and agent productivity is down 30% year-over-year. In a two-quarter trial, HelpHub cut first-response time to under 3 hours and would pay for itself within 11 months through recovered agent capacity—equivalent to 2.5 full-time hires we won't need to make. We need approval to sign by March 15 to lock this year's pricing.**

Why it's better: It's 88 words—nearly half the length—and the recommendation is the first sentence. The justification is now concrete (14 hours, 30%, under 3 hours, 11-month payback, 2.5 hires avoided) instead of vague ("many of the challenges"). The hedging is gone: "we recommend" replaces "we recommend that the company consider," and a hard ask with a date ("approval to sign by March 15") replaces the limp "consider proceeding." A busy reader who reads only this paragraph can approve it. The "before" sends them looking for the point; the "after" hands it to them. This is Chapter 4's BLUF and Chapter 19's "one clear ask" applied at the scale that matters most.

✏️ Try This (60 seconds): Take the "before" summary and find every word between "In recent years" and the first concrete fact. Count them. That's how long you made the reader wait before giving them anything they didn't already know. Now do this to your own last proposal.

🔄 Check Your Understanding What is the single test that tells you whether an executive summary is finished?

Answer

Can the reader make the decision from the summary alone, without reading the body? If the summary requires them to flip to page 6 to find the cost, or to read the approach section to understand what you're proposing, it has failed—it's an introduction, not a stand-alone case. The summary must contain the problem, the ask, the justification, the cost, and the next step. The body is for the one person who implements; the summary is for the person who decides.

[📍 Good stopping point]

20.5 Persuasive Structure #1: Problem–Solution

The next three sections give you three persuasive structures—patterns for ordering an argument so it lands. They are not mutually exclusive; a strong proposal uses all three in different places. The first and most fundamental is problem–solution.

The logic is simple: people fund solutions to problems they feel. So before you present your solution, you must make the reader feel the problem. A solution presented before its problem is a solution in search of a need—the reader's reaction is "okay, but why do I care?" The order matters: problem first, then solution, and the solution must visibly map onto the problem.

The most common failure is leading with the solution because the solution is what you're excited about:

❌ Before (solution-first; the reader doesn't yet care): We propose implementing a real-time data pipeline using Apache Kafka and a streaming architecture. This will enable event-driven processing, improve our data infrastructure, and position us for future scalability. The system will use a publish-subscribe model with horizontal scaling capabilities.

A non-technical executive reads that and feels nothing, because no problem has been established. Why do we need real-time? What is broken now? The features (Kafka, pub-sub, horizontal scaling) are answers to a question the reader hasn't been asked. Flip it:

✅ After (problem-first; the solution arrives as relief): Right now, our sales dashboards are 24 hours stale. A regional manager who cuts prices at 9 a.m. can't see the effect until the next morning—so by the time a promotion is clearly failing, we've already lost a full day of margin. Last quarter that lag cost an estimated $210,000 in over-discounting. We propose a real-time data pipeline that updates dashboards within seconds of each sale, so managers can adjust the same hour instead of the next day.

Why it's better: The "after" spends three sentences making the reader feel a concrete pain—stale data, a manager flying blind, $210,000 lost—before naming the solution, and when the solution arrives it is described by what it does for the reader (dashboards that update in seconds, same-hour adjustment), not by its technology. The word "Kafka" doesn't even appear; it belongs in the approach section for the technical reviewer, not in the persuasive opening for the executive. The problem creates the demand; the solution satisfies it. That sequence is the engine of persuasion.

A useful refinement, drawn from the same tradition as Chapter 4's SCQA: structure the opening as Situation → Complication → Resolution. State the stable situation ("our dashboards update overnight, which worked when we had one region"), introduce the complication that breaks it ("now we have twelve regions and same-day pricing, and overnight is too slow"), then present your solution as the resolution. The complication is the hinge—it's the moment the reader realizes the status quo is no longer acceptable, which is exactly when they become willing to spend.

🧩 Productive Struggle Before reading on, try this. Here is a solution-first opening. Rewrite it problem-first, inventing a plausible, quantified pain. (You're allowed to invent the numbers for the exercise—just make them concrete.)

Draft: "We propose adopting a company-wide single sign-on (SSO) system integrated with our identity provider, supporting SAML and multi-factor authentication across all internal applications."

Attempt it, then check one possible version.

One possible rewrite

*"Our employees each manage 14 separate passwords for internal tools, and the help desk spends roughly 30% of its time on password resets—about $140,000 a year in support cost. Worse, password fatigue means people reuse credentials, which is how last spring's phishing incident spread to four systems. We propose a single sign-on system so employees log in once, securely, and the reset burden and the reuse risk both disappear."* Notice: the SAML/MFA detail vanished from the opening (it goes in the approach section), and the solution is now described by its effect—one login, less help-desk cost, less breach risk—not its protocol. The pain (14 passwords, $140K, a real incident) does the persuading.

20.6 Persuasive Structure #2: Features → Benefits

This is the most violated rule in all of proposal writing, and fixing it is the highest-leverage habit in this chapter: decision-makers buy benefits, not features.

A feature is a fact about your solution—what it is or has. A benefit is what that feature does for the reader—the outcome they care about. "256-bit encryption" is a feature. "Your customer data stays safe even if a laptop is stolen" is a benefit. Writers default to features because features are what they know; the solution's spec sheet is concrete and close at hand. But the reader doesn't want a spec sheet. They want to know what changes for them.

The translation move is mechanical, and you should run it on every feature you're tempted to list. Take the feature and ask "so what?"—and keep asking until you reach an outcome the reader actually cares about. That chain from feature to outcome is the benefit. (This is the same "so what?" test you met in Chapter 3, pointed now at value instead of clarity.)

Here is the move in a table—the single most useful artifact in this chapter to keep on your desk:

Watch the difference in a real passage:

❌ Before (a feature dump): HelpHub offers a unified inbox, AI-powered ticket routing, customizable dashboards, a robust API, SLA management, multi-channel support across email, chat, and social, and a knowledge-base module with full-text search.

The reader's eyes glaze. It's a list of nouns; nothing tells them what gets better. Now convert the features that matter into benefits, and cut the ones that don't:

✅ After (features translated to benefits): HelpHub routes each ticket to the right agent automatically, which is what cut first-response time from 14 hours to under 3 in our trial. Because email, chat, and social all land in one inbox, agents stop switching between four tools and handle about 40% more tickets per shift. And its knowledge base lets customers answer their own common questions—deflecting an estimated 25% of tickets before they ever reach an agent.

Why it's better: The "before" lists seven features; the "after" keeps three and attaches each to an outcome with a number (3 hours, 40% more tickets, 25% deflected). It also cut four features—"customizable dashboards," "robust API," "SLA management," "multi-channel" qua label—not because they're worthless but because they don't move this decision; they can live in an appendix for the technical evaluator. The reader of the "after" knows exactly what changes for them. The reader of the "before" knows only that the product has many nouns.

One caution: benefits must be true and provable, or you've crossed from persuasion into selling snake oil—a line Chapter 38 (Ethics) takes seriously. "Saving ~6 hours per rep per week" must be a number you can defend, not a number you wish were true. The most persuasive benefit is one backed by your own trial data or a reference customer. An unprovable benefit is worse than a feature, because the moment the reader doubts one claim they doubt them all.

🔄 Check Your Understanding Convert this feature into a benefit for a hospital administrator deciding whether to buy a scheduling system: "The system supports configurable shift templates and automated conflict detection."

Answer

Run "so what?" to an outcome the administrator feels: "Nurses get their schedules two weeks earlier and never get double-booked, so you stop losing staff to scheduling frustration and stop paying last-minute agency rates to cover gaps." The features (configurable templates, conflict detection) became outcomes the administrator owns (earlier schedules, no double-booking, lower turnover, lower agency costs). Note that the right benefit depends on the audience: for the nurses themselves the benefit is "predictable schedules and a fair process"; for the CFO it's "lower agency spend." Same feature, different benefit per reader—theme 2 again.

20.7 Persuasive Structure #3: Risk–Mitigation

The third structure addresses the quiet force that kills more proposals than bad ideas do: fear. A decision-maker who approves your proposal is taking a personal risk—if it fails, it's partly on them. So part of persuasion is not just showing the upside; it's reducing the felt risk of saying yes. The structure for that is risk–mitigation: name the real risks, and pair each with how you'll handle it.

The counterintuitive truth—and it surprises new writers every time—is that naming the risks makes the proposal more persuasive, not less. Hiding the risks doesn't make the reader feel safe; it makes them suspicious, because an experienced executive knows every plan has risks, and a proposal that lists none looks naïve or dishonest. By raising the risks yourself, you do three things: you prove you've thought it through, you control the framing (you get to present the mitigation alongside the risk), and you build trust that you won't hide bad news later.

The form is a simple two-column table—risk on the left, mitigation on the right:

Notice the pattern in the mitigation column: each one converts a vague fear into a managed situation with a concrete control (parallel run, 3-week overlap, price cap, buffer). The reader's anxiety—"what if the migration corrupts our data?"—is met before they voice it, with a specific answer that shows you've already war-gamed it.

Compare two ways of handling the same risk:

❌ Before (risk hidden, then forced to admit it under questioning): Proposal text: "The migration is straightforward and low-risk." In the meeting, an executive asks: "What happens to our five years of historical tickets?" The presenter, caught flat, says, "We'll, uh, we should be able to migrate most of that." Confidence in the room drops.

✅ After (risk raised proactively with a mitigation): Proposal text: "The main risk is the migration of five years of historical tickets. We mitigate it by migrating to a parallel system, validating against live data for two weeks, and cutting over only after a clean reconciliation—with the old system kept read-only for 90 days as a fallback." In the meeting, the same question gets the answer "as noted on page 4, here's our migration safeguard," and confidence in the room rises.

Why it's better: The risk is identical; what changed is who raised it. When the executive surfaces a risk you ignored, you look unprepared and you answer from the back foot. When you've already named it and shown your mitigation, the same question becomes evidence of your thoroughness. Proactive beats reactive every time—the risk you name is a risk you control.

⚠️ Warning: There's a failure mode in the other direction—the proposal that lists fifteen risks with weak mitigations and terrifies the reader. The skill is to name the risks that are real and material (the three or four that would actually keep the reader up at night) and mitigate each convincingly. A long list of trivial risks signals anxiety, not rigor. Pick the risks the smart reader is already thinking about, and answer those.

20.8 Writing for Executives: You Have Three Minutes

Everything in this chapter converges on a single audience and a single constraint. The executive who decides on your proposal is, in the language of Chapter 2, a specific reader with a specific way of reading—and that way is faster and more skeptical than almost any audience you'll write for. Internalize a few facts about how executives read, and the writing follows.

They read the executive summary and stop. We covered why in §20.4. The implication for everything else you write: assume the body is read by an analyst or implementer, not the decider. Write the summary to win the decision; write the body to survive scrutiny.

They think in bottom line, money, and risk. Not in methodology, not in technical elegance, not in how hard you worked. An executive's three native questions are: What do you want? What does it cost (and return)? What could go wrong? If your document answers those three in the first half-page, you've spoken their language. If the reader has to dig for any of the three, you've made them work.

They have no time and infinite alternatives. Three minutes is not a metaphor; a busy executive may genuinely give your proposal that long before deciding to engage or move on. So the cost of a buried point is total—not "they read it later," but "they never read it." This is the inverted pyramid (Chapter 4) with the stakes turned up: the most important thing first, because there may be no second thing.

The practical writing moves that follow from this:

• Lead with the ask, always. First sentence of the summary, first sentence of the cover email, first sentence of the slide. (Chapter 19's discipline, scaled up.)
• Quantify everything you can. "Significant savings" is invisible; "$310K over three years, 14-month payback" is a decision. Executives anchor on numbers.
• One page, then depth. Give a one-page (or half-page) summary that stands alone, then let the detail follow for whoever needs it. Match the depth to the decision (§20.3).
• Make the next step a single, dated action. Not "let us know your thoughts" but "we need sign-off by March 15 to lock pricing." A decision-maker can act on a specific ask; they archive a vague one.
• Cut your favorite paragraph. The part you're proudest of—the elegant technical explanation, the thorough background—is usually the part the executive doesn't need. Theme 6: every sentence must earn its place, and in an executive document the bar is brutally high.

💡 Tip — the "forward test": Before you send a proposal, imagine the executive reading the summary and forwarding the whole document to a subordinate with one line: "Looks good—make it happen." If the summary alone is enough for that subordinate to understand what was approved and why, your summary is doing its job. If the subordinate would have to ask "wait, what exactly did they approve?", your summary failed.

🔄 Check Your Understanding An engineer's proposal opens with two pages explaining the elegant microservices architecture they'll build, then states the cost and the business problem on page three. Diagnose the failure in executive terms.

Answer

The proposal leads with the part the writer finds most interesting (the architecture) instead of the three things the executive needs (the ask, the cost/return, the risk). An executive giving it three minutes reads two pages of microservices, learns nothing about why this matters to the business or what it costs, and moves on—the decision-relevant content on page three is never reached. The fix: a half-page executive summary up front (problem in business terms, recommendation, cost, ROI, next step); the microservices detail demoted to the approach section for the technical reviewer. The architecture isn't wrong to include—it's wrong to lead with.

20.9 Internal vs. External Proposals: Same Bones, Different Muscles

A proposal to your own leadership and a proposal to an outside client share the skeleton from §20.2, but the emphasis shifts because the reader's relationship to you—and their alternatives—is different.

An internal proposal asks your own organization for resources: budget, headcount, time, priority. Your reader already knows the company, the context, and often the problem. What they're really deciding is priority and trust—is this worth funding over the other things competing for the same budget, and do they trust you to deliver? So an internal proposal:

• Can assume shared context (don't re-explain the company to the people who run it—a Chapter 2 audience point).
• Must compete against other internal priorities, so the ROI and the cost-of-inaction matter enormously—you're arguing for a slice of a fixed pie.
• Lives or dies partly on your track record and relationships; the qualifications section is less "here's our company" and more "here's why this team will deliver."
• Often needs a named sponsor—a senior person who'll champion it in the room you're not in.

An external proposal asks a client to choose you over competitors, often in response to a formal RFP (Request for Proposal). Your reader is evaluating you against alternatives and starts from less trust. So an external proposal:

• Must establish credibility from zero—the qualifications, case studies, and references carry far more weight, because the client doesn't already know you.
• Has to answer the RFP exactly, in the order and format requested; clients often score proposals against a rubric, and an unanswered requirement is lost points no matter how good the rest is.
• Competes on differentiation—why you and not the other three bidders—so the features-to-benefits discipline (§20.6) is sharpest here.
• Is a legal-ish document: what you promise, you may be held to, so scope and assumptions must be precise.

A quick vocabulary note you'll meet in external work: a solicited proposal responds to an explicit request (an RFP or invitation); an unsolicited proposal is one you send without being asked, which is harder because you must first convince the reader they even have a problem worth solving—the problem–solution structure (§20.5) does double duty there.

The bones are the same; which muscles you develop depends on whether your reader already trusts you and what they're comparing you against. Both, though, obey the master rule of the chapter: write for that reader's decision, not for your idea.

📐 Project Checkpoint

This chapter advances the second piece of your Communication Portfolio: the research/project proposal (introduced in the academic chapters and now sharpened for a workplace decision-maker). If you drafted a proposal earlier—say, a grant's Specific Aims (Chapter 17) or a project pitch—you'll now rebuild its front end for an executive reader.

This increment: write a one-page executive summary and a problem statement for a real proposal of your own. Choose something concrete you'd genuinely want funded—a tool, a hire, a process change, a project. Then produce two artifacts:

1. A stand-alone executive summary (≤ 200 words) following §20.4's five moves: situation, the ask, the key justification (with at least one real number), the cost, and a single dated next step. Apply the finished-test: hand it to someone who knows nothing about your project and ask, "Could you approve this with just this paragraph?" If they have questions you didn't answer, the summary isn't done.

2. A problem statement (1 paragraph) stated entirely in the reader's currency—cost, risk, time, missed opportunity—not in your terms. Run the §20.2 before/after on your own first draft: write it the way you naturally would, then translate every internal/technical fact into a consequence the decision-maker feels.

Then do the features-to-benefits drill on your own solution: list the three features you're proudest of, and for each, run "so what?" until you reach a benefit the reader cares about. Keep the benefits; you'll likely find the features alone were unpersuasive.

Self-check before you file it: Does the summary lead with the ask, or with context? Is there a number? Is the next step a single dated action? Could a reader forward it with "looks good, make it happen" and have the recipient understand what was approved?

Next increment (Chapter 21, Workplace Reports): you'll write the progress and status updates that report on a project once it's approved—the writing that keeps the proposal's promises visible. Your proposal makes the case to start; the status report proves you're delivering. Keep this proposal; Chapter 21 assumes the project it describes is now underway.

20.10 Common Mistakes & Practical Considerations

The mistakes below are the ones that sink real proposals. Most are not failures of the idea; they're failures of audience and structure—the same failures this whole book keeps naming.

Burying the ask. The number-one killer, and the reason for the chapter's anchor. The recommendation hides on page nineteen, or in the last sentence of a 165-word summary. If a reader can't find what you want them to do in the first few sentences, you've buried it. Fix: lead with the ask, every time.

Describing instead of persuading. A proposal that reads like a project plan—here's what we'll build, here's the architecture, here's the schedule—forgets that its job is to make the reader want it. Description answers "what"; persuasion answers "why should I care and why now." You need both, but the persuasion has to come first and frame the rest.

Features without benefits. The spec-sheet proposal (§20.6). Every feature listed, no outcome attached. The reader learns what the thing is and never learns what it does for them. Run "so what?" on every feature.

No "do nothing" baseline. A business case that doesn't price the cost of inaction hands the reader the cheapest objection for free: "let's wait." Quantify what happens if they don't act—it's often your strongest number (§20.3).

Unquantified value. "Significant improvements," "substantial savings," "increased efficiency." These are invisible to a numbers-driven reader. If you can't put a number on a benefit, the reader assumes there isn't one. Even a rough, clearly-labeled estimate ("roughly $200K/year, based on current reset volume") beats an adjective.

Hiding the risks. Covered in §20.7. A risk-free-looking proposal reads as naïve or evasive. Name the real risks; mitigate them convincingly.

Wrong document depth. A thirty-page business case for a $4,000 tool, or a one-paragraph pitch for a $4M migration. Match the effort to the stakes (§20.3); mismatched depth is itself a judgment failure the reader notices.

Optimistic budgets and timelines. The suspiciously round number, the timeline with no buffer, the budget that omits training and migration. Decision-makers have been burned before; an honest budget that accounts for the hard parts is more persuasive than a lowball that will blow up later (§20.2). Padding erodes trust; transparent contingency builds it.

Forgetting the next step. A proposal that ends "we look forward to your thoughts" has no ask. End with one specific, dated action: what you need, from whom, by when.

Ignoring the RFP's structure (external). When a client gives you a format, follow it exactly. Scorers check boxes; a brilliant proposal that answers the questions in the wrong order loses to a mediocre one that answered them in the right order. Your creativity goes into the content, not into reorganizing their rubric.

A decision framework to keep at hand:

Frequently Asked Questions

What's the difference between a proposal and a business case?

A proposal asks "will you let us do this?"—it presents a plan (problem, solution, approach, timeline, budget, team) and seeks approval to execute it. A business case asks "is this worth doing, and which way?"—it compares options (including doing nothing), analyzes cost and benefit, and recommends one, justified mainly by the numbers. They often combine: a strong proposal contains a business case (the part proving the investment pays off), and a business case usually ends by proposing a path. Pick the one that matches the open decision: if "whether and which" is unsettled, lead with the business case; if the plan just needs a yes, lead with the proposal.

How long should an executive summary be?

Short enough to read in under a minute—typically a half-page, often one to two hundred words, rarely more than a single page even for a long document. Length isn't the real target, though; self-sufficiency is. The test is whether a reader who reads only the summary can make the decision. If yes, it's the right length even if it's three sentences. If they'd have to consult the body, it's too thin no matter how long it is. Lead with the ask, include at least one number, end with the next step.

How do I turn a feature into a benefit?

Take the feature (what the thing is or has) and ask "so what?"—then keep asking until you reach an outcome the reader actually cares about: saved money, saved time, reduced risk, less hassle. "Automated backups" → so what? → "you never lose more than a day's work" → so what? → "even if a server dies, you don't re-key lost orders." That last clause is the benefit. Crucially, the right benefit depends on the audience: the same feature becomes "lower agency costs" for a CFO and "predictable schedules" for the staff. Always state the benefit, not just the feature, and make sure it's provable.

Why should I include risks in a proposal? Won't that make it weaker?

The opposite—naming risks makes a proposal stronger, because experienced decision-makers know every plan has risks and distrust one that claims none. Raising the risks yourself proves you've thought it through, lets you control the framing by presenting the mitigation alongside the risk, and builds trust that you won't hide bad news later. Use a two-column risk–mitigation table: the real, material risks on the left (the three or four a smart reader is already worried about), a concrete control for each on the right. The risk you name is a risk you've shown you can manage.

How do I write for an executive who only has a few minutes?

Assume they read the executive summary and stop. So put the three things they care about—the ask, the cost and return, the main risk—in the first half-page, in their language (money, risk, bottom line), not yours (methodology, technical elegance). Lead with the ask, quantify everything you can, give a one-page summary that stands alone before any detail, and end with a single dated next step. Cut the paragraph you're proudest of if it doesn't serve the decision. The mental test: would the summary alone let the executive forward the document with "looks good, make it happen"?

Chapter Summary

Key takeaways

• A proposal seeks approval for a plan ("will you let us do this?"); a business case justifies an investment and chooses among options ("is it worth it, and which way?"). Pick the one that matches the open decision.
• A proposal's standard parts each answer a reader's question: problem (why care?), solution (what?), approach (how, credibly?), timeline (when?), budget (what cost, trustworthy?), qualifications (why you?), risks (what could go wrong?), and the ask (what do you need from me?).
• The executive summary is the document, not a preview of it—most decision-makers read only it. It must stand alone, lead with the ask, justify with a number, state the cost, and end with a dated next step.
• Three persuasive structures: problem–solution (make them feel the pain before naming the cure), features→benefits (run "so what?" to the outcome the reader cares about), risk–mitigation (name the real risks and pair each with a control).
• Write for the executive's three minutes: the ask, the money, the risk—first, in their language, quantified, with one clear next step.

Action items

1. On your next proposal, write the executive summary first and apply the stand-alone test before drafting the body.
2. Run "so what?" on every feature until it becomes a benefit; cut the features that don't move the decision.
3. In any business case, price the "do nothing" option—it's often your strongest number.
4. Build a risk–mitigation table for the three or four risks your smartest reader is already worrying about.
5. End every proposal with a single, dated ask—never "let us know your thoughts."

Common mistakes

Burying the ask · describing instead of persuading · listing features without benefits · omitting the cost of inaction · unquantified "significant" value · hiding risks · mismatched document depth · optimistic budgets/timelines · no concrete next step · ignoring an RFP's required structure.

Decision framework

Spaced Review

A few questions reaching back, to strengthen retention.

1. (From Chapter 18) You're presenting a research poster, and a colleague says they put every result on it so visitors get the full picture. Using the assertion–evidence idea and information hierarchy, what's the flaw, and how does it connect to this chapter's point about the executive summary?
2. (From Chapter 16) A doctoral student's thesis proposal keeps expanding in scope. What's the single discipline that keeps a long project document defensible—and how is "match the document's depth to the decision" (this chapter, §20.3) a version of the same idea?
3. (From Chapter 19, bridging) Chapter 19 said a request email needs one clear action and a deadline. How does an executive summary's "single dated next step" apply that same rule, and why does the stakes being higher make the rule more important, not less?

What's Next

Chapter 21 (Workplace Reports) picks up where the proposal leaves off. Once a decision-maker approves your proposal, you owe them a stream of writing that proves you're delivering: progress reports, status updates, and—when something breaks—incident reports. Where this chapter was about persuading someone to start an investment, Chapter 21 is about reporting on it once it's running, in the scannable, exception-based formats busy stakeholders actually read. The audience discipline carries straight over: a status update, like an executive summary, is read by someone with no time who wants the bottom line first.

Practice: Exercises · Quiz Go deeper: Case Study · Case Study 2 Review: Key Takeaways · Further Reading