The Sentence That Became a Contract

The line that would have cost us was one sentence long, and it was good writing. "Our team will resolve all critical and high vulnerabilities within twenty-four hours of detection." Clean, confident, specific. The subject matter expert (SME) who wrote it meant it as a statement of competence, the kind of thing you say to show you take security seriously. He did take security seriously. That part was never in question.

The problem was the document it landed in. We were writing a performance work statement (PWS) of our own. The government had handed us objectives and asked bidders to define the work, so we were the ones setting the standards, and in that kind of document a sentence like his does not show how good you are. It becomes a number the government can hold you to for the next five years. Twenty-four hours, every finding, measured and reported, with consequences attached when you miss. Nobody on the customer side had asked for twenty-four hours. He volunteered it, because in his world it was a plain description of doing the job right.

I caught it on a read-through, and we changed it. But it stuck with me, because the SME did nothing wrong by the only frame he had. He was handed a section and a deadline, and no one told him that the document he was writing into turns descriptions into promises.

Here is the part nobody explains when you get pulled in. You are not always doing the same job, even when the writing looks identical, because there are two different kinds of document you can be writing, and they put you in opposite relationships to the work.

Most of the time, you are responding. The government has already defined the work in a statement of work (SOW) or a PWS that it wrote, and your job is to describe your approach to performing a scope someone else set. The requirements are on the page. The standards are on the page. You are showing that you can execute known work well, not deciding what the work is. The latitude there is narrow on purpose, and rebuilding an approach the government already chose reads as having missed the requirement.

The other case is rarer and carries far more weight. Sometimes the government issues a statement of objectives (SOO), which gives you the objectives it cares about and almost nothing else, and asks bidders to develop the PWS themselves as part of the proposal (this is performance-based acquisition, FAR Subpart 37.6 if you want the citation). Now you are not responding to a scope. You are authoring one. You define the tasks, you propose the standards, and if you win, what you wrote becomes the bar you live under for the life of the contract.

You never write the SOO. That document is the government's, and it stays the government's. What you write back is the PWS. So you are always in one of two relationships to the scope, either describing work that someone else already defined or defining it yourself.

That is the whole distinction, and it changes what your sentences are doing. The twenty-four-hour line lived in the second case. The SME, trying to be thorough, wrote a standard tighter than anything the objectives required, and because we were authoring the PWS, his description was about to become our commitment.

You can usually tell by reading what you were handed. A package that hands you requirements, tasks, and the standards already written puts you in the responding seat. A package that hands you objectives and asks you to develop the PWS puts you in the authoring seat.

The seat sets the discipline. Responding, your job is to show your approach to a scope someone else set, so describe your work against the defined requirements and resist the pull to redesign them. One caution even here: the methods you commit to can be incorporated into the contract if you win, so you have less room to over-reach but you can still over-promise.

Authoring, treat every sentence as contract language, because that is what it may become. Read your own writing the way the government will read it, as a set of commitments rather than a set of descriptions. Propose standards you can defend for the full performance period, not the most impressive numbers you can think of in a draft. The ambitious specifics that feel good to write are exactly the ones that cost you later, because you will be measured against them long after the proposal is forgotten.

There is one question worth asking your proposal team before you start, and it costs them about thirty seconds: am I responding to requirements the government already wrote, or am I helping write the PWS, and which of my sentences become binding if we win? The answer reshapes how you write everything after it. Asking it marks you as someone who understands what the document does, which is the opposite of needing your hand held.

It comes down to two pens. With one, you are describing your work against a scope someone else drew, and the discipline is fit and approach. With the other, you are drawing the scope yourself, and the discipline is restraint, because every standard you set is a standard you have agreed to meet. The same paragraph of solid technical writing is a compliant answer in the first case and a five-year obligation in the second, and nothing in the writing itself tells you which. Only the document does. Knowing whether you are responding to the work or defining it is knowing whether your words describe or commit, and that is worth settling before you write the first sentence.

The Proposal Stack publishes biweekly for technical GovCon professionals. If this was useful, forward it to someone who's about to write a section without knowing whether they're responding to the work or defining it.