Phase Dadvanced

Module 14: Your First Proposal

Proposal structure, compliance matrix, writing to evaluation criteria.

Video

Module 14: Your First Proposal

Full video lesson coming soon. Sign up to be notified.

Lessons (4)

1

Proposal structure: technical, management, past performance, cost

A government proposal is a structured response to a solicitation. Unlike a commercial sales pitch, it follows a rigid format specified in Section L (Instructions to Offerors). Deviating from the format is the fastest way to get eliminated.

Most RFPs require four volumes:

Volume I: Technical Approach. This is where you describe HOW you will perform the work. Not what you know. Not who you are. How you will execute the specific requirements in the Statement of Work (SOW) or Performance Work Statement (PWS).

Structure your technical approach to mirror the SOW. If the SOW has five sections, your technical volume should have five corresponding sections. Evaluators use the SOW as their scoring guide. Make it easy for them to find your response to each requirement.

For each SOW requirement, follow this pattern: State your understanding of the requirement (one sentence). Describe your approach to fulfilling it (one to three paragraphs). Explain why your approach reduces risk or adds value (one paragraph). Reference a specific example from past work where you used this approach (one paragraph).

Volume II: Management Approach. This describes your project management methodology, team structure, quality control processes, and risk management approach.

For a solo contractor, this volume covers: Your project management process (how you track milestones, report progress, manage scope changes). Your quality control process (how you verify deliverable quality before submission). Key personnel qualifications (your resume, relevant certifications, education). Staffing plan (how you handle workload spikes, whether you use subcontractors for surge capacity). Risk mitigation (what could go wrong on this contract and how you prevent or handle it).

Volume III: Past Performance. Provide references for similar work you have performed. Each reference should include: Contract/project name and number. Client organization and point of contact (name, phone, email). Dollar value and period of performance. Description of work performed. Relevance to the current solicitation.

If you have no federal past performance, use commercial references for similar work. FAR 15.305(a)(2) states that a lack of past performance history "shall not be evaluated favorably or unfavorably." New contractors receive a neutral rating, which is better than a bad rating but worse than a good one.

Volume IV: Cost/Price Proposal. Your pricing for the work. The format depends on the contract type: Firm-fixed-price: a total price for the deliverables, sometimes broken down by CLIN (Contract Line Item Number). Time-and-materials: hourly rates by labor category and estimated materials costs. Cost-reimbursement: detailed cost breakdown (direct labor by category, indirect rates, materials, travel, ODCs, fee/profit).

Module 11 covered pricing strategy. In this volume, you present those numbers in the format Section L specifies.

2

Building a compliance matrix from the solicitation

A compliance matrix is the document that proves you read and responded to every requirement in the solicitation. Evaluators use it to verify completeness. A proposal missing a compliance matrix, or with a matrix that has gaps, signals that you did not read the solicitation carefully.

How to build a compliance matrix:

Step 1: Extract every requirement from the solicitation. Requirements appear in three places:

Section C (Statement of Work / Performance Work Statement): the work requirements. Every "shall" statement is a requirement.

Section L (Instructions to Offerors): the format and content requirements for your proposal. Every instruction about what to include is a requirement.

Section M (Evaluation Criteria): the scoring criteria. While not requirements per se, each evaluation factor implies content your proposal must address.

Step 2: Create a spreadsheet with these columns:

Column A: Requirement source (e.g., SOW 3.2.1, Section L paragraph 4.a, Section M Factor 1) Column B: Requirement text (verbatim from the solicitation) Column C: Proposal section where you address it (e.g., Technical Volume, Section 3.2) Column D: Compliance status (Compliant, Exception, Not Applicable) Column E: Notes (any clarifications or assumptions)

Step 3: Map every requirement to a proposal section. If a requirement does not have a corresponding proposal section, you have a gap. Either add a section or explain why the requirement is not applicable.

Step 4: Verify compliance status for each row. "Compliant" means your proposal directly addresses the requirement. "Exception" means you are proposing an alternative approach (explain why). "Not Applicable" means the requirement does not apply to your offer (explain why).

Using ClariFAR Clause Helper:

Paste the Section I clause list into the Clause Helper at /clause-helper. It identifies each clause and flags the ones that require a specific response in your proposal. Add these clause-driven requirements to your compliance matrix alongside the SOW requirements.

Common compliance matrix mistakes:

Missing "shall" statements: if the SOW says "the contractor shall submit monthly progress reports," that is a requirement. Your compliance matrix must show where your proposal commits to monthly progress reports.

Vague compliance claims: "Compliant" without explanation is weak. "Compliant: we will submit monthly progress reports by the 5th business day of each month, using the format in Attachment J-3" is strong.

Ignoring Section L format requirements: if Section L says "Volume I shall not exceed 30 pages, single-spaced, 12-point Times New Roman," that is a compliance requirement. Exceeding the page limit can result in page truncation or disqualification.

The compliance matrix is your insurance policy against evaluation gaps. An evaluator who cannot find your response to a requirement will score you down. The matrix ensures nothing is missed.

3

Writing to evaluation criteria

Section M tells you exactly how your proposal will be scored. Every word you write should earn you points under Section M. If a sentence in your proposal does not correspond to an evaluation factor, it is wasting page space.

How to map your writing to Section M:

Step 1: List every evaluation factor and subfactor from Section M. Example:

