Prepare an RFP that gives bidders one answerable job

An RFP is not a request for a price. It is the package that tells prospective suppliers what decision you need, what work is included, which documents govern, how to respond, and how responses will be assessed. If those things are scattered between an email, a drawing set and a late addendum, bidders fill the gaps differently. The prices stop being comparable before anyone has made a mistake.

Build the decision before the package

Start with the result you need to buy: a defined scope, a design service, a supply package, an investigation, or a delivery partner. Write the outcome in one paragraph. Then list the evidence a bidder needs to understand it: drawings, specifications, site information, existing-asset records, programme, commercial terms and any required forms.

Do not use an RFP to hide an undecided scope. Mark a decision as open, state who will make it and when, and ask bidders to identify the consequence. That produces useful alternatives; an unmarked gap only produces contingencies that cannot be compared.

Make one governed document set

Put the source files in one Workshop project before issuing. The file drawer keeps documents together, and the workspace can open drawings, PDFs and other project records beside the discussion. Give every issued file a clear name and revision. Keep the superseded file too, but say which edition governs the request.

For each requirement, record the source and location: “architectural A2.01, detail 4” is usable; “per drawings” is not. Workshop’s Requirements view and work register are a useful place to hold the requirement, its evidence and the question or finding it creates. It gives a later reviewer somewhere to return to instead of reconstructing an email chain.

Worked example: procure a roof renewal

An owner needs to replace a leaking low-slope roof before winter. The project folder contains a roof plan, a condition report, photos, an asbestos survey, a target completion date and the owner’s insurance requirements. The request is not “quote a new roof.” It is: remove and replace the roof assembly shown on A1.02; identify any concealed deck repairs separately; maintain drainage; coordinate a safe occupied-building sequence; and provide warranty and closeout records.

Open the files in Workshop and use this brief as the starting objective:

Prepare an RFP for the roof renewal. Read the roof plan, condition report, photos and asbestos survey. List the governing documents and their revisions, extract the scope and information bidders need, identify conflicts or missing decisions, and create requirements and questions with their source locations. Produce a reviewable RFP outline and a bidder response schedule; do not treat an assumption as a confirmed requirement.

Review the resulting requirements and findings in the workspace. Correct the scope boundaries, rule on what is genuinely missing, and assign an owner and date to each unresolved decision. This is the useful use of the project record: it turns a collection of files into a package someone can check before it is issued.

Ask for a response you can evaluate

The response schedule should separate the things that answer different questions:

• proposed technical approach and exclusions;
• price basis, quantities, allowances and taxes;
• programme, lead times and dependencies;
• qualifications, capacity and named responsibilities; and
• departures, assumptions and questions.

State the evaluation criteria in the request. Price may be one criterion, but it cannot answer whether the work meets the requirement, arrives when needed or carries an unpriced dependency. Use the same response headings in the comparison you will make after closing.

The issued package should have a visible structure: invitation and decision; scope and exclusions; document register; site and asset information; bidder instructions and schedule; response form; evaluation criteria; and clarification/addendum log. Exporting a report or sharing a folder is not the issue date by itself. Complete the package in the buyer’s required channel, then retain the exact issued documents in the project.

Run clarification as part of the record

Give bidders one channel and a deadline for questions. Log each material question, its source, the answer and the affected document or requirement. If an answer changes the work, issue a revised package or addendum to everyone who received the original. A private answer that changes scope creates unequal bids.

Before you send

Read the request as a bidder who has never seen the project. Can they find the governing set, the submission time and method, the scope boundary, the evaluation basis and the route for a question? If not, the next response will price the missing information rather than the work.

Open Workshop to assemble the project evidence and keep the issued package, its questions and later decisions in one working context.