A new pursuit can send a proposal team straight into old project sheets, resumes, and familiar language. Before anyone starts writing, give the team a shared view of what this opportunity actually requires.
A practical compliance checklist connects each requirement to its source, the person responsible for answering it, and the place it belongs in the submission. It also makes unanswered questions visible while there is still time to resolve them.
Use the steps below as a working method. The RFP or RFQ, its attachments, and the issuing organization’s formal updates govern the specific pursuit.
1 Assemble the complete opportunity record
Start with the documents your team is working from: the solicitation, attachments, required forms, and published addenda or amendments. Record each document’s title, issue date, and version in one place.
Name a person to check the official posting location for updates. When something changes, record which requirements and proposal sections are affected, then notify their owners. A saved PDF is a snapshot; it should not quietly become the team’s only reference.
Keep questions and answers with the record, including the source and date. If guidance appears to conflict, flag it for clarification through the process specified in the solicitation rather than letting different writers choose different interpretations.
2 Capture submission requirements separately
Put delivery instructions where everyone can find them. Check:
- The submission date, exact time, and stated time zone
- The required delivery method and destination
- Portal access, file types, size limits, and file naming
- Page limits, formatting rules, and any stated exclusions
- Required signatures, forms, certifications, and acknowledgments
- Separate volumes, envelopes, or attachments
- Question deadlines and any mandatory meetings or site visits
Assign an owner to each applicable item. If a form needs someone else’s signature, identify that person early. Set an internal completion target that leaves room to inspect the final files and complete delivery. Follow the actual instructions for the pursuit; requirements vary.
3 Turn compound requests into individual checks
A heading such as “Relevant Experience” may contain several separate asks. The solicitation might request comparable projects, completion dates, the proposed team’s roles, and owner references.
Create a row for each distinct requirement so a strong project description does not conceal a missing reference. Preserve the source wording and add a practical interpretation beside it when useful.
A simple working checklist can contain:
- Requirement and source page or section
- Required response, form, or evidence
- Planned proposal section
- Responsible person and internal due date
- Status and unresolved question
- Reviewer and verification date
Use specific statuses such as “evidence requested,” “draft ready,” and “verified.” Define “verified” as checked against the source requirement and the proposed response, not merely written.
4 Map the evaluation criteria to the outline
Read the submission instructions and evaluation criteria together. Capture any stated weighting, required order, and subcriteria. Give each criterion an obvious home in the outline, using the requested structure where one is prescribed.
Ask two questions about every planned section: What does the evaluator need to learn here? What evidence will support the answer?
A team section may need to show relevant responsibilities and availability, for example, rather than simply list impressive biographies. Capture the specific request before choosing resumes or adding general firm language. If the instructions and evaluation criteria seem inconsistent, track the issue for clarification.
5 Check the evidence before reusing it
For every project example or qualification, identify the source that supports the claim and who can confirm it. Review the facts that are easy to carry forward incorrectly: project dates, scope, delivery role, personnel, references, and completion status.
Separate what the firm did from what an individual did at a previous employer. Keep past-project results separate from proposed commitments on the new pursuit. Confirm that material is approved for reuse and appropriate to share.
When support is missing, leave a visible question for the right person. Polished wording should not make an unverified claim look settled.
6 Give each gap an owner
Consider this fictional example: an RFP asks for two comparable occupied-facility projects, including each project’s phasing approach and the proposed project manager’s role.
The team has two project sheets, but one says nothing about phasing. The checklist should show the missing detail, its owner, and when the answer is needed. The next step is a targeted request to someone who knows that project: what work occurred while the facility remained occupied, and what did the proposed manager actually do?
Once the answer is checked, connect it to the relevant source and response section. If the evidence cannot support the requirement, bring that gap to the pursuit lead instead of filling it with generic language.
7 Keep the checklist active through final review
Before drafting begins, check that every requirement has an owner and a planned response location. Review unresolved gaps with the pursuit lead so the team knows what needs a decision.
As drafts develop, update the checklist with the actual section or page location. Recheck affected rows after addenda, staffing changes, and major revisions.
Before submission, compare the checklist against the final assembled files. A requirement addressed in an earlier draft can disappear during editing or layout. Have a reviewer follow the source references and confirm both the substance and the delivery requirements.
The useful output is a proposal your team can explain and check: where each requirement is answered, what supports it, and who reviewed it.
Pursuit Draft from POLR Labs is built for AEC proposal teams and is currently in private alpha. To explore its source-backed drafting workflow, request a walkthrough.