Requests for Proposals (RFPs) are a staple of big technology decisions. They create structure, documentation, and a paper trail that legal and procurement teams appreciate. But they also create blind spots that can tank your transformation long after the bid is awarded.
This is your guide to using RFPs as one data point—without letting them drive the bus off a cliff.
Why We Still Use RFPs (The Good)
Done well, RFPs can:
- Force alignment on what you think you need (requirements, priorities, scope).
- Create traceability for promises and commitments (useful for contracting and, if necessary, disputes).
- Standardize comparisons across multiple vendors and integrators.
Keep them. Just don’t mistake them for the whole decision.
Where RFPs Go Wrong (The Bad)
1) Feature Checklists ≠ Transformation Success
RFPs over-weight yes/no functionality. But software features are rarely why programs fail. It’s the operating model, data, integration, and people. A system can check every box and still miss the mark in the real world.
Fix: Pair your checklist with scenario-driven evaluations (e.g., “Create a make-to-order work order with a last-minute design change and price update across CRM → CPQ → ERP → MES → AP.”). Score how well each vendor executes—not just whether it’s theoretically possible.
2) The “Yes-ology” Problem
Most RFPs return with 98–99% “Yes.” Technically true—and practically useless. The key isn’t can it do X; it’s how natively, how intuitively, how fast, and at what cost.
Fix: Replace binary answers with graded responses:
- Native (no config)
- Configuration
- Extension / Low-code
- Customization
- Third-party bolt-on
- Not supported
Tie each grade to effort, risk, and TCO.
3) Unrealistic Time & Cost
RFPs typically price “design–build–deploy” for a single platform. They underrepresent the big-ticket realities: data migration/cleansing, cross-system integration, business readiness, cutover, stabilization, and change management. That’s where schedules slip and costs explode.
Fix: Require a total program plan and bottom-up effort model covering:
- Data strategy (mapping, quality, conversion waves)
- Integration architecture & non-functional needs (security, performance, observability)
- Change management (org design, process adoption, training at scale)
- Hypercare & value realization (benefit tracking, process KPIs)
The Blind Spots RFPs Rarely Catch
- Competitive advantage erosion: “Standard” cloud processes can flatten what makes you different. Require vendors to show how your differentiating workflows will be preserved.
- Vendor lock-in & exit: Ask for data egress SLAs, archival formats, and switching playbooks up front.
- Operating model fit: Tools succeed only if roles, approvals, and decision rights are realigned. Bake target operating model deliverables into scope.
- Roadmap risk: Cloud vendors change features on their schedule. Define update governance, opt-in/out policies, regression testing, and robotic test coverage.
- SI bait-and-switch: Name key personnel with substitution rights & penalties. Request resumes + LinkedIn histories and conduct live technical interviews.
A Better Way to Run Your Selection (Keep the RFP, Upgrade the Process)
- Phase Zero first. Define business case, value levers, constraints, and the target operating model before you send an RFP.
- Scenario-based demos & conference room pilots. Use your data, your edge cases, and timeboxed build exercises.
- Independent fit scoring. Weight process fit, UX, integration effort, and extensibility—not just features.
- Commercials that protect you.
- Price caps, rate cards, and change-order thresholds
- Named resources with replacement rules
- Data ownership, egress rights, and auditability
- Update cadence controls and non-regression commitments
- Reference checks that matter. Same industry, size, and complexity; talk to the project sponsor and program manager, not just the reference handler.
- Program-level plan & TCO. Insist on a multi-year cost model (licenses, services, internal FTEs, integrations, testing, updates, training, hypercare).
- Owner’s team + PMO. Don’t outsource control. Stand up an internal PMO with independent QA to “trust but verify.”
What Your RFP Should Actually Ask
- Show us the end-to-end scenario execution (with our data).
- Map native vs. config vs. customization vs. 3rd-party for each requirement.
- Quantify the adoption plan: stakeholder impacts, training waves, KPI targets.
- Propose the data migration strategy by domain (customer, item, BOM, supplier, pricing, etc.).
- Detail integration patterns, SLAs, security model, and observability.
- Commit to key personnel and update/test governance.
- Deliver a program plan that includes stabilization & value realization.
Questions to Pressure-Test Your Decision
- What value outcomes are we funding—beyond “go-live”?
- Where will we conform to software, and where will software conform to us (and why)?
- If the vendor’s roadmap removes a feature we rely on, what’s our control?
- Could a composable architecture (core + best-of-breed + interoperability layer) reduce lock-in and risk?
- If we had to exit in three years, how painful would it be—and what’s the plan?
Learn More
Download our Lessons from 1,000 Digital Transformations and the Digital Transformation Report for objective benchmarks, implementation risks, and vendor-neutral guidance.
And don’t forget to join us at:
Stratosphere 2025
🗓 August 25–27, 2025 | Denver, CO (In-person & virtual)
A vendor-neutral, expert-led conference on digital transformation strategies.
Details & registration: thirdstage-consulting.com/stratosphere-2025
The Executive Mastermind
An exclusive peer network of transformation leaders collaborating on strategy and innovation.
Learn more: thirdstage-consulting.com/the-executive-mastermind
