A Guide to Writing a Technical Approach

Let's set the scene. You’ve just come on to a new proposal effort and are anxiously awaiting your writing assignment.

When it finally hits your inbox, fear rises as you discover that you have been assigned the Technical Approach and have no technical expertise. Do not panic! We’ve got your back! Keep reading for some proven do’s and don'ts to help you write a winning Technical Approach.

What the Technical Approach should be

The Technical Approach should meet the customer’s technical requirements, clearly show your methodologies and solutions for doing this work, and include impactful proof points to validate your claims and reinforce your success. While responding to the technical requirements of the RFP is critical, ensuring that the other sections of the proposal, such as Program Management, Staffing, Transition, and Pricing support the Technical Approach provides a truly powerful, compelling case to the customer.

The government will evaluate the degree to which your proposal submission presents a clear understanding of the work statement in the request. Remember, proposals are scored, not read. It is important to note that the RFP usually specifies the relative weightings of the Technical, Management, Transition, Price, and other sections.

Oftentimes, we see general information used to address a project’s Technical Approach section. This approach is a big mistake that will cost you dearly at scoring. A comprehensive, clear Technical Approach is essential to your proposal's success, but often, the development of the Technical Approach lags the rest of the proposal.

Because of space constraints, a lack of time and understanding, or poor planning, offerors often fill the Technical Approach section of a proposal response with reuse or boilerplate material instead of a customized, scope-specific solution. Such shortcuts result in a missed opportunity to highlight and weave in key win themes and discriminators of your proposed work plan.

The goal of a Technical Approach document is twofold:

• To demonstrate that your solution is fully compliant.
• To supply a solution that is compelling in meeting the customer’s requirements better and as a better value than any alternative.

Writers should remember that the focus of a Technical Approach should be on how the customer will benefit from what you offer. Evaluators should walk away understanding why your proposal is their obvious best option. The section should demonstrate your understanding of the requirements and the approach to satisfying them.

There are many ways to approach writing technical sections. The KSI Advantage™ process recommends the following steps:

1. Describe the Technical Challenge(s). What is the problem in need of a solution? What are the risks? What are the consequences of failure to fix the problem? Demonstrate you understand the scope and complexity of the problem. Describe the as-is state and why it is not optimal or could be improved.
2. List Your Assumptions. What reasonable, necessary, or desirable assumptions must be made to support the plan?
3. Describe Your Plan or Solution. How do you solve the technical challenge(s)? Provide the:
   1. Who: Organization or key personnel, responsibilities, and authorities, labor categories, skill mix
   2. What: System, technology, process, procedure, policy, steps, activities
   3. When: Timeframe, schedule, milestones, dates, phases
   4. Where: Location(s) where the work will be performed
   5. Why: Rationale for why your solution will work
   6. How: Methods to measure your solution’s effectiveness, including metrics, performance measures, success criteria, and relevant benchmarks; identify potential risks of your plan, and eliminate or mitigate them
      
      
4. Provide Your Experience. Provide your relevant experience and past performance that demonstrates the credibility and effectiveness of your approach. Include examples of past performance handling contracts of similar scale, scope, and complexity. Provide metrics of your success where appropriate.
5. Articulate the Customer Benefits. How will your customer benefit from your understanding, plan, and relevant experience? Be specific. Think improved safety, enhanced quality, improved performance, reduced costs, accelerated schedule, reduced risk, and increased customer or stakeholder satisfaction.
6. Define the Vision for the End State. Assume your solution was successfully implemented. What is the end state? What would it look like? Describe how activities would be carried out safer, better, faster, and cheaper.
7. Support with Graphics. Technical processes are difficult to describe in words. Include supporting graphics, such as process flows, charts, milestone schedules, matrices, risk registers, schematics, pictures, customer testimonials, snapshots of awards or commendations, feature/benefit charts, organizational charts, or related visuals. Below is an example of Feature and Benefits Table that applies to a technical section.

