ROI【🔏Classified File】 No. X046 | What is an RFP

Detective's Note: "Build us a nice system"—this request spawns 90% of project failures. The truth uncovered by ROI Detective Agency's investigation of hundreds of system development projects: successful projects invariably possessed a blueprint called the "RFP (Request For Proposal)." Most clients believe "vendors are professionals, so we can leave it to them" and outsource without articulating "what they want to build." The result: deliverables that are "spec-compliant but unusable," "over budget," and "behind schedule"—a triple disaster. Why do 70% of projects without RFPs fail, while proper RFPs boost success rates to 80%? "Current challenges," "desired state," "mandatory requirements," "evaluation criteria"—the document design technique that transforms vague expectations into concrete contracts through four interwoven elements. Uncover the code that transforms vendor selection from a gamble into scientific decision-making.

What is an RFP - Case Overview

RFP (Request For Proposal), formally defined as "a document where clients clarify requirements, specifications, and evaluation criteria to solicit proposals from multiple vendors," is utilized in the procurement process for system development, consulting, and outsourcing projects. Recognized among clients as a document that systematically describes "what we want to achieve (objectives)," "what functions are needed (requirements)," "by when and at what cost (constraints)," and "how to evaluate (selection criteria)," providing vendors with the foundation for proposal creation. However, in actual practice, it's either dismissed as "tedious paperwork" or leads to analysis paralysis pursuing a "perfect specification document"—most organizations fail to understand its true strategic value as "a foundation for dialogue to align client and vendor understanding."

Investigation Memo: An RFP is not merely a "purchase order" but an "expectation alignment device." Why do "make it nice" requests inevitably fail, while "we want to achieve this state" clarifications generate success? We must elucidate this project success foundation document that implements MVP's "minimum requirements definition" and enables Agile Development's "change-embracing contracts."

Basic RFP Structure - Evidence Analysis

Primary Evidence: Complete requirement description through 8 sections

Section 1: Project Overview

Purpose: Share project background and objectives

Essential elements:

1. Company/Organization Overview
   - Industry and scale
   - Business operations
   - Organizational structure

2. Project Background
   - Why this project is necessary
   - Current challenges and problems
   - Risks of inaction

3. Project Objectives
   - What to achieve (qualitative goals)
   - Definition of goal state
   - Expected effects and outcomes

4. Project Scope
   - Target scope (departments, operations, regions)
   - Exclusions (explicit)
   - Future expansion possibilities

Bad Example (Vague):

"Want to build a system for operational efficiency"
→ Which operations?
→ How much efficiency?
→ What's wrong with the current state?

Good Example (Specific):

"In the sales department's (30 staff) customer management operations,
current Excel-based management causes information sharing delays
and duplicate data entry, resulting in 120 hours of monthly workload loss.
CRM implementation aims to enable real-time information sharing,
eliminate duplicate entry, and reduce workload by 100 hours monthly."

Section 2: Current Situation

Purpose: Enable vendors to accurately understand the current state

Essential elements:

1. Current System Configuration
   - List of systems in use
   - Infrastructure environment
   - Data volume and transaction volume
   - Integration requirements with existing systems

2. Current Business Flow
   - As-Is business processes
   - Time and frequency for each step
   - Bottlenecks and problems
   - Stakeholders and role assignments

3. Current Challenges
   - Quantitative problems (workload, cost, error rate)
   - Qualitative problems (usability, dependency on individuals)
   - Prioritization

4. Constraints
   - Budget ceiling
   - Schedule constraints
   - Technical constraints (mandatory technologies, etc.)
   - Organizational constraints (approval processes, etc.)

Real Example from ROI Detective Agency:

Current State: 
- 200 business framework articles managed in Markdown
- Manual sitemap.xml updates (30 minutes each time)
- Manual weekly ranking tabulation (1 hour weekly)
- Duplicate metadata entry (10 minutes per article)

Challenges:
- Workload when adding articles (quantitative: 10 hours monthly)
- SEO opportunity loss from update oversights (qualitative)

Constraints:
- Budget: Zero development cost (utilizing ChatGPT)
- Timeline: Within 2 weeks
- Technology: Continue using Markdown and Python

Section 3: Requirements

Purpose: Clarify what's mandatory and what's optional

3 Requirement Categories:

Must (Mandatory Requirements):
- Won't contract without these
- Conditions for project establishment
- Example: "Complete migration of existing data"

Want (Desired Requirements):
- Nice to have but not mandatory
- Earn bonus points in evaluation
- Example: "Smartphone app support"

