Edited by us
RFP writing prompt — handling the not-yet-decided
When budget and schedule are still open, how to leave blanks so the document still works.
By Mephify (operator)4 min read
What makes this hard
When you start writing a request for proposals, more is undecided than decided. The budget is in negotiation, the schedule depends on the budget, and nobody has asked whether consortia are allowed.
Hand that state to AI and the undecided gets filled in as if decided. Sentences like 'total budget not to exceed $200,000' or 'six months from contract date' appear naturally, with no source behind the numbers. The reader can't tell confirmed values from examples, and if the notice goes out as is, those numbers become facts.
Make every item carry its own status
The fix is not removing blanks but naming them. Have every item labeled one of three ways:
- CONFIRMED — a settled value with a basis
- PROVISIONAL — under review; may change
- [INPUT NEEDED] — not yet known, plus one line on what fills it
That 'what fills it' line is the most useful part in practice. [INPUT NEEDED: total budget] alone tells nobody who fills it or when, but 'to be entered after finance sign-off' turns the blank into a to-do list.
Put it like this
Budget and consortium eligibility are still open. Don't guess values. Mark them as undecided and add one line each on what will fill them.
Name the regulations; don't let it interpret them
Public procurement may fall under the FAR in the US, or your jurisdiction's procurement law. But don't let AI explain what those rules say. Invented clause interpretations are the most dangerous failure in this document.
Write it like this: name which regulations may apply, and mark applicability as something the responsible office must confirm. The document then reads 'FAR applicability to be confirmed' rather than 'under this clause…'. The former is correct.
The nine parts the instruction requires
Status labels and naming regulations are sentence-level rules. On top of them, this service's RFP instruction requires nine parts of the document's skeleton, because a document missing any one of them can't be used as is.
- ① Project overview — name, issuing body, purpose, background, budget, contract terms, each with its status label
- ② Scope of work — current state, target architecture, build, integration, testing, transition, training, operational support, with what's out of scope stated
- ③ Requirements specification — the heart of the document; explained below
- ④ Project management requirements — governance and reporting cadence, schedule and progress, quality assurance, risk, configuration and change control, staffing and replacement, warranty and maintenance. This is the part most often missing entirely
- ⑤ Deliverables list — deliverable, due point, reviewer, approval step, with no deliverable left without an approver
- ⑥ Proposal instructions and required submissions — proposal outline, mandatory content, submission format
- ⑦ Evaluation criteria — items, sub-criteria, and method are proposed as a provisional draft, with only the score cells left blank. Not inventing scores doesn't mean not building the table
- ⑧ Traceability table — objective → scope → requirement → deliverable → acceptance → evaluation item in one line each, with orphans collected separately
- ⑨ Timeline and contracting checks — dates as slots; applicable regulations, procurement procedure, consortium and subcontracting as items to confirm
One requirement, one obligation
The requirements specification is the heart because it decides what the bidder promises and what the buyer will accept. The instruction splits requirements into functional, non-functional, interface, security, data, and operations, numbers them like FR-01, and allows one obligation per sentence.
Why it splits
'The system shall support user authentication, authorization, and audit logging' is three requirements, not one. If only the logging is missing at acceptance, nobody can say whether it passed.
Split into one line each and every line gets its own acceptance method.
Each requirement carries five companions: status (confirmed, provisional, or open), deliverable, acceptance method, evidence, and owner. A requirement without those five can't be accepted, and that's where contract disputes start. At the end the instruction collects the remaining blanks by number with who decides each, and if the organization has a standard RFP template, it offers to take the file and reorganize to that outline.
Checklist for writing it yourself
- 1Did you separate confirmed from undecided values in the request first
- 2Did you explicitly say 'don't guess the undecided'
- 3Did you require a 'what fills this' line for every blank
- 4Did you tell it to name regulations without interpreting them
- 5Did you state whether the buyer is public or private? That one fact changes the document's structure
Reading helps; trying is faster.