Writing a proposal for help desk software

Recently, I had the chance to combine my technical writing skills with my experience as a help desk analyst. In checking the Legal Notices section of my local newspaper, I noticed the following listing placed by a state government agency: “Request for Proposals: Customer Service Database Call Tracking System and Related Services.”
I telephoned a friend who works at a custom software company and said, “You ought to bid on this job—it sounds like it’s right up your alley.” He said, “Why don’t you write the proposal for us?”

So I volunteered my time to write the proposal, in exchange for a cut of the pie if my friend’s company was awarded the contract. While this specific proposal was for a software development project, the tips listed below are applicable to any type of RFP. And for those who provide contract development or IT support, RFPs are a fact of life. Here are some of the lessons I learned during the process of writing the proposal.

Lesson 1: Read every word of every document
When you’re responding to a Request for Proposal (RFP), the first thing you must do is clearly identify what you’re being asked to provide in your proposal. This RFP consisted of three documents:

The general conditions—This document spells out what the legal relationship will be between you (as the vendor) and the government agency, if and when you’re awarded the contract. In this case, the general conditions included instructions on how invoices are to be submitted, how the contract may be terminated, whether and how the contract may be modified, and ownership of the software being created.

The solicitation instructions—This document explains how vendors are supposed to submit their proposals. If you overlook the tiniest detail from this document, your proposal won’t even make it to the committee that awards the contract. For example, in this case, the solicitation instructions specified exactly how to address the sealed envelopes in which copies of the proposal had to be submitted. Based on my reading of the legalese, your proposal could be “kicked out” of consideration and passed over if you make the slightest mistake in addressing the envelopes.

The RFP specifications—This document tells you what the customer wants. In addition to the details of the project, the document in my case also contained additional solicitation instructions.

My advice is simple: Don’t even think about starting to write your proposal until you’ve read all of the documentation at least twice. If you’re able to download soft copies of the documents—all of my agency’s files were Word documents—search for key words such as “mandatory,” as in “mandatory submissions,” and “required” or “requirements.” That will help you cut through the clutter so you can figure out what you must write.
On my second and third passes on the documents, I used a highlighter to bring attention to those key words and to any other sections that required action by me or by my client. Here are the items listed under the Mandatory Submissions section of this RFP:

List of References

Vendor Profile

Statement of Work

List of Exceptions

Completed Pricing Schedule

Completed and Signed Proposal Certification

Lesson 2: Make a list of deliverables
When you’re writing the proposal, you must also act as project manager and make sure that your client provides all the information you need. After thoroughly reviewing the RFP materials, I had a meeting with the folks at the software development company, and I passed out assignments.

To the business manager, I assigned the task of gathering a list of references. This list had to include customers for whom the company had provided similar services or products, contact names and information, years of association with the client, description of goods or services provided, dates of service, and the approximate dollar value of work the company has done (or is doing) for that customer.

The president of the company filled out the vendor profile, the proposal certification, and the pricing schedule. The profile indicates whether the company is minority-owned, how long the company has been in business, and other information about the company itself. The proposal certification had to be signed in ink by a principal officer of the company.

The pricing schedule had to be submitted in a separate, sealed envelope, apart from the proposal itself, and clearly labeled as “Company ABC’s Pricing Schedule.” According to the general conditions document, the agency would open the pricing envelope only after a proposal had made it through two levels of review.

In our case, we didn’t have any items for the “List of Exceptions.” However, in the proposal binders, I included a page labeled “List of Exceptions.” On that page, there was one sentence: “The Offeror has no exceptions to list.”

Last, but certainly not least, the task of writing the “Statement of Work” was left to me.

Lesson 3: Overlook no detail
My friends, when I read the agency’s description of their situation, I almost laughed out loud. Here was a government agency with a multimillion dollar annual budget, admitting for the world to see: “The Agency currently tracks incoming calls using an Excel spreadsheet. The calls are entered into the spreadsheet, and reports are generated manually.” I’m only paraphrasing a tiny bit.

The “Minimum Requirements” section described the functionality the agency expected to be part of the “customer service database call tracking system.” Here are some of the items from the list of attributes:

“The proposed system should automatically assign a unique number for each new call. The number will be used to identify the call.

“For every call opened, updated, or closed, the user will have the ability to enter free-formatted text describing the call.

“A unique category code will be assigned to identify the type of call (i.e., customer, vendor, complaint, question)."

There was also a list of reports that the system would be expected to generate. Those reports included a staffing report, which would be generated daily and that would list the calls in the order in which they were received. According to the RFP, the staffing report would be used to “track incoming call volume.”

Another report, called “Inquiry Report,” would group and subtotal the calls by type. The RFP specified that the report would be generated “weekly and ad hoc.”

Think like the customer
At first blush, some of you are probably thinking, “Why do they need to purchase a custom system to do these kinds of things?” Others of you are thinking, “Heck, I could knock that project out in Access in no time.”

The trick to writing the proposal, in my opinion anyway, was not merely to write a design specification that covered all of the bullet points in the RFP. To get the contract, I reasoned, we had to write a proposal that anticipated all of the things the agency had not included in its RFP. We had to think like the customer.

The person who wrote the RFP had taken a stab at describing the database structure for the customer calls table. However, it was a primitive, single-table design.

When I wrote the design specification, I laid out a relational database design, with one table to store individual call records; one table to store names and addresses for known customers, to be looked up based on the telephone number entered by the user; and another table to store the comments; and so on.

The software company (my partner in the proposal) uses Visual Studio as its primary development tool, so they didn’t really care how I mocked up the sample screens in the proposal document. I used Access 2000 to set up sample tables and forms so I could capture realistic-looking screen images of data entry screens and report screens.

The RFP was silent on the issues of password-protection for logons and how and when the data would be backed up and archived. Our feeling was that we should give the client more than they asked for, so we included sample logon screens and maintenance screens that included backup and archive options.

In other words, we tried to write a design specification for the best customer-call tracking database we could imagine, even though the RFP—strictly speaking—described a less-robust system.

The hardest part: Being patient
A few days before the deadline for proposals, I met with the folks at the software company, and we reviewed every page of the design specification in excruciating detail. When we were done proofreading, we purchased a half-dozen three-ring binders with color-coded tabs. (The RFP required six copies of the proposal, each under separate cover.) We printed and punched the documents, assembled the packages, and affixed the special address labels.

At this writing, we have learned that our proposal has passed the initial evaluation. (That simply means we didn’t overlook any of the documents required in the solicitation instructions.) However, the committee has yet to meet to begin evaluating the proposals for technical merit.