Editor’s Note: The following piece, by the late, great Herman Holtz, was to appear as part of Herman’s “Hindsights & Insights” column. It is part of our collection of “classics”–articles that stand the test of time no matter how many technologies come and go. Published with permission.
It is easy to be misled by the phrase “proposal writing,” which appears to stress the importance of writing. A proposal must be written, of course, but success in winning the contract depends on project design and salesmanship, as well as on writing. Even that is misleading because all are interdependent elements of success. The best design must be sold (how else will the client know that yours is the best design?), and the presentation must support the sales strategy. To adapt an old lawyer’s joke, if you have an excellent design going for you, you pound technical superiority. If you have a low price going for you, you pound savings. And if you have neither going for you, you pound the table (rhetorically, that is). But pounding the table–depending on sound and fury–is rarely an effective strategy.
Before you begin developing a proposal, you must first understand what it is that you need to pound. In particular, you must first understand what the Statement of Work (SOW)–the component of the Request for Proposal (RFP) that outlines the work needed–is asking for. Some SOWs are clear and specific; in this case, the writer of the SOW has all but dictated what you need to do. Other SOWs describe a need but leave it to you to design and describe the project necessary to satisfy their needs. And, fortunately or unfortunately, depending on your perspective, many RFPs and SOWs are completely unclear, describing symptoms rather than problems and needs. In this case, you may need to gain the information by inference, your own experience with similar situations, and even guessing–by reading between the lines, in effect.
Especially when working with unclear and poorly developed SOWs, you may find pinpointing those needs to be a challenging process. There are aids, though, that you can employ: specifically one called the functional flowchart, which is somewhat akin to storyboard methods. That is, you start by translating the words of the SOW into a flowchart that illustrates the phases and functions of the solution you’ll ultimately propose:
FIRST STEP> SECOND STEP>… Nth STEP>… FINAL STEP
How do you actually construct the flowchart? You create the flowchart through a process of reading, rereading, and extracting key words and descriptions from the SOW. With each subsequent reading, you refine the flowchart based on new tidbits found. Depending on the SOW, you may find it easy or difficult to sketch the first draft of the flowchart:
- A highly defined SOW is relatively easy to translate into a functional flowchart. You sketch the flowchart based on the details and information provided.
- An unclear SOW may offer you little help in developing a flowchart. You may be able to sketch in the last block, projecting the needed end-product, and possibly the first block, describing what you have or must do as the first step. You must then conjure up all the blocks leading from start to finish.
- A poorly developed SOW may not provide any obvious cues. In this case, you may struggle to get more than the leftmost and rightmost blocks in the first reading. You must rely on scouring the RFP and SOW for clues through repeated readings. Every gap or anomaly you find in the developing flowchart tells you what to search for in another reading of the SOW; the clues are often there, but the specifics may not be obvious. It’s amazing, you find, how much you missed in the first half-dozen readings. In poorly developed SOWs, you must now rely on detective work, your own knowledge of how such work is normally done, logical bridging through extrapolation, and sheer inspiration to complete the flowchart, troubleshoot it, and refine it.
I find it best to read the RFP and SOW with a large pad beside me and to sketch as I read. That helps me visualize the project, and I wind up after the first reading with a rough sketch and a beginning picture in my mind. If I am leading a team, I assemble the team before a large white board, and we develop the draft flowchart together in a brainstorming session. As a result, we can draw on each other’s observations, develop a thorough flowchart, and get the same project picture in mind.
In the end, the flowchart not only becomes part of your proposal, but is also a critical tool in developing your strategy and proposal. Throughout the process you may find errors, logical/illogical functions and phases, inadequate or unnecessary functions, and other problems. Many of these will stand out starkly from the flowchart, even when they were not readily apparent in the SOW. As a result, flowcharting can help you develop a solution that will meet client needs and develop a winning strategy for landing the contract. Additionally, providing a hard-backed copy of the flowchart as an exhibit to be displayed while the client reviews your proposal not only helps the client evaluate your proposal, but also helps make your proposal more memorable.
Some Inspiration on Inspiration
Studies have been made of how inventors and designers of all kinds stimulate their creative imagination. There are three stages in creation: concentration, incubation, and inspiration. First, you concentrate and work consciously to seek ideas and answers. Those exhausted finally, you incubate the problem by turning your attention to entirely unrelated matters. Ultimately, your subconscious delivers a solution to your conscious mind in what we call inspiration. It’s like struggling to remember a name or number you know so well but can’t recall–until much later, when it suddenly pops into your head unbidden! Practice this method of wooing inspiration when developing flowcharts and proposals!
