This section provides guidelines for writing the technical and management sections of a proposal.
Technical Approach Writing Guidelines
Your team’s technical approach to performing this project should be summarized in this section. It should satisfy the customer’s technical requirements, clearly demonstrate your approaches and methodologies for accomplishing this work, and include sufficient proofs to substantiate your claims.
The technical requirements are summarized in Section L and detailed in Section C of most Government RFPs. To begin planning your technical response, provide a high level view of the major technical requirements. This can be accomplished as a bulletized list, table, flow diagram or a work breakdown structure (WBS) diagram. Here is an example:
From this high level requirements listing, you can begin formulating your concept of operations (e.g., what people and skill sets will be required; what should the reporting structure look like; what level of oversight will be required; what gaps must be compensated for using subcontractors or consultants; what corporate experience do we possess that is similar, recent and relevant; what infrastructure will be required to manage, control, and correct this work effort; what deliverables are required and what systems will be required to produce them?). Where applicable, the technical approach should clearly identify and address all tasks and subtasks required to achieve the overall work, task, or mission objective. Use this information as a basis for preparing your project performance schedule, transition schedule and plan, staffing plan, cost estimate, and risk assessment/management plan.
A detailed work breakdown structure (WBS) and organization breakdown structure (OBS) with control account managers (CAMs) should be defined and documented to support the development of a detailed resource-loaded, logic-driven project schedule. Your WBS/OBS and designated CAMs should be defined consistent with the RFP requirements. If done properly, this information can be used to help management visualize the key tasks and deliverables and gain a better understanding of the opportunity and a better appreciation for the level of effort required for both the proposal and the project.
Here’s an example of the first step to building a WBS based on an information technology contract. This represents a primary task and sub-tasks broken down to the fourth level WBS (i.e., IT Support Services is WBS level 1.0, Operating Systems is 1.1, Applications is 1.1.1, and Windows is 18.104.22.168). You can break it down as far as you choose to ensure that you get sufficient detail on the activity to convey it in your proposal. However, for scheduling, monitoring, and cost capture purposes, it is often not prudent to go past the 3rd or 4th WBS level.
This can be applied to any type of work effort, for projects such as A/ECM, environmental remediation, nuclear reactor operation, software and hardware design projects, the WBS structure can become quite large and complex. Similar information should be gathered as it relates to more complex A&E, engineering and construction bids.
The technical section of the proposal needs to demonstrate both understanding of the requirement and approach to satisfy the requirement:
- Task objectives/importance
- Special requirements/interfaces/relationships
- Potential problems/issues and solutions
- Applicable regulations, directives, and laws
- Cite past performance examples that attest to your understanding
What? When? Who? Why? Where? How?
- What it is that you will do?
- When will you do it?
- Who will do it (i.e, the project manager, the business manager, or the mechanic)?
- Why must this activity be done?
- Where it will be done?
- How will it be done?
Focus on HOW
- Identify methods, procedures, processes, tools and techniques
- Show innovation for the future (How to perform Better, Faster or Cheaper going in and over time)
- Milestones and schedules
- Reporting and documentation requirements
- QA/QC and testing and calibration requirements
- Identify risks and discuss mitigation approach (solutions/benefits)
- Cite past performance examples (proof statements) – Use statistics when possible to substantiate approach
- Use graphic(s) as appropriate, but USE GRAPHICS
Avoid getting hung up trying to force glowing prose
- Think about what you want to say
- Write it down
- Rework and polish it
- Every requirement can’t be expressed as an earth shaking claim
- Keep it simple, positive, factual, confident and honest
Help the evaluator find your responses to the RFP criteria
- Reference the RFP section or evaluation criteria
- Outline your proposal to the instructions (Section L); add in any missing evaluation criteria (Section M), and weave in the other relevant pieces such as scope of work (typically Section C), special contract clauses (section H), and any associated amendments impacting the contents of your proposal
Most projects have some degree of infrastructure requirements that may or may not impact pricing. Describe the necessary labor categories and whether you are proposing current team employees, incumbent hires or new hires. Also:
- Are there any wage determination requirements to be considered (e.g., DBA or SCA wage rates)?
- What are the major technical labor categories?
- Will you use in-house people or subcontract to specialty or niche subcontractors possessing those skill sets? (Who, What Organization, What Location)
- Will you need to hire? (How Many & When Needed)
Identify the major technical risks and a brief description of your mitigation strategy. Be prepared to discuss/define your risk management methodology.
Substantiated technical themes and discriminators should be communicated to illustrate the strength of your team’s technical offering.
Management Approach Writing Guidelines
In best-value procurements, management capabilities and approach are often the two highest weighted evaluation criteria. The management approach is your company’s ability to plan, implement, control, sustain, measure and report on the required work.
An effective management approach should clearly communicate that the selected approach is relevant to the customer’s needs. The effectiveness of this approach should have been proven on programs similar to the requirements of this opportunity.
Data like the customer’s organizational and reporting structure as well as their major program management systems, tools and processes should inform your approach and shape how you will manage the project, communications, and work flow and coordination.
Most services procurements specify a certain number of key personnel or require you to identify who you believe the key personnel should be. It might also be one of the key evaluation criteria. Careful attention should be given to the identification of these individuals and making sure they have strong prior management experience on projects of similar size and scope. Additionally, if given the opportunity to name the key positions, do not over propose the number of positions. Keep in mind that key personnel are different than non-key; it requires customer approval and usually a minimum of a 30-day notice before you can expect the approval. Fewer key positions means more flexibility to the contractor.
Bidders are also required to prove their ability to staff the project. Your staffing strategy may be to hire the incumbent contractor’s staff or to staff a project with your own skilled employees from other projects. It can be quite helpful to involve someone from recruiting and human resources in the discussions for this factor.
In addition, make sure to:
- Illustrate your proposed program/project organization including key personnel and how it aligns with client organization (creates a visual of effective client interfaces)
- Use consistent flow diagrams
- Describe your methodologies
- Identify our tools
- Identify typical risks and how you plan to mitigate, manage, transfer, or avoid them
– Mike Lisagor & Melanie Baker