Proposal Lessons Learned

Ya gotta be lowest price to win...

Get your team together early, and get the proposal disseminated, in its entirety as quickly as possible. If you only receive it in hard copy get someone to start scanning and OCR'ing the document into softcopy. This will be a critical time saver later.

Go through the RFP and develop an understanding, visual and written, what the RFP is asking for. These images will be important to your gold/red team reviews later.

Identify your book bosses early and work with each to develop an understanding of the RFP implications for their individual books. In particular the technical volume, the team should be sized appropriately to support it. If it's a big technical challenge then chunk it down and find staff to handle the chunks.

Begin early with your leadership team. Walk through the proposal development game plan with them and build buyin for what has to happen, and when it has to happen. Develop this game plan into a speech, schpeel, brief, or whatever, but be prepared to communicate it repeatedly to the troops as they come on board to support. The surest way to confusion, frsutration, and lots of rework is to not communicate what the overall process will look like, and what is expected of the team members.

In this latest instance we did not have a game plan that was shared with the troops. Instead we had a couple three senior staff that had the experience and new what the general game plan would look like. They were augmented with other staff that new how to handle individual parts of the problem. But at no point was the entire team brought together and given a talk on how the whole the executed and would come together in a proposal document 8 weeks into the future. As a result a lot of muttering under breath, poor moral, and half hearted effort became the norm. The team never merged into the tight unit that it could have become.

As for process, here are some of the things that happened along the way:

Get the RFP copied and diseminated early. Have extra copies on hand for late comers.
Ask the readers to answer these questions while they're reading:
Do you understand what the customer is asking for in this section?
Do you have an idea of what the solution could be in this section?
Do we have experience within SAIC to deliver such a solution?
Can you parse the section into clear requirements and deliverables?

Readers should mark up their documents to highlight requirements and deliverables, making them very obvious. Each reader who will respond to the proposal must develop a good understanding of what their section requires and be prepared to discuss technical solution options at a soltuion development strategy session.

A requirements driven outline is a very good way to structure the propsal response. But in some instances the RFP does not lend itself well to such an approach. Two other approaches for organizing the proposal revolve around mapping to the CLIN outline (or cost outline) or mapping to the RFP's own outline of the problem (lifted straight from their document outline). I recommend using the latter to structure the proposal, and the top level of the WBS. But the former (CLIN) should be integrated into the WBS to assist in developing a cost role up that the customer wants to see.

Requirements analysis is critical. Bring in a requirements analyst who can parse the document and find all requirements statements. They should also identify all deliverables and mark them as such in the requirements traceability matrix. Requirements can take at least two forms, deliverables, or capabilities. Deliverables are concrete objects that are left behind with the customer, including events such as meetings. Capabilities are attributes of deliverables, such as speeds and availability, etc.

The output of requirements analysis becomes critical to ensure that you've developed a technical solution that meets all of the requirements of the RFP. Requirements must be mapped to the WBS to ensure that somewhere in the execution of the program each individual requirement will be addressed and satisfied. A cross walk analysis betwenn RTM and WBS ensures completeness and accuracy of both. More critically it establishes reality upon with the Bill of Materials and Basis of Estimates will be built.

RFP->Questions->RTM->Solution Outline->WBS->BOM->BOE->Cost
Solution Outline->Understanding of Requirement->Approach to Meeting Requirement
Understanding of Requirement -> Past Performance Examples