Factor 1: Technical Approach (Most Important) Subfactor 1a: Understanding of requirements Subfactor 1b: Technical methodology Subfactor 1c: Innovation and risk reduction

Factor 2: Past Performance (Important) Subfactor 2a: Relevance of past work Subfactor 2b: Quality of performance

Factor 3: Cost/Price (Less Important than Technical and Past Performance)

Step 2: For each subfactor, write content that directly addresses it. Do not hope the evaluator infers your compliance. State it explicitly.

Bad: "We have extensive cybersecurity experience." Good: "In 2025, we completed a NIST SP 800-171 compliance assessment for [Client], a DoD contractor with 45 employees and 3 active CUI-handling systems. We identified 23 control gaps, developed remediation plans for each, and achieved full compliance within 4 months. This experience directly demonstrates our understanding of the cybersecurity assessment methodology required under SOW Section 3.2."

The good version names the client, quantifies the work, specifies the methodology, and maps back to the SOW section. An evaluator can easily award points.

Writing techniques that score well:

Lead with your approach, not your qualifications. Evaluators want to know what you will do, then why you are qualified to do it. "We will conduct weekly vulnerability scans using [tool], with findings triaged by severity within 24 hours" is stronger than "Our team has 15 years of vulnerability management experience."

Use the solicitation's language. If the SOW says "enterprise cybersecurity architecture," use that exact phrase in your proposal. Evaluators scan for key terms. Paraphrasing into "IT security design" makes them work harder to match your response to the requirement.

Quantify everything. "Improved performance" is vague. "Reduced mean time to detection from 72 hours to 4 hours" is specific and scorable.

Address risk explicitly. Every technical approach has risks. Name them and describe your mitigation. "Risk: vendor patch delays may extend the remediation timeline. Mitigation: we maintain a 2-week buffer in our remediation schedule and have pre-negotiated SLAs with our top 3 vendors for expedited patching."

Discriminate yourself from competitors. Evaluators read 5-20 proposals. What makes yours different? Your proprietary tool, your unique methodology, your specific past performance on an identical system. State it clearly: "Unlike approaches that rely on manual checklist audits, our automated compliance scanner evaluates all 110 NIST SP 800-171 controls in under 60 minutes, with cited regulatory references for each finding."

4

Common mistakes that get proposals eliminated

Government proposals are eliminated for preventable reasons more often than they lose on merit. Here are the mistakes that kill proposals before evaluators finish reading them.

Mistake 1: late submission. Government deadlines are absolute. If the solicitation says proposals are due at 2:00 PM Eastern on June 15, a proposal received at 2:01 PM is late. Late proposals are returned without evaluation. There is no grace period, no "the email server was slow" excuse. Submit at least 2 hours before the deadline. If submitting electronically, confirm receipt.

Mistake 2: exceeding page limits. If Section L says 30 pages maximum, page 31 and beyond are either removed or the proposal is rejected. Use your page budget strategically. Do not waste 3 pages on company history that no evaluation factor asks about.

Mistake 3: wrong format. If Section L says "12-point Times New Roman, single-spaced, 1-inch margins," follow it exactly. Using 11-point font to fit more content is immediately noticeable and may result in rejection. Evaluators deal with enough proposals that format violations stand out.

Mistake 4: not answering the question. If Section M asks for "demonstrated understanding of challenges in migrating legacy DoD systems to cloud infrastructure," and your proposal talks about your general cloud migration methodology without referencing DoD-specific challenges (ATO requirements, IL4/IL5 classification, DISA STIG compliance), you did not answer the question. You answered a similar question. Evaluators score what you wrote, not what you meant.

Mistake 5: unsubstantiated claims. "We are the best cybersecurity firm in the region." Says who? Unsubstantiated superlatives annoy evaluators. Replace with evidence: "We have completed 14 NIST SP 800-171 assessments for DoD contractors in the last 18 months, with an average client SPRS score improvement of 47 points."

Mistake 6: copy-paste from previous proposals. Evaluators can tell. References to the wrong agency, wrong contract name, or wrong SOW section are instant credibility killers. Every proposal must be tailored to the specific solicitation. Boilerplate is fine as a starting draft, but the final product must address this solicitation's specific requirements.

Mistake 7: missing mandatory elements. If Section L requires a "Key Personnel Resume" and you do not include one, your proposal is non-responsive. Use your compliance matrix (Lesson 2) to catch these gaps. Check off every Section L requirement before submitting.

Mistake 8: pricing errors. Mathematical errors in your cost volume are taken seriously. If your labor rates do not multiply correctly, or your total does not match the sum of your CLINs, the contracting officer must request clarification. At best, this delays evaluation. At worst, it raises concerns about your attention to detail on a contract where attention to detail is the entire job.

Mistake 9: no connection between volumes. Your technical approach promises a "senior cybersecurity engineer" but your cost volume does not include that labor category. Your past performance references describe network administration but your technical approach is about software development. Evaluators read all volumes. Inconsistencies between them are red flags.

Mistake 10: ignoring the debrief. When you lose (and you will lose), request a debrief. FAR 15.506 gives you the right to a post-award debrief within 3 days of notification. The debrief tells you exactly why you lost and what your proposal scored on each factor. This is the most valuable feedback you will ever receive. Apply it to your next proposal.

Your first proposal will not be perfect. The goal is to submit a compliant, responsive, competitive proposal. Each subsequent proposal gets better as you learn the process and build your library of past work.