The Capture process is more than identifying a customer’s requirements and objectives in a Request for Proposal (RFP). Here are seven steps to help you develop your capture process.
1. Know the Customer
Ideally, your capture process starts prior to the release of the RFP. It should begin with understanding the customer’s needs, wants, likes/dislikes, and their procedures and business culture. Also, determine the key decision makers and their backgrounds. Knowing these details, no matter how small, can provide your team with that simple edge over your competitors.
For example, let’s say that a customer releases an RFP to develop a web application. The customer’s Senior VP distrusts software applications that use open-source and JAVA. But the RFP doesn’t say anything about open-source or JAVA; it only states functional requirements and leaves the technical specifications up to the RFP respondents. Knowing the Senior VP’s preference makes the difference between winning or losing the contract.
Customer details should always be shared with the entire proposal team and review teams.
2. Identify the Risks
Prior to responding to the RFP, identify risks embedded in the RFP. Risks can be contractual terms, timelines, capabilities, profitability, available resources, and others. Risks fall into different categories, and therefore your company will need to consult with various Subject Matter Experts (SMEs) such as attorneys, project managers, cost analysts, management, and others. Preferably, each of these SMEs should read the RFP in the Business Development phase, but typically there isn’t enough time for each of your SMEs to review the RFP and compile an analysis.
To expedite this process, collect keywords and terms from your SMEs that could classify content as a risk. These risk keywords/terms can be reused for analyses of future RFPs. This process is also rather helpful as part of your Bid/No Bid phase. Identifying risks early on helps your company manage and mitigate risks and control costs.
Knowing how and what to capture is key to winning contracts, managing risks, and controlling costs.
3. Identify Project Scope
A project scope is typically defined by a project’s goals, deliverables, tasks, costs, and deadlines. Note that a project scope is normally thought of as part of a project’s planning process. The RFP’s Statement of Work (SOW) describes the elements of scope. Identify scope elements and have your SMEs analyze the identified scope elements for the proposal and for the possible project plan. Your SMEs should assemble a collection of keywords/terms and phrases to quickly identify scope elements. Frequently this collection of scope keywords/terms and phrases can be used for other RFPs.
By identifying scope as part of the proposal development process, it provides your team with a better understanding of the customer’s requirements that may not be identified by the so-called required words, “shall”, “must”, and “will”. Therefore, scope reduces the risk of cost overruns and prevents proposal non-compliance.
4. Identify Requirements
When identifying requirements in an RFP/RFQ, most people search for specific words like “shall”, “must”, and “will” and optional words such as “can”, “may”, and “optional”. Limiting your search to these words alone may cause you to miss requirements. I recommend expanding your list of keywords, for example; “critical”, “duty”, “necessity”, “needed”, and others.
Using keywords is helpful to quickly identify most requirements and helps to prevent missing requirements. The more required keywords you have, the better you are at finding requirements. At times there are requirements that are not easily identified by common keywords. Therefore, keyword searches and identifications do not replace reading the RFP and understanding its content.
5. Identify Regulations
Typically Federal Government RFPs include notations to the Federal Acquisition Regulation (FAR). There may be other government regulations as well that you need to be aware of and identify in the RFP, such as Section 508 Compliance.
6. Identify Acronyms and Abbreviations
The Federal Government is notorious for using acronyms and abbreviations, and the same is true with most government RFPs. Identifying acronyms and abbreviations in the RFP prior to writing is important for a couple reasons. First, you want to know the definitions of all the acronyms and abbreviations so you can address the RFP. Second, you should use the same acronyms and abbreviations in your proposal where it is practical.
7. Identify Common Concepts/Terms
Identify the RFP’s fundamental concepts and terms. Your proposal text should be using the same concepts and terms that are in the RFP. If your proposal uses different concepts/terms than the RFP, there is an increasing probability that the customer’s proposal review board will believe your proposal does not address the requirements in the RFP. In other words, the customer’s proposal review board may think your proposal is non-compliant.
Comparing an RFP’s concepts and terms to a related proposal identifies concepts and terms not addressed or not addressed often enough in the draft proposal. It is good to know the common concepts and terms and share them with your writers and SMEs prior to writing the proposal. In addition, using the same lexicon as your customer will make it easier for the customer to understand the content of your proposal.
In short, “Capture” is simply slicing and dicing, categorizing, sorting, and formulating in an effort to clearly and fully address an RFP and comprehending what the customer wants. Knowing how and what to capture is key to winning contracts, managing risks, and controlling costs.
Capture Software Tools
Using an RFP shredder/parser software tool is a huge time saver in identifying requirements, risks, scope, and government regulations. There are a few RFP shredder/parser software tools on the market and they differ in capabilities and price. An RFP shredder/parser software tool should not replace reading an RFP and keywords alone should never be used to identify all requirements.
You will note, I used the term “tool”. A tool extends your capabilities and helps you save time, but does not replace you. My company Atebion LLC provides RFP shredder/parser software, acronym identification/validation, and concept analysis tools as well.