Helpful tips when developing the Technical Approach

• Read it ALL: Make sure you read the entire solicitation carefully and understand all the requirements while identifying anything that is not clear and needs clarification by the Government or that will require a corporate decision on how to respond. If the specifications are unclear or contradictory, consider submitting a Request for Information (RFI) to ensure you have all the information for a clear understanding.
• Follow the RFP and Evaluate the Rating Scheme: Use the order of the RFP to develop your outline and systematically address all submission and evaluation criteria. Make sure you understand the implications of the rating scale.
• Remain Customer Focused: This entire process is about them, not you. Emphasize why they should pick your proposal over every other submission by showing how your approach will benefit them.
• Include a Corporate Blue Team Review: A corporate review of the proposed technical solution ensures the right questions are asked early in the development process and avoids lagging or misalignment with the Management, Pricing, and Transition sections.
• Work with Subject-Matter Expert(s) (SMEs): Before you can write to a solution, you must understand it. SMEs hold the keys to that understanding. Engage a SME to ensure a thorough approach is provided for critical scope areas. Expert knowledge will go a long way in showing your understanding of the project.
• Include Opportunity-Specific Details: Do not just restate the SOW/PWS. The Technical Approach is your opportunity to provide details! Stand out from the competition by demonstrating your understanding of the project through a work breakdown structure or thoughtful sequencing information.
• Connect to the Schedule: If a schedule is required, make sure the narrative matches, and ensure the Technical Approach is reflected in the Transition Plan. Check for consistency across key elements such as start dates, dates for full operation, total contract duration, etc.
• Ensure the Staffing Plan Includes Required or Key Personnel: You can’t do the work if you don’t have the staff. Make sure technical staff are in place to execute the technical work and that all necessary staff have been considered in the overall Staffing Plan of the proposal. Be sure staff covers all the positions, skills, and qualifications the client specifies.
• Identify Risks and Mitigation Plans: Every project has its challenges as well as its opportunities. Make sure to identify any major technical risks and provide a brief description of your mitigation strategy. 
• Ensure Compliance: Review your content and make sure that your proposal appropriately addresses all of the RFP specifications, is formatted as requested, and includes all of the required forms for a fully compliant response.
• Be Consistent: Make sure you have double and triple-checked your grammar, titles, acronyms, key personnel, meeting names, format, etc. for consistency throughout the entire proposal.
• Simulate a Review: Mimic a source-selection committee by having a separate person or group that is not involved in the preparation of the approach to review your proposal. As every writer knows, a fresh pair of eyes can see things we cannot. They may be able to identify a deficiency that needs additional language to get the point across.
• Make Sure the Management Approach Supports the Execution of the Technical Approach: Demonstrate the Management Approach you have designed to successfully execute your Technical Approach. Develop a high-level Program Management Plan and drill down to specific tasks, timelines, and deliverables. It must be clear to the evaluator that you have the appropriate personnel, oversight, and expertise needed to drive your Technical Approach.

Things to avoid

Now that we have spent significant time telling you what to do, here are some key “not to do’s.”

• Don’t ignore the SOW/PWS and technical requirements.
• Don’t wait to engage your technical SMEs.
• Don’t skimp on the details that give your proposal strength and proof points.
• Don’t forget that you need an appropriate Staffing Plan to do the work.
• Don’t price yourself so high that it does not match the weight of your Technical Approach.
• Don’t fill your Technical Approach with fluffy, non-specific language.

Conclusion

If you are assigned the Technical Approach section of a proposal, do not fret! Remember it is crucial to present a fact-based approach that demonstrates a clear, tangible value to the customer.

Your response should illustrate how you will approach the project and meet the requirements in the solicitation while remaining customer-focused and integrating illustrative proof points throughout. Make sure you show them your value-add through metrics and thoughtful graphics. And don’t forget, proposals are scored, not read, so review your work like an evaluator would.