How to Read a Solicitation: Optimized for Writing

A section draft lands on my desk. The technical writing is excellent. The subject matter expert (SME) who wrote it knew the domain cold, and it showed in every paragraph. They took each of their assigned requirements, drilled straight down into it, and wrote a deep, accurate response to every line. Then they bolted three sentences of compliance language onto the end, as if to say "and yes, we will meet all stated requirements."

It was a checklist answered perfectly. It was also going to score in the middle of the pack, and the SME had no idea why.

This is a common place to write from. It comes from a reasonable-sounding belief about what reading a solicitation is for, and the belief is wrong.

The belief worth killing first is that your job is to write to the requirements, and that doing so completely is the goal.

Compliance is the floor. Everyone serious clears it, which means clearing it earns you nothing. Proposals are won on whether you can demonstrate that you understand what the government is actually trying to accomplish, and why the requirements exist in the first place.

Nobody hands you a method for this, so the natural default is to answer each requirement at face value: "the requirement says X, so here is how we do X." That produces a technically perfect response that scores in the middle. The response that wins shows you understand why the government asked for X: what problem it solves, where it sits in the larger thing the government is trying to build, what would go wrong if it were done badly. Same requirement, entirely different proposal.

You cannot write the second kind by working each requirement on its own. You get there by reading the solicitation well enough to see the shape of the whole first.

This issue is about how to read one.

Solicitations run from ten pages to well over a hundred. You are not going to read all of it, and you should not try. Reading a solicitation well is a matter of knowing what to look for and in what order.

One thing nobody tells technical people, and you deserve to hear it plainly: these documents are often badly organized, and they are almost never written to be read by a technical person. So when you read one and think "this is a mess, why is this scattered everywhere," you are not failing to understand it. It really is a mess. Knowing that is half the battle, because it tells you to stop expecting a logical document and start hunting for specific things.

And put the idea of "Section L, Section M, Section C" out of your head. You will hear proposal people talk this way. It is industry shorthand for a federal format that a lot of departments and agencies frequently do not follow in practice. Sometimes you get a clean attachment list with L, M, and C broken out. Most of the time you get a combined package where none of it is labeled that way. Do not search for section letters. Search for meaning. Here is the order I use.

Start with background, scope, and purpose. This usually lives in the Performance Work Statement (PWS), the Statement of Work (SOW), or the Statement of Objectives (SOO). Which one it is does not matter for your purposes, because they all open by telling you what the government is trying to achieve.

This step matters more than it seems, especially if you are being pulled in cold. The capture team has lived with this opportunity for months. You are seeing it for the first time. The front matter is how you catch up on what the government is after before you read a single requirement.

Use your find function and search for "evaluate" and "evaluation." This is the most important step, and it's the one a face-value reading skips entirely.

The evaluation criteria tell you how the government plans to choose a winner, and that governs how you write. Two distinctions matter most. The first is the source-selection approach: is it lowest-price technically-acceptable (LPTA), or a best-value tradeoff? The second is whether the award is competitive or sole-sourced. These are not trivial. Under LPTA, you are rated acceptable or unacceptable and then judged on price, so the innovation and the value-adds and the "here is how we go above and beyond" mostly become wasted effort, unless they are specific and germane to what you are proposing. Worse, a section padded with them adds risk and noise an evaluator can hold against you. You only know to write lean, or expansive, if you read the evaluation criteria first.

You are a technical SME. You are almost certainly not writing the project management section. Every solicitation has one, and it's usually not your job, so you don't need to read it closely.

There is one exception. You need to know what management approach the team plans to use, because it changes how the work actually gets done and therefore how you write about it. A traditional, plan-driven approach implies a different rhythm of work than an Agile one. Describe your technical work in a way that contradicts the team's stated management style and you have created a seam an evaluator can see. Get that one fact, then move on.

Now go to where the government broke the work into chunks. These are usually called task areas, though you will also see tasks, performance objectives, or contract line item numbers (CLINs) depending on the solicitation. The label is beside the point. This structure is the government's own logic. It is how they decided to divide the problem, and your assigned section lives somewhere inside it.

Work big to small. Find the chunk you are responsible for, say a cloud migration task area. Then decompose it. What is the government actually asking for here? What technologies are in play? What outcome are they describing underneath the requirement language? You are not memorizing the solicitation. You are understanding your chunk well enough to write something that fits the government's logic instead of fighting it.

That is the whole method. Front matter for the what, evaluation criteria for how they will judge, the PM section for the one fact you need, and your task area decomposed from the top down. Four targeted passes instead of one exhausting read.

Reading a solicitation well is a matter of precision. Thoroughness is the trap. A flawless response to requirements read in isolation does a great deal of work to land on the floor, and meeting every requirement is necessary but never sufficient. Understanding the purposes behind the requirements is what actually gets scored, and you reach it by seeing the whole before you decompose your part.

The SME who does that writes less and wins more.

The Proposal Stack publishes biweekly for technical GovCon professionals. If this was useful, forward it to someone who's about to open a solicitation for the first time.