Nice to Have (Optional):
- Future scalability
- Consider based on proposals
- Example: "AI analysis functionality"

Functional Requirements:

What the system "should do"

Examples:
- Customer information registration, search, update, deletion
- Automatic sales data aggregation and graphing
- Email notification functionality
- CSV export functionality
- Permission management (admin, general users)

Documentation Format:
ID | Requirement | Details | Priority | Verification Method
R001 | Customer Registration | Input 20 fields including name, contact | Must | Verify registration possible
R002 | Search Function | Partial match search by name, company | Must | Display results within 1 second
R003 | Mobile Support | Responsive design | Want | Verify operation on each device

Non-Functional Requirements:

How the system "should be"

Performance Requirements:
- Response time: Within 3 seconds for normal operations
- Concurrent connections: 100 users
- Data processing: 100,000 records/day

Availability Requirements:
- Uptime: 99.5% or higher
- Failure recovery: Within 4 hours

Security Requirements:
- SSL/TLS communication
- Two-factor authentication
- Access log recording

Maintainability Requirements:
- Source code delivery
- Operation manual provision
- 3-month maintenance support

Section 4: Proposal Requirements

Purpose: Clarify what vendors should propose

1. System Configuration Proposal
   - Recommended technology stack
   - Infrastructure configuration
   - Architecture design

2. Implementation Approach Proposal
   - Development methodology (Waterfall/Agile)
   - Phasing
   - Milestone setting

3. Project Structure Proposal
   - Team composition (size, roles)
   - Key member skills and experience
   - Communication methods

4. Schedule Proposal
   - Duration for each phase
   - Delivery dates
   - Critical decision points

5. Cost Proposal
   - Initial development cost
   - Monthly operation cost
   - Optional costs
   - Payment terms

6. Risk Mitigation Proposal
   - Anticipated risks and countermeasures
   - Quality assurance methods
   - Trouble response procedures

7. Similar Track Record Introduction
   - Cases from same industry/scale
   - Results and effects
   - Reference materials

Section 5: Evaluation Criteria

Purpose: Make vendor selection judgment criteria transparent

Scoring Example:

Total 100 points

1. Requirements Fit (30 points)
   - Must requirement feasibility: 20 points
   - Want requirement achievement: 10 points

2. Technical Capability & Track Record (25 points)
   - Similar project experience: 10 points
   - Technical validity: 10 points
   - Team skills: 5 points

3. Project Management (20 points)
   - Schedule validity: 10 points
   - Structure appropriateness: 5 points
   - Risk mitigation thoroughness: 5 points

4. Cost (15 points)
   - Initial cost: 10 points
   - Operation cost: 5 points

5. Maintenance & Support (10 points)
   - Maintenance structure: 5 points
   - Response time and scope: 5 points

Important Principles: - Don't automatically select "lowest price" - Judge by comprehensive evaluation - Disclose evaluation criteria in advance - Eliminate arbitrary decisions

Section 6: Timeline

RFP Process Schedule:

2025/11/01: RFP publication
2025/11/08: Q&A deadline
2025/11/10: Q&A responses published
2025/11/20: Proposal submission deadline
2025/11/22-25: Presentations
2025/11/27: Vendor selection & result notification
2025/12/01: Contract execution
2025/12/05: Project kickoff

Desired Project Schedule:

Phase 1: Requirements definition (3 weeks)
Phase 2: Basic design (4 weeks)
Phase 3: Development & testing (8 weeks)
Phase 4: Migration & release (2 weeks)

Total: 17 weeks (approximately 4 months)

Section 7: Proposal Format

Purpose: Receive comparable proposals

Required Sections:
1. Cover page
2. Company overview
3. Project understanding
4. Proposed system overview
5. Functional specifications
6. Technical specifications
7. Project structure
8. Schedule
9. Cost estimate
10. Similar track records

Page limit: Main content within 30 pages
Submission format: PDF
Submission method: Email attachment

Section 8: Contract Terms

Basic Contract Policy:

Contract Type:
- Quasi-delegation or work contract
- Expected contract amount range

Payment Terms:
- Initial payment: 30%
- Interim payment: 40% (upon development completion)
- Final payment: 30% (upon acceptance completion)

Intellectual Property Rights:
- Deliverable copyrights: Belong to client
- Source code delivery: Mandatory

Confidentiality:
- NDA execution required
- Third-party provision prohibited

Warranty:
- Defect liability period: 3 months
- Free correction support

