If you’re drafting proposals, it’s a sure bet that sooner or later you’ll write past performance narratives. On the surface it seems simple enough: describe what you did. But too often, even experienced writers fall into the same three traps. Below we provide an overview of these pitfalls and how to avoid them.
PASSIVE VOICE
The problem. How often have you seen a sentence like this? “After the system was redesigned, the data was migrated to the new server.” While technically correct, this kind of passive language makes for weak proposals. Why? Because it removes your company’s efforts from the equation. Here the system is the subject, and the reader’s focus is on it—while your company’s role is quietly erased.
The fix. Instead of “After the system was redesigned…” simply switch to “After we redesigned the system…” That phrasing makes “we” the subject, instead of “the system.” In, say, a scientific paper, we don’t really care who did the work—we only care about the results. But in writing up past performance, the important thing is not just that the work was done, but that your company did it. By casting your company as the subject of the sentence, you subtly shift the reader’s focus: it’s not just a successful project, it’s your successful project.
VAGUE LANGUAGE
The problem. When asked to write a past performance narrative, many writers simply rephrase the Performance Work Statement (PWS). “The contractor shall redesign communication protocols” becomes “We redesigned communication protocols.” Period, end of description.
There are two problems with this approach. Firstly, if the Government has access to the PWS, it’s immediately obvious that you copied it. That makes you look lazy—not the image you want to project. (Moreover, the Government often explicitly forbids copying the PWS, meaning you risk noncompliance). Secondly, it makes for a boring and uninformative narrative.
The fix. Remember that past performance narratives are just that—narratives. You’re telling the story of what you did. Like any good story, a successful past performance narrative has a conflict and a resolution. Likewise, it has concrete details to make the story more vivid. Take a look at this alternate version:
Due to inefficiencies in existing communication protocols, the customer’s project managers often received conflicting sets of information, which had to be reconciled before work could proceed. This led to severe workflow slowdowns, costing the customer approximately $1M annually in wasted hours.
Just like that, we have a conflict. Granted, it’s not a nail-biter, but we’ve introduced a problem and the reader is at least mildly interested in how it will be resolved. Moreover, we have specific details that make the problem more palpable: instead of a vague sense of inefficiency, we know exactly what’s at stake: $1M every year.
Next, we need a resolution. Again, there’s a temptation to be vague here: “We redesigned communication protocols.” True, but there’s more to the story. To get there, you conducted interviews with key team members to identify the root causes of the inefficiencies, designed several alternate communication flows, compared them to determine which would be most effective, and so on. In other words, your work was much more complex than the bland PWS description implies. Give yourself the credit you deserve!
IRRELEVANT DETAILS
The problem. Some writers see a blank page and panic. Worried about how to fill the space, they include every piece of information they have. The problem is that past performance narratives are nearly always page-limited, meaning any space spent on extraneous information is lost space that could have been used on something more persuasive. For example, let’s say you’re proposing on an application development project. Here’s a poor example:
In this project, we developed a new application and installed a new server. The server was a Brand X V400 SuperServer featuring advanced wireless widget integration. To install it, we removed the existing server and rerouted 42 feet of overhead cable in three rooms.
The passage is detailed—but it’s not relevant. We may be great at installing servers and rerouting cable, but that tells the Government nothing about our ability to develop applications. The evaluator loses interest, starts skimming—and likely misses out on other details that are important.
The fix. Go through what you’ve written, sentence by sentence. Is each sentence demonstrating your ability to do this specific job? If not, cut it out and use that space to give additional relevant information.
Just by keeping these three tips in mind, you can transform your past performance narratives from yet another checklist item to a persuasive part of your proposal—giving you an edge you need in the ultra-competitive federal marketplace.