Recently, a colleague (DD, not to be confused with D2) called asking my help on proposal writing. She was relatively new to the field, and it was vexing her. The big complaint she had was, “When I ask the engineers, ‘How are you going to do X?’ or ‘How does that work?’ they didn’t know. Aren’t they supposed to?” This brought up a point I hadn’t considered in a while because I’d adsorbed it early in my career: what, exactly, are you writing about in a proposal when you’re writing the technical approach?
The technical volume in a proposal is where you discuss the heart of the effort: what sort of widget/solution are you going to deliver for the customer? A conscientious writer like my pal DD, who is used to explaining processes in her writing, assumed that this section would describe how that work would be done and how the technical solution actually would function, which is true to some extent. The management volume of a proposal, for example, will explain how your organization will organize its project team to deliver the product or service in question. Wouldn’t the same thing apply to the technical solution? Not always.
When the Solution is Something That Has Been Done Before
If the solution is an existing product that can be sold “out of the box” with very little tweaking (say, by adding the specific software fields your customer wants to capture or adding a simple physical interface), that’s a solution that can be explained easily. The team likely has done that type of work before and even knows exactly how long it will take to do it. In some cases, if the solution is something that can be sold as is, the customer might issue only a Request for Quote (RFQ) rather than a Request for Proposal (RFP) because the product or service being requested is a known quantity.
When the Solution is Something That Has Not Been Done Before
However, if there are multiple ways that a solution will interact with another system, an existing tool is being asked to do something it wasn’t designed to do, or of the customer’s problem is wholly unique, the description of the work will take some creativity. Until the engineers talk with the customer and see all the details of the problem to be solved, they have to guess to some extent. Given that context, the answer to DD’s question is no, they cannot describe exactly how they will deliver the solution and how it will work because until they see the problem in detail, they don’t know yet.
Assuming they have a set of existing tools and have worked on similar problems before, the engineering team can use that experience to explain how they would approach the problem. Yet until they’re awarded the contract and start working, they don’t know exactly how the process will go.
Where the Technical Writer Adds Value
This is why the management and past performance volumes (sections) in a proposal also matter. Understanding a bidder’s technical approach, management approach, and past performance dealing with similar problems help a customer decide who might make the best candidate. Where the technical writer comes in is by incorporating marketing language into a proposal and by serving as an advocate for the customer or end user. Marketing language would be including explanations of how the company’s tools and approach will make the development process or outcome easier or better than others’. Being an advocate for the end user would be including explanations of how the solution will save time, money, or effort or how the proposed solution will increase productivity, precision, or output.
As I told DD, it’s not just a matter of explaining how wonderfully an existing product works: you need to make the customer understand “What’s In It For Me (WIIFM)?”
