How to write an RFP for Drupal projects

Most Drupal RFPs fail before the first paragraph is written, because nobody agreed what the document is for. Is it a competitive tender to select a build partner? A market-scanning exercise to establish a budget? A procurement formality required by a grant? Each one needs a different document, a different timeline and a different level of specification.

Write three sentences before you write anything else: the decision (award a build-and-support contract for the platform), the decider (a named panel with a named chair), and the walk-away condition (no proposal below the security gate, or no proposal that cannot meet the hosting ownership requirement). Those three sentences will stop the RFP drifting into a wish list, because every requirement you add has to earn its place against them.

This is also the point to choose your procurement route. A competitive RFP suits a well-defined scope with several credible bidders. A two-stage process (request for information, then a short RFP to three vendors) suits a scope you cannot yet specify. A direct award with a single vendor is defensible when the work is small, urgent or genuinely sole-source — but say so openly rather than dressing it up as competition.

Crawl the current site and count: nodes by content type, media assets and total file size, languages, user accounts by role, taxonomy vocabularies, redirects currently in place, and forms or webforms that receive submissions. Then count the things that are not content: integrations, cron jobs, custom modules, and the three scripts somebody wrote in 2019 that nothing can replace.

Next, build the URL inventory. Pull twelve months of analytics and rank pages by sessions, by conversions if you have them, and by inbound links. The top thousand URLs are the ones you cannot afford to break; they become the redirect coverage requirement in the RFP. This is the difference between a migration that preserves search visibility and one that quietly loses a third of it.

Finally, inventory the constraints: supported PHP and database versions, hosting contract end dates, the security review your IT team will insist on, the accessibility obligation in your funding agreement, and the date by which a grant or board decision expires. Constraints discovered at contract stage become delays; constraints written into the RFP become acceptance criteria.

Break the work into eight to twelve work packages, each with a deliverable that exists at the end: a design system in Figma, a content model in configuration, a migrated content set with a reconciliation report, a redirect map covering the top thousand URLs, a launch runbook. A work package with a deliverable can be priced, scheduled and accepted. A work package described as 'design and build' cannot.

Then write the out-of-scope list. This feels negative and it is the most commercially valuable page in the document. Out of scope: ongoing content entry beyond the agreed migration volume, photography, copywriting beyond the agreed page count, third-party licence costs, translations, and any integration not listed in section six. When a vendor later says 'that was not included', you want a page that says it was.

State buyer responsibilities with equal precision. Who supplies brand assets, who approves designs, how many review rounds, who provides API credentials, who is available for user testing, how quickly approvals arrive. Vendors price risk, and an unnamed approval process is priced as risk.

Write requirements as numbered clauses: actor, obligation, standard, evidence. 'R4.3 The platform must support editorial workflows with at least three states (draft, review, published) and at least four roles with configurable transitions. Evidence: a demonstration of a page moving through all states in a staging environment.' A clause like that can be scored. 'User-friendly editorial experience' cannot.

Describe the content model explicitly, because this is where Drupal projects are won and lost. Content types, fields and their types, references between entities, taxonomies and their hierarchy, and the listing behaviour of each. You do not need to design the model — that is the vendor's job — but you do need to describe the editorial outcomes it must produce.

Separate the mandatory from the desirable. Mandatory requirements become pass/fail; desirable ones earn points. Mixing them in one list guarantees arguments at evaluation, because every vendor will claim to meet everything and the panel will have no way to differentiate.

Decide who owns the infrastructure before you ask anyone to price it. Hosting inside the vendor's platform is simpler to start and harder to leave; hosting inside your own cloud account is more work to set up and gives you the billing relationship, the data residency and the exit route. Both are legitimate. What is not legitimate is leaving the question open and inheriting whichever the vendor prefers.

Write the operational requirements as evidence requests. Backup retention with a restore test report. Recovery point and recovery time objectives, with the last three actual incident recoveries. A patching commitment expressed in hours after a Drupal security advisory, with the date of the last critical patch. Availability measured, not promised. Each of these is a document that either exists or does not, which makes evaluation fast and honest.

Then write the exit clauses while everyone is still being polite. A complete export in structured formats, no extraction fee, documented runbooks, a named transition period, and a contractual statement that you can keep operating the platform without the vendor. If a vendor refuses these clauses at award stage, you have learned something more valuable than any reference call.

Choose seven to nine criteria and weight them to total 100. For Drupal work a workable starting point is technical approach 18, hosting and operations 15, total cost of ownership 15, comparable experience 13, named team 12, security and compliance 10, delivery and support model 9, accessibility and QA 8. Change these to match your priorities, but change them deliberately and write down why.

Define what each point on the scale means, in terms of evidence. A five names the approach, the people and the proof. A three is plausible but unsupported. A one is asserted only. Without definitions, three evaluators will score three different proposals, and the vendor with the best written English will win.

Set the gates separately. Legal standing, insurance, three comparable Drupal builds, a named architect, security assurance, and the ability to meet your hosting model. Gates are checked before scoring and are not negotiable; everything arguable belongs in the weighted score.

Issue the RFP to three to five qualified bidders with a single submission channel, a question deadline, and a commitment to publish every question and answer to all bidders. This is not bureaucracy; it is what stops one vendor from having a materially better brief than another, which is the most common grounds for a procurement challenge.

Hold a bidders' conference if the scope is complex. Thirty minutes of architecture explanation saves three weeks of clarification emails, and it tells you which vendors ask good questions — a useful signal in itself.

Do not extend the deadline for a vendor who asks. Extend it for everyone, or not at all, and publish the reason. Late submissions from well-liked vendors are how procurement processes acquire a reputation that follows the project for years.

Score independently and in writing before the panel meets, then discuss only the criteria where scores diverge by more than two points. Average the rest. Require a citation from the proposal for every score of four or above; it is remarkable how many high scores lose their justification when someone asks where in the document it came from.

Run the demonstration against the same three tasks for every finalist, in the vendor's own environment, with real content. Ask them to publish a page, roll back a deployment, and prove the requirement the panel finds hardest to believe. Score the demonstration separately and include it in the published criteria so it is not a surprise.

Call the references yourself, with a script. Ask what the project originally cost against the final cost, what changed, how a missed deadline was handled, who did the work versus who sold it, and how the handover went. Then award, notify all bidders with their own scores, and publish the outcome internally — including the parts of the process that did not work, so the next procurement starts further ahead.