RFP Strategy
How to Write a Technical Approach for a Government RFP (AEC Guide)
A practical guide to writing the technical approach section of a government RFP — the highest-weighted evaluation criterion in most AEC solicitations, and the section where proposals most commonly lose winnable points.
Summary
The technical approach is where most AEC firms lose evaluation points they should win. Not because they can't do the work, but because they describe phases when evaluators are looking for evidence of project-specific judgment. Here's how to write one that scores.
The technical approach is the section of a government RFP that evaluators spend the most time reading, and the section that most AEC firms write least effectively. Not because they can't do the work. Because they describe methodology when evaluators are looking for evidence of judgment.
Short answer: A strong technical approach for a government RFP proves three things: you understand the specific risks and constraints this project presents, your plan addresses them in a way that fits this project's context, and your team has navigated comparable challenges before. Generic phase descriptions earn average scores. Project-specific insight earns high ones.
What is the technical approach and why does it matter so much?
The technical approach — sometimes called the technical methodology, work plan, or project approach — is the section that explains how your team will deliver the scope. It's distinct from your team qualifications and past performance sections, though the strongest responses tie all three together.
In most government RFPs for AEC professional services, the technical approach carries 30–50% of total evaluation points. It's the highest-weighted criterion in the majority of engineering, architecture, and construction management solicitations. It's also the section where the gap between top-scoring and average-scoring proposals is widest — and most of that gap comes from process, not technical capability.
What evaluators are actually looking for
Government evaluators read dozens of technical approaches in every procurement. After a while, they all start to sound the same:
"Our team will begin with a thorough site analysis, followed by stakeholder engagement, concept development, and iterative reviews leading to construction documents."
That sentence is not wrong. It is also invisible. What evaluators are scoring is evidence that your team has already thought specifically about this project's problems.
| What most proposals write | What evaluators want to see |
|---|---|
| "We will conduct a comprehensive site analysis." | Which constraints will drive design decisions, and how will you surface them before they become costly? |
| "Our team has strong stakeholder engagement experience." | Who are the likely stakeholder groups, where will conflict arise, and how will you structure decisions? |
| "We will manage the project to budget and schedule." | Where are the specific cost and schedule risks on this project, and what are your mitigation strategies? |
| "Quality control is embedded in our process." | At what gate points will quality reviews occur, who conducts them, and what happens when issues are found? |
| "We bring relevant past experience." | Which specific past project proves your team has navigated a comparable challenge? What was the outcome? |
How to structure a technical approach
Most government RFPs specify the structure they want. Follow it exactly — reordering sections in a way that evaluators didn't expect creates friction and costs points. If the RFP gives you latitude, a strong default structure for AEC technical approaches is:
- Project understanding: Name the specific challenge this project presents — not a generic scope restatement, but the constraint, risk, or complexity that will actually define the work. This signals immediately that you've read the RFP carefully and thought about it.
- Technical methodology: How you will move from brief to deliverable, with emphasis on the decisions your process is designed to make, not just the phases it passes through.
- Risk identification and mitigation: Three to five specific risks on this project — not generic project risks — with your mitigation strategy for each. This is where many proposals lose the most points.
- Project management and communication: Reporting cadence, change control, decision-making protocol, and issue escalation. Owners want to know how problems get resolved before they become disputes.
- Relevant past performance: One or two specific past projects where your team navigated a comparable challenge, with measurable outcomes and a direct connection to this project's approach.
The most common technical approach mistakes
The failure modes in technical approach sections are consistent across AEC firms of every size:
- Phase lists instead of decisions: Listing phases (site analysis, schematic design, design development) without explaining what decisions each phase is designed to make. Phases describe process. Evaluators want to see judgment about what will be hard and why your approach addresses it.
- Generic risk language: "We will manage risk proactively throughout the project." This sentence earns no points. Name the actual risks for this project — site access constraints, heritage approval timing, unclear program requirements, occupant disruption — and describe your specific mitigation for each.
- Past performance disconnected from the approach: Listing impressive projects in a separate section without connecting them to the approach you're describing. The linkage is what creates credibility. If your past project taught you something about how heritage approvals affect design development timelines, say so and explain how that shapes your approach here.
- Missing the owner's subtext: Every government RFP has a background to the project. Read it. If it mentions a previous failed procurement, a budget constraint that killed a prior scope, or community opposition, those are signals about what the owner is afraid of. Your technical approach needs to address those concerns directly.
- Writing for length instead of for scoring: Technical approach sections that fill page limits with narrative but don't directly address each scored criterion earn average marks at best. Map the criteria before you write a word.
How to differentiate a technical approach
Proposals that score in the top quartile share one characteristic: they prove specific judgment about the specific project.
The most reliable way to differentiate is to identify the one or two things about this project that are genuinely difficult or unusual, name them directly, and explain how your team's approach is designed to address them. This signals two things evaluators respond to: that you've read the RFP carefully, and that your team has already started thinking about the problems they'll need to solve.
For AEC firms, the clearest differentiation almost always comes from past project experience — not from listing impressive projects, but from connecting a specific outcome from past work to the approach you're proposing:
"On the Rideau River water treatment expansion, we identified a conflict between the phased construction requirements and the operational continuity protocols in week one of design, rather than at the 60% IFC stage. Our approach for this project front-loads the same operational sequence review for the same reason."
That is not boilerplate. That is proof of experience. It wins evaluation points.
Using past projects as technical evidence
Most AEC firms have far more relevant past experience than they use effectively in technical approach sections. The problem isn't that the experience isn't there — it's that it's buried in old proposals, project closeout reports, and the memory of principals who were on the project years ago.
The best proposals connect specific outcomes and decisions from past work to the specific methodology being proposed. This requires being able to find the right project quickly, recall what that project actually taught the team, and articulate the connection clearly under deadline pressure.
Stepscale makes past project knowledge searchable and usable during proposal writing. Rather than rebuilding context from scratch for every bid, teams can surface the most relevant past work, identify the outcomes and lessons that apply, and write technical approaches grounded in evidence — not just capability claims.
A pre-writing checklist
Before writing the technical approach, work through these steps:
- Extract every scored criterion for the technical approach section and note the weight allocated to each. Structure your response to match this weighting.
- Identify the one or two genuine technical challenges this project presents — not generic risks, but this project's specific constraints.
- Pull the two or three past projects most relevant to this scope and note the specific decisions, outcomes, or lessons that apply to this assignment.
- Draft a response map: one row per scored criterion, one column for where and how you'll address it in the proposal.
- Write the risk section first. It forces specificity and creates the frame around which the rest of the approach is built.