Day 1
I was responsible for the “solution architecture” piece. The request had already given the code-drop date, which was going to be in three months. This told me that they had probably estimated the project already in some fashion or at least the budget. It also indicated that they already knew what technology it was going to be in and they had a fair amount of idea about what kind of product they were going with.

Someone in technical sales told me, “no Microsoft”. I asked why and the answer was “well I remember hearing somewhere that they are looking for a J2EE solution, and also, we don’t have any in-house expertise on that”. Good reasons? Maybe or maybe not. Again, important to know such tribal knowledge, which can prevent you from going down a tangent path.

Day 2-5
With four days left, my initial thought was that it was sufficient time to come up with a decent very high level architectural proposal, if I took the initial approach of comparing couple of options. I wanted to compare Microsoft’s and Sun’s solution. The project manager immediately questioned this approach and asked why we wouldn’t simply recommend a solution. I thought to myself, well unless I compare options myself, how would I recommend it to a client and on what basis?

The person in-charge of the whole affair asked me my recommendations on building portals with pre-built shopping cart software and other functionality. My response was to go with third party or build one. He said there is no time to build one. I could sense that he was trying to gauge, how confident I was in terms of coming up with a viable solution in ten minutes. On the surface it seemed that everyone else had a pretty good handle on how to go about this. In retrospect, the whole affair was very chaotic. Chaos is not a bad thing sometimes, but it is apparent that we did not have proper process in place which could even guide us towards a goal. So I sat down to write my thoughts on what some best practices should be. I came up with a list which by no means is exhaustive. However, I have tried to capture the approaches which were absent and seemed to contribute to the chaos the most.

Following are some things to keep in mind when responding to a RFP:

Must have a document collaboration system in place. Multiple authors working on separate copies of a document adds to the misery of formatting, collating, merging. We actually lost content due to such problems. A document version control system is a must. Some organizations have Sharepoint, but something as simple as a wiki software or open source document management software such as Alfresco will suffice.

A writer & document expert must be on the team from the start. Flair for writing is a talent available in lesser quantities in technical teams. Having a writer guide the proposal effort helps with the language and keeping varies styles consistent. Not all of us are word processing software experts. Someone who does this for a living such as a technical writer or author must be part of team. I cannot recover the hours we spent trying to make bullet points consistent and format tables.

Avoid Copy Paste Misery. Most proposals are not written from scratch. Most are a customized version of bits and pieces captured from previous responses. Given such highly reusable nature of responses, it goes without saying that responses should be easily accessible, word-searchable (google desktop does a nice job of searching word documents), highly modularized. All of the above will make it easy for people to quickly assimilate content from disparate proposals.

Get the team into selling mode. The team must be able to visualize what the requester is hoping for. Upfront there is little or no formal effort spent on this. Key people are sent off in their directions to fetch appropriate content. What exactly defines this appropriate content is based on the requester and their problem. The team must start thinking of what is being expected, what the general tone of the RFP is? A common platform and pitch must emerge in the initial hours and the team must remain on message throughout their effort.

Tackle hard questions early on. A natural tendency for the responder will be to focus on their core competencies and worry about fringe unknown areas later. This translates into not worrying about the fringe areas at all. A good response will have all the areas of the proposal covered, not just the areas they are comfortable with. Make a list of these areas early on and tackle them head on.

Identify risks. The project might be an impossible one, or there might be risks. Hiding or ignoring the risks may prove fatal ultimately. The response should clearly lay out the risks from the beginning with a mitigation strategy. If you see an unreasonable request, it should be pointed out with a possibility of discussion on the topic.

Do not ignore the competition. Its not very hard to guess the competition. The response exercises should include a phase on researching the competition. What are they likely to respond with? What are their core competencies? Can you show in your response, how you are better than your competition?

Do not compete on price alone. Chances are there is some way estimations are done in your organization. Even if you rely completely on developer input based on experience, spend some time on it. Any estimation effort that is only a couple of hours is likely off the target. However, revisiting the estimate and applying couple of different models is a good practice. I saw hours spent in debates over the final price, but I did not see any effort to revisit the estimations. Do this work early on, so later if the top bosses are not happy with your final quote, you can show multiple estimation models to support your numbers.

Keep the last day for formatting and cosmetic fixes only. Editing the response till the last day can prove disastrous. In our case, we forgot to update the table of contents of the final document. It is easy to get carried away with content, and at the last moment, the overall look of the document will suffer. Avoid finishing the content on the last day.

Keep the document interesting and brief. Actual humans are going to read your response. Not only that, they are also going to read many such similar responses. Keep the response succinct. This is a not a writing competition. Neither the party with most words is going to win the bid. If you can demonstrate early on that what you have to say can be easily understood by the requester, you are half way there already.

Figure out the request theme. Early on, before you dive deep into the response, spend some time figuring out some key themes that emerge from the RFP. Write the themes on a whiteboard, discuss them with the team and make sure the response addresses the pertinent themes all the way.

Review, review, review. Chances are by the end, all involved parties in the response creation are suffering from document fatigue. At this point, you need fresh eyes to correct, update and enhance the content. You will need more than one person to review and comment on the document.

Do not overwork the team. If the time to respond is short, the requester probably does not want you to create a weighty door stopper. Keep it short. This will also allow the team to do quality work and not just quantity work. If everyone works around the clock to come up with material, chances are they are not reviewing each other’s work and mistakes are slipping by. The work you demonstrate in the response is the first clue to the requester about the eventual quality of the software you are promising to deliver. Also, to the team it is an indication of how the actual project might be run. Don’t scare them from the get go. Keep the load reasonable and quality high.

In summary, it takes cool heads who can keep the zeal to create reams of document under control, to produce a sharp looking response to a RFP. The best practices you demonstrate while responding are only an indicator of how the actual project will be done. The objective is not just to win the bid with a stellar response, but be able to execute and deliver what is promised in the response. So remember, proposing the plan is the just the beginning of the battle. Keep an eye on the final goal of how the project will be delivered and the response will speak for itself.