Not long ago, I was asked by a client what my "secret sauce" for writing great proposals is. I thought about it, and realized there is no secret! Writing clearly is the first step. The second is applying tried-and-true techniques picked up from being a magazine journalist, a technical author, and, yes, even a poet.
In more than 20 years in the business, I have found that if I'm writing regularly about technology, management, and other topics, it makes sense to get hands-on. As a technologist and management consultant, I am able to incorporate my expertise into technical responses. Here is a snapshot of my approach to making a technical response stand out:
I build an accurate "fact bank," a series of statements describing the company and its past performances. Before I start filling in the bullets from the "pink" version of the technical response, I go through source material for the company and write down 5-10 sentences that precisely describe the successes of the firm, how the team works, major features of our solution, and how those features translate into important benefits. During on-going review, Workbench notifies the client, so that they review the "fact bank" and make any necessary corrections, additions, or deletions. After they do that, I incorporate their edits. Now I have the body of pre-approved content I use to construct the technical response, and I know what I'm writing is factually accurate. The clients is able to review drafts, stored in the document management tab in Workbench, knowing a draft addresses the PWS/SOW in a compelling way that's on the mark.
When I'm chasing content on subjects I am not personally expert in, I do three things:
- I do basic research into the topic. For example, when addressing a requirement to assess IOT vulnerabilities, I found a library of white papers from IBM that provided the meat-and-potatoes of a technical model. IBM's approach, available under Creative Commons license, is a sensible one that knowledgable staff can implement.
- I interview subject matter experts (SMEs) within the organization. When I was tasked with writing a response for Customs and Border Patrol (CPB) to design and implement a processing center, I could write authoritatively about the IT systems requirements. But for the architectural aspects, I contacted the teaming partner, a building design firm in Texas, to interview one of their senior architects on an optimized design approach. I incorporated that information into the overall winning response.
- Finally, I ask the client for PowerPoints from their engineering team. Having been one, I know engineers in particular tend to be visually oriented, and it benefits the response to have visuals to accompany technical copy. The "meat" of an idea can be extracted from the visual -- then I write a clear, descriptive caption for it. Translating ideas from a visual into text helps everyone understand technical concepts.
On the subject of capturing information from SMEs, I often conduct interviews over the phone. But occasionally I get SMEs who prefer to express themselves other than verbally. In those cases, I offer to email them questions so they can email me their replies. Often those people with technical aptitude may not speak English as a first language, but can compose emails well enough. If responses are unclear, I rewrite them in plain English and then reply back with my rewrite for review. Usually the SME makes a few minor edits, and after that, I can move forward incorporating into the larger technical response.
Not rocket science, and perhaps Mr Herger, my 11th grade English teacher at Good Counsel, might recommend a few more tips. But this is a good start on drafting technical proposals that stand out.