Evidence Analysis: The revolutionary aspect of RFPs lies in transforming "vague expectations" into "concrete contract terms" and eliminating information asymmetry between clients and vendors, thereby dramatically reducing project failure risk.

RFP Creation Practical Steps - Investigation Methods

Investigation Finding 1: Large-Scale Government RFP Case

Case Evidence (Ministry of Internal Affairs "My Number Card Management System Renewal" RFP):

Phase 1: Internal Consensus Building (3 months)

Step 1: Current Challenge Identification
- Department interviews (20 departments)
- Current system problem compilation
- Quantitative data collection (failure counts, processing times, etc.)

Step 2: Project Objective Clarification
- Executive explanation and approval
- Budget allocation (¥○ billion)
- Project charter creation

Step 3: Requirement Prioritization
- Must/Want/Nice to Have classification
- Technical feasibility review
- Security requirement examination

Phase 2: RFP Main Document Creation (2 months)

Step 1: Structure Decision
- Standard format selection
- Section additions/deletions
- Page count target setting (main content 50p)

Step 2: Section Drafting
- Current state analysis: Systems department
- Requirements definition: Operations departments
- Evaluation criteria: Procurement department
- Contract terms: Legal department

Step 3: Internal Review
- Department confirmations (3 rounds)
- Legal review
- Security review

Phase 3: RFP Publication & Q&A Response (1 month)

Publication Channels:
- Government procurement portal site
- Direct notification to major vendors

Q&A:
- Reception period: 2 weeks
- Total questions: 127
- Response publication: Batch publication (anonymized)

Important Q&A Examples:
Q: Will API specifications for existing systems be provided?
A: After contract execution, provided under confidentiality agreement

Q: Is phased release possible?
A: Please include phasing in your proposal

Phase 4: Proposal Evaluation & Selection (1 month)

Proposals Received: 8 companies

First Evaluation (Document Review):
- Independent scoring by 5 evaluators
- Using evaluation sheets
- 3 companies selected

Second Evaluation (Presentation Review):
- 90 minutes per company (60min proposal, 30min Q&A)
- Technical lead attendance mandatory
- Demonstration implementation

Final Selection:
- Top-ranked company by comprehensive evaluation selected
- 2nd place company retained negotiation rights
- Result notification and explanation

Results: - Selection period: 3 months from RFP publication - Contract amount: Within budget - Project success rate: Proceeding as planned

Success Factors: 1. Detailed current state analysis (3 months of investigation) 2. Clear evaluation criteria (eliminating arbitrariness) 3. Careful Q&A response (ensuring transparency) 4. Multiple vendor competition (quality assurance)

Investigation Finding 2: Startup Simple RFP Case

Case Evidence (E-commerce Company "Inventory Management System Construction" RFP):

Constraints:

Budget: ¥3 million
Timeline: 2 months
Internal resources: 0 engineers

Simple RFP (10 pages A4):

1. Background & Objectives (1 page)
"In EC business with ¥50M monthly sales,
managing inventory in Excel.
20 inventory discrepancies and order errors monthly.
Systemization aims to improve inventory accuracy 95%→99%"

2. Essential Functions (2 pages)
- Product master management
- Inbound/outbound recording
- Real-time inventory display
- Reorder point alerts
- CSV import/export

3. Current Data (1 page)
- Product count: 500 SKUs
- Monthly inbound/outbound: 3,000 transactions
- Excel management limitation clarification

4. Desired Technology (1 page)
- Cloud-based
- Mobile compatible
- API integration with existing EC cart

5. Schedule (1 page)
- Development: 6 weeks
- Testing: 2 weeks

6. Evaluation Criteria (1 page)
- Functional fit: 40%
- Cost: 30%
- Delivery date: 20%
- Maintenance structure: 10%

7. Proposal Deadline (1 page)
- 2 weeks later
- Proposal within 10 pages
- Budget estimate mandatory

Results: - Proposals received: 3 companies (1 major, 1 mid-size, 1 freelancer) - Selection: Mid-size SI company (balanced approach) - Development: Completed within budget and on schedule - Effect: 98% inventory accuracy achieved

Lessons: - Perfect RFP unnecessary - Clarify "non-negotiables" - 10 pages sufficient for small projects

RFP Power - Investigation Report

Power 1: Dramatic Improvement in Project Success Rate

Data Evidence (IPA Survey):

Projects without RFP:
- Success rate: 31%
- Budget overrun: 52%
- Schedule delay: 64%

Projects with Proper RFP:
- Success rate: 78%
- Budget overrun: 18%
- Schedule delay: 23%

Power 2: Vendor Selection Transparency & Fairness

Without RFP:
"Ask a vendor acquaintance"
→ No comparison, no competition
→ High cost, low quality risk

With RFP:
"Compare multiple vendors with clear criteria"
→ Price optimization through competition
→ Optimal partner selection

Power 3: Prevention of Requirement Gaps

Problems discovered during RFP creation process:
- "Functions thought necessary" are actually unnecessary
- "Unconsidered requirements" are actually essential
- Perception gaps between departments
- Gap between budget and aspirations

→ Resolved before project start

Power 4: Improved Estimate Accuracy

Without RFP:
Vendor: "Requirements unclear, so ¥10M with buffer"
→ Actually possible for ¥5M

With RFP:
Vendor: "Calculated from detailed requirements: ¥6M"
→ Contract at appropriate price

RFP Limitations and Cautions - Investigation Warnings

Limitation 1: Creation Cost Burden

Problem:
- Detailed RFP creation takes months
- High internal coordination costs
- Excessive for small projects

Countermeasures:
- Simplification according to project scale
- Template utilization
- Focus on minimum essential items

Limitation 2: Flexibility Loss Risk

Problem:
- Too much detail makes changes difficult
- Inhibits vendor creative proposals
- "Following RFP" becomes the goal

Countermeasures:
- Clear on "objectives," flexible on "methods"
- State alternative proposals welcome
- Consider combining with [Agile Development](/behind_case_files/articles/X038_AGILE_DEVELOPMENT)

Limitation 3: Decisions with Incomplete Information

Problem:
- Can't know everything at RFP stage
- Requirements change during development
- Perfect RFP doesn't exist

Countermeasures:
- Phased development with [MVP](/behind_case_files/articles/X036_MVP) thinking
- Contract clauses assuming changes
- Validation period with prototypes

Caution: RFP is NOT a "Contract"

Misconception:
"What's written in RFP is absolute"

Correct Understanding:
"RFP is dialogue starting point"
- Refinement during proposal stage
- Formal specifications finalized at contract
- Continuous adjustments during development

Related Case Files - Investigation Lines

Frameworks with Close Connections:

• MVP: Thinking that minimizes RFP requirements
• Realization First Principle: Feasible RFP over perfect RFP
• Agile Development: Flexible development process post-RFP
• Baseline of Measurement: Quantification methods for evaluation criteria

Advanced Frameworks:

• RFI (Request For Information): Information gathering before RFP
• RFQ (Request For Quotation): Quote request after specification confirmation
• SOW (Statement of Work): Work scope definition after contract

Industry-Specific RFP Cases - Investigation Records

Financial Industry: Core System Renewal RFP

Characteristics:
- Ultra-detailed (over 200 pages main content)
- Strict security requirements
- Financial regulator compliance requirements
- 10-year maintenance premise

Focus Items:
- 99.99% availability
- Complete audit trail preservation
- Disaster recovery (DR)
- Phased migration plan

Manufacturing Industry: Production Management System RFP

Characteristics:
- Emphasis on factory floor integration
- IoT device integration
- Real-time requirements
- Global deployment premise

Focus Items:
- Multi-language support
- Production line integration
- Inventory optimization algorithms
- Traceability

Retail Industry: E-commerce Site Construction RFP

Characteristics:
- Customer experience (UX) focus
- Marketing integration
- Peak season load measures
- Omnichannel support

Focus Items:
- Payment method diversity
- Recommendation functionality
- CRM integration
- Mobile-first

Investigation Conclusion - ROI Detective Agency's Assessment

Truth: RFP is an "Expectation Translation Device"

The essence of RFP is not document creation but the process of translating the "vague image" in the client's mind into "concrete words" that vendors can understand and implement.

3 Principles of Success:

1. Don't Aim for Perfection
   → Deliver at 80% accuracy quickly
   → [Realization First Principle](/behind_case_files/articles/X037_REALIZATION_FIRST)

2. Leave Room for Dialogue
   → "We want this" not "It should be like this"
   → Leverage vendor expertise

3. Set Measurable Criteria
   → Numerical targets, not vague "make it nice"
   → [Baseline of Measurement](/behind_case_files/articles/X041_BOM)

Detective's Conclusion:

Projects without RFPs are like sailing without a map. A perfect map is unnecessary, but basics like "where are we heading," "what should we avoid," and "how do we judge" are essential. Proper RFPs don't guarantee project success, but they dramatically reduce failure probability. That is the most important lesson learned from hundreds of cases investigated by ROI Detective Agency regarding system development.

Case File X046 - Investigation Complete