The idea behind it
Incumbent bias is the tendency of a buying team to favor the vendor it already uses. In an RFP it shows up in the requirements. Teams that have used one product for years describe what they need in that product's terms: its feature names, its file formats, its default settings and its support tier. The result is sometimes called a wired or fingerprinted specification. Only the incumbent can meet it in full, so the competition is a formality. Behavioral economists William Samuelson and Richard Zeckhauser named the underlying effect status quo bias in 1988.
The fix is to write requirements as capabilities rather than products. A capability requirement states the outcome the organization needs, such as low-code workflow automation with role-based access, and lets any vendor show how it delivers it. Public procurement rules in many jurisdictions already restrict brand-name specifications or require the words "or equivalent" for this reason. Process matters as much as wording. Criteria set after vendor demos tend to mirror the demos, and an incumbent that helped draft the RFP or sees internal roadmaps has an advantage other bidders cannot match. An audit before issue catches these problems while the RFP can still be changed.
What's inside
- An audit header: RFP title, category, incumbent vendor, auditor and dates.
- Section 1, branded feature names: product names, version numbers, proprietary formats and vendor-specific APIs.
- Section 2, oddly specific must-haves: exact thresholds, UI patterns, deployment details and support models.
- Section 3, requirements only one vendor can meet, including bundled capabilities and unjustified exclusion of open source.
- Section 4, process integrity: who drafted the RFP, when criteria were set, scoring and information access.
- Each check has a risk rating and columns for the finding, requirement reference and whether a rewrite is needed.
- Five before-and-after rewrites from vendor-specific wording to capability language.
Format: PDF (3 pages) and Word document.
A look inside
Pages 1 and 2 of 3 of the PDF. Select an image to enlarge it.
Who uses it
- Procurement and sourcing leads, to check that a competitive process is competitive before it goes to market.
- IT category managers, to rewrite requirements inherited from the incumbent's documentation.
- Evaluation committee chairs, to document how the requirements were set and who contributed to them.
- Internal audit and compliance teams, to review whether a tender could be challenged as favoring one supplier.
When to use it
- A contract is coming up for renewal and the business wants to test the market.
- A draft RFP was written by the team that runs the incumbent's product every day.
- Requirements were copied from the current system's specification or the incumbent's proposal.
- Leadership suspects a sourcing event is a renewal with paperwork.
- A losing bidder on a previous RFP complained that the requirements favored one vendor.
How to use it
Audit the draft RFP before it is issued and rewrite or justify every requirement it flags.
- Complete the RFP Audit Header with the RFP reference, category, incumbent vendor, auditor, audit date and planned issue date.
- Work through Section 1 by searching the draft for product names, version numbers, proprietary file formats and vendor-specific APIs.
- In Section 2, ask where each numerical threshold, UI pattern, deployment detail and support requirement came from.
- In Section 3, ask each evaluator to name three vendors who could meet each requirement, and break bundled requirements into separate capabilities.
- In Section 4, record who drafted the requirements, when the evaluation criteria were approved and whether the incumbent had access other bidders lacked.
- For each check, enter the finding, the requirement reference and whether a rewrite is needed, starting with the High-risk items.
- Rewrite flagged requirements in capability language using the five before-and-after examples as models, or document why the narrow wording is required.
You leave with: A marked-up draft RFP with every vendor-specific requirement either rewritten as a capability or justified in writing, and a record of how the process was kept fair.
Where it goes wrong
- Searching only for brand names and missing thresholds copied from the incumbent's published benchmarks.
- Setting evaluation criteria after vendor demos, so the criteria describe what the demos showed.
- Scoring familiarity, such as "we know how to use it", as if it were a capability.
- Staffing the evaluation team only with people who have worked with the incumbent for years.
Get the checklist
It is free. Enter your work email and we send the download link.
Questions
What is a wired RFP?
A wired RFP is one whose requirements are written so that only one vendor can meet them. It often happens without intent, when the team copies the incumbent's features and terms into the specification. The remedy is to state each requirement as a capability any qualified vendor could deliver.
How do you write vendor-neutral RFP requirements?
Describe the outcome, not the product. Replace a product or API name with the function and the standard it should support, such as a documented REST API or SCIM. Where a specific product or format is truly required, document the reason in the RFP file.
Can the incumbent vendor help write the RFP?
It should not draft the requirements. An incumbent that shapes the wording can tilt the competition toward its own product. Document who contributed to the requirements and give the incumbent the same information as every other bidder.