Published on Mon Aug 24 2026 00:00:00 GMT+0000 (Coordinated Universal Time) by Jacob Cavazos

The Technical Approach section is the most heavily weighted component of a federal proposal. In most solicitations, it accounts for 40 to 60 percent of the total technical evaluation score. It is Volume I, the first volume evaluators read, and it is the volume where most proposals are won or lost.

A technical approach is not a description of your company. It is not a restatement of your past performance. It is not a list of your certifications. A technical approach is a specific, structured argument that you understand the government’s problem and have a credible, low-risk method for solving it. Every paragraph should advance that argument. Every section should trace to a requirement in the RFP. Every claim should be backed by evidence.

Most contractors get this wrong. They write technical approaches that are vague, unstructured, and untraceable. They describe their capabilities instead of the government’s mission. They use boilerplate copied from previous proposals. They omit graphics. They miss requirements. Then they lose, and they do not understand why.

This post describes how to write a technical approach that wins. It covers what the section is, how evaluators score it, the structure that produces consistent results, and how to use deterministic requirement extraction to ensure the section is both compliant and compelling.

What the Technical Approach Section Is

The Technical Approach section is Volume I of a federal proposal. It is defined by Section L (Instructions to Offerors) of the RFP, which specifies the content, format, and page limits. Section M (Evaluation Factors) defines how it will be scored.

The technical approach answers one question: how will you perform the work described in Section C (Statement of Work) or Section P (Performance Work Statement)? The answer must be specific enough that an evaluator can determine whether your approach will work, detailed enough to demonstrate understanding, and structured enough that every requirement in the SOW is addressed.

A typical technical approach for a mid-size federal contract (5-year, $50-200 million) runs 30 to 60 pages. For larger contracts, it can run 100 pages or more. The page limit is enforced — proposals that exceed it are eliminated or penalized. Writing a technical approach is an exercise in density: you must pack maximum relevant content into a fixed space, with no filler.

The technical approach is distinct from the Management Approach (Volume II), which covers contract organization, staffing, and processes. It is distinct from Past Performance (Volume III), which covers your record on similar contracts. It is distinct from Price (Volume IV). The technical approach focuses on the work itself: the technical solution, the methodology, the risk mitigation, and the innovation.

How Evaluators Score the Technical Approach

Federal proposal evaluation is governed by Section M of the RFP. Section M defines the evaluation factors, their relative weights, and the scoring methodology. Evaluators do not score proposals holistically. They score them against defined criteria, using a structured rubric.

The evaluation process works as follows. Each evaluator receives the proposals and a scoring sheet listing each evaluation factor and sub-factor from Section M, with space for a score and a narrative justification. The evaluator reads the proposal, assigns a score to each factor, and writes a justification. The scores are then aggregated across evaluators and factors to produce a final ranking.

Scoring is typically color-coded or adjectival:

• Blue / Exceptional — the proposal exceeds requirements in a way that benefits the government.
• Green / Acceptable — the proposal meets requirements. No significant weaknesses.
• Yellow / Marginal — the proposal has weaknesses that may require correction.
• Red / Unacceptable — the proposal fails to meet requirements and cannot be selected.

A proposal must score Green or above on every factor to be eligible for award. A single Red on any factor means elimination. This is why compliance is non-negotiable: a technically brilliant proposal that misses a single mandatory requirement receives a Red on compliance and is eliminated.

Evaluators assess two dimensions: compliance and quality. Compliance means the proposal addresses every requirement in the RFP. Quality means the proposal demonstrates understanding, presents a credible approach, manages risk, and offers innovation where appropriate. A compliant but generic approach scores Green. A compliant, specific, well-structured approach with clear traceability scores Blue.

The evaluators are not your peers. They are government technical personnel, often the program managers who will oversee the contract. They read dozens of proposals and are looking for reasons to eliminate them so they can focus on a shortlist. Vague language, missing requirements, and lack of traceability give them those reasons.

The Five-Part Structure

A technical approach that wins follows a consistent structure. The structure is not arbitrary — it maps to how evaluators think and how Section M factors are defined. The five parts are Understanding, Approach, Methodology, Risk Management, and Innovation.

Part 1: Understanding

The Understanding section demonstrates that you comprehend the government’s problem. This is not a restatement of the SOW. The government wrote the SOW — they know what it says. The Understanding section should demonstrate that you understand the context behind the SOW: the mission the contract supports, the constraints the government faces, the stakeholders involved, and the challenges that will arise during execution.

A strong Understanding section identifies the three to five most difficult aspects of the work and explains why they are difficult. This signals to evaluators that you have thought about the problem. A weak Understanding section paraphrases the SOW and adds nothing.

The Understanding section should be 2 to 4 pages. It should be specific: name the systems, name the stakeholders, name the constraints. If the contract involves migrating a legacy system, identify the system, its dependencies, and the migration challenges. If the contract involves cybersecurity, identify the threat landscape, the compliance framework, and the specific controls that are hardest to implement.

Part 2: Approach

The Approach section describes your solution at a high level. It is the architectural overview: what you will build, what you will deploy, what services you will provide, and how they fit together. The Approach section should be accompanied by a graphic — a system architecture diagram, a process flow, or a service model. Proposals with graphics score higher than proposals without them. A clear architecture diagram communicates understanding more effectively than three pages of prose.

The Approach section should trace directly to the SOW requirements. Every major work element in the SOW should have a corresponding element in your approach. If the SOW has five task areas, your approach should address all five. If the SOW specifies performance standards, your approach should describe how you will meet them.

This is where the compliance matrix becomes essential. Every requirement in the compliance matrix that falls under the technical approach evaluation factor should be addressed in this section or in the Methodology section that follows. For a detailed treatment of how the compliance matrix drives this mapping, see RFC compliance matrix automation.

Part 3: Methodology

The Methodology section describes how you will execute the approach. Where the Approach section says what you will do, the Methodology section says how you will do it. This includes processes, procedures, tools, staffing models, and quality assurance methods.

The Methodology section should be specific enough to be verifiable. “We will use agile development methodologies” is not a methodology. “We will conduct two-week sprints with daily standups, sprint planning, sprint review, and sprint retrospective, using Jira for backlog management and Confluence for documentation” is a methodology. The first is boilerplate. The second is a process an evaluator can assess.

The Methodology section should also describe how you will measure performance. If the SOW includes service level agreements, describe how you will track, report, and remediate SLA performance. If the contract includes quality assurance requirements, describe your QA process, metrics, and reporting cadence.

Part 4: Risk Management

The Risk Management section identifies the risks associated with the work and describes how you will mitigate them. This section is where many proposals lose points. Evaluators want to see that you have thought about what could go wrong and have a plan for it.

A strong Risk Management section identifies 5 to 10 specific risks, assesses each for probability and impact, and describes a mitigation strategy for each. The risks should be specific to this contract, not generic. “Key personnel may leave” is a generic risk. “The lead systems engineer position may be difficult to fill due to competition with three concurrent DoD programs in the same geographic area” is a specific risk. Specific risks demonstrate understanding. Generic risks demonstrate that you have a risk management template.

Each risk should include a probability assessment (Low, Medium, High), an impact assessment (Low, Medium, High), and a concrete mitigation strategy. “We will mitigate this risk through careful planning” is not a mitigation strategy. “We will mitigate the key personnel risk by identifying two qualified candidates for each key position prior to contract award, offering retention bonuses tied to contract longevity, and cross-training senior staff across task areas” is a mitigation strategy.

Part 5: Innovation

The Innovation section describes improvements you will bring to the contract that go beyond the minimum requirements. Not every RFP asks for innovation, but many include an evaluation factor for it. Even when it is not a formal factor, demonstrating innovation can move a proposal from Green to Blue.

Innovation should be relevant. An innovation that reduces cost, improves schedule, enhances performance, or reduces risk for the government is valuable. An innovation that is impressive but irrelevant to the contract is filler. “We will use machine learning to optimize resource allocation across task areas, reducing labor hours by an estimated 15 percent” is a relevant innovation if the contract involves resource-intensive operations. “We have a patent pending on a new blockchain architecture” is irrelevant unless the contract involves blockchain.

The Innovation section should be 2 to 4 pages. It should propose 2 to 4 specific innovations, each with a description, a quantified benefit statement, and an implementation plan: “reduces response time by 30 percent,” “eliminates 200 labor hours per month,” “improves first-call resolution rate by 15 percent.”

Using the Compliance Matrix to Structure the Technical Approach

The compliance matrix is not just a checklist. It is the structural backbone of the technical approach. Every critical requirement in the matrix should map to a specific subsection of the technical approach. This ensures two things: that every requirement is addressed, and that an evaluator can trace each requirement to its response.

The mapping works as follows. After the compliance matrix is built — using deterministic extraction to ensure every “shall” requirement is captured — the requirements assigned to the Technical Approach evaluation factor are sorted by category and priority. Critical requirements (those with specific timelines, security obligations, or penalty clauses) each get a dedicated subsection. Important requirements are grouped by topic. Standard requirements are addressed in the Methodology section.

This structure produces a technical approach that is inherently traceable. An evaluator looking for the response to requirement R-127 can find it directly, because the compliance matrix says “R-127 is addressed in Section 3.4.2.” A proposal without this traceability forces the evaluator to hunt for the response, and an evaluator who cannot find a response assumes it is missing.

For a real example, consider the House of Representatives IT Services solicitation (OAM20047S). The deterministic extractor found 223 requirements mapped to the Technical Approach evaluation factor, of which 66 were critical. A technical approach structured around these requirements would have 66 dedicated subsections for critical requirements, plus topic-level subsections for the remaining 157. Every requirement is addressed. Every response is traceable. The evaluator’s job is easy, and easy evaluation produces higher scores.

Threading Win Themes Through the Technical Approach

A win theme is a discriminator — a specific capability, approach, or advantage that differentiates your proposal from competitors. Win themes are not marketing slogans. They are substantive arguments backed by evidence. “We are the best” is not a win theme. “We have performed this exact work for three similar House of Representatives programs and can deploy a proven solution in 30 days instead of 90” is a win theme.

Win themes should be threaded through the technical approach, not confined to a single section. A win theme that appears in the Understanding section, is demonstrated in the Approach section, is operationalized in the Methodology section, and is reinforced in the Innovation section is more persuasive than a win theme stated once. Threading creates coherence. It tells the evaluator: this is not a claim, it is a pattern.

The process of identifying and threading win themes is closely related to ghosting — the practice of identifying your competitors’ weaknesses and structuring your proposal to highlight them without naming competitors. For a detailed treatment of how to identify discriminators and thread them through a proposal, see our analysis of proposal ghosting and discriminator analysis.

The key principle is that win themes must be specific and evidence-backed. A win theme that is vague (“we offer superior technical capabilities”) is not a discriminator. A win theme that is specific and verifiable (“our automated monitoring platform reduces mean time to detection from 45 minutes to 3 minutes, as demonstrated on the DHS CDM program”) is a discriminator. The competitor cannot match it without the same evidence.

Common Mistakes That Sink Technical Approaches

Most technical approaches that lose share a small number of failure modes. Avoiding these does not guarantee a win, but it eliminates the most common reasons for loss.

Vague language. “We will provide high-quality services” is vague. “We will provide 24/7 network monitoring with a 15-minute response time for severity 1 incidents, staffed by CCNA-certified engineers, using a SIEM platform that correlates events across 12 data sources” is specific. Vague language signals that the contractor does not understand the work. Specific language signals understanding and credibility. Every sentence should pass the specificity test: could a competitor say the same thing? If yes, the sentence is not a discriminator and should be made more specific.

Missing requirements. A technical approach that does not address a requirement in the compliance matrix is non-compliant. This is the most common cause of elimination. The fix is deterministic: use the compliance matrix as the structural backbone, ensure every requirement maps to a subsection, and verify that every subsection addresses its requirement. For the extraction process that ensures no requirement is missed, see deterministic RFP requirement extraction.

No traceability. A technical approach that addresses requirements but does not trace them is compliant but hard to evaluate. The evaluator cannot find the response to a specific requirement and may score it as missing. The fix is a traceability matrix mapping each requirement to its response location in the proposal, included as an appendix or cross-referenced in the compliance matrix.

Copy-paste boilerplate. Reusing text from previous proposals is common and not inherently wrong. But boilerplate that is not tailored to the specific RFP is obvious to evaluators. It references the wrong agency, the wrong contract, the wrong systems. Every reused paragraph should be reviewed and tailored. If a paragraph does not reference something specific to this RFP — a requirement number, a system name, a performance standard — it is probably boilerplate and should be rewritten.

No graphics. Proposals without graphics score lower than proposals with graphics. This is consistent across evaluation studies. Graphics communicate structure, process, and architecture more efficiently than text. A technical approach should include at least one graphic per major section: an architecture diagram in the Approach section, a process flow in the Methodology section, a risk matrix in the Risk Management section. Graphics should be original, referenced in the text, and explained in captions.

How Deterministic Extraction Ensures a Compliant Technical Approach

The technical approach is only as good as the requirements it addresses. If the compliance matrix is missing requirements, the technical approach is missing responses, and the proposal is non-compliant regardless of writing quality.

Deterministic requirement extraction ensures that every “shall” in the RFP is captured. Every requirement is categorized, prioritized, and mapped to an evaluation factor. The requirements mapped to Technical Approach become the structural backbone of the section. The proposal team writes responses against a verified, complete list — not against the requirements they happened to remember.

This matters because human review is unreliable. A proposal manager who reads an 80-page RFP and builds a compliance matrix manually will miss 5 to 15 percent of the requirements. On a 223-requirement RFP, that is 11 to 33 missed requirements. Each missed requirement is a potential elimination. Deterministic extraction finds all 223, every time, in under 10 seconds. The categorization is deterministic, so the structure is consistent across proposals and across proposal teams.

For contractors who want to understand the full pipeline — from RFP ingestion through requirement extraction, compliance matrix construction, FAR clause verification, and proposal generation — our rating of govcon AI proposal tools compares how eight tools handle each stage. The tools that use deterministic extraction for compliance and LLMs only for generation produce the most reliable results.

The Writing Process

The process for writing a winning technical approach follows a specific sequence. First, extract requirements deterministically and build the compliance matrix. Second, structure the section around the five-part framework, assigning critical requirements to dedicated subsections. Third, identify 3 to 5 win themes through discriminator analysis and plan how to thread each through multiple sections. Fourth, draft each section in order — Understanding, Approach, Methodology, Risk Management, Innovation — ensuring every paragraph is specific and every claim is evidence-backed. Fifth, verify compliance by checking that every requirement in the matrix is addressed and traceable. Sixth, review for specificity: read every paragraph and ask whether a competitor could say the same thing. If yes, rewrite.

This sequence produces a technical approach that is compliant, specific, well-structured, and traceable. The tools change — deterministic extraction replaces manual highlighting, LLMs assist with drafting — but the sequence does not.

Frequently Asked Questions

What is a technical approach section?

The technical approach section is Volume I of a federal proposal. It describes how the contractor will perform the work defined in the Statement of Work. It is governed by Section L (Instructions to Offerors) and scored under Section M (Evaluation Factors). In most solicitations, it carries 40 to 60 percent of the total technical evaluation weight. A technical approach must demonstrate understanding of the government’s problem, present a credible solution, address every applicable requirement, and manage risk.

How long should a technical approach be?

The length is determined by Section L of the RFP, which specifies page limits. A typical technical approach for a mid-size federal contract runs 30 to 60 pages. For larger contracts, it can run 100 pages or more. Page limits are enforced — proposals that exceed them are eliminated or penalized. The goal is not length but density: every page should contain specific, relevant, traceable content. Filler pages reduce the space available for substantive content.

How do evaluators score the technical approach?

Evaluators score the technical approach against the evaluation factors defined in Section M of the RFP. Each factor is scored on a color-coded or adjectival scale: Blue (Exceptional), Green (Acceptable), Yellow (Marginal), or Red (Unacceptable). A proposal must score Green or above on every factor to be eligible for award. Evaluators assess two dimensions: compliance (does the proposal address every requirement) and quality (does the proposal demonstrate understanding, present a credible approach, manage risk, and offer innovation). A proposal that is compliant but generic scores Green. A proposal that is compliant, specific, well-structured, and traceable scores Blue.

What is win theme threading?

Win theme threading is the practice of identifying 3 to 5 discriminators — specific capabilities or advantages that differentiate your proposal — and weaving them through multiple sections of the technical approach. A win theme that appears in the Understanding section, is demonstrated in the Approach section, operationalized in the Methodology section, and reinforced in the Innovation section is more persuasive than a win theme stated once. Threading creates coherence and signals that the discriminator is a pattern, not a claim. Win themes must be specific and evidence-backed to function as discriminators.

How do I ensure my technical approach is compliant?

Compliance requires that every requirement in the RFP mapped to the Technical Approach evaluation factor is addressed in the proposal. The most reliable method is to use deterministic requirement extraction to build a complete compliance matrix, structure the technical approach around the matrix so that every critical requirement has a dedicated subsection, and verify that every subsection addresses its requirement. A traceability matrix mapping each requirement to its response location should be included as an appendix. This ensures that evaluators can find every response and that no requirement is missed.

Written by Jacob Cavazos