How to Write an RFP: Good Orders Start with Good RFPs

As a client, the most critical situation to avoid is project failure. Budget overruns, delivery delays, quality issues, and deteriorating relationships with contractors—the root cause of these problems often lies in the quality of the RFP (Request for Proposal) created before project initiation.

"We want to create a stylish website," "We want to emphasize usability," "Please include SEO optimization"—when these expressions appear in an RFP, the project has already begun its journey toward failure.

Consider the case of Mr. Tanaka (pseudonym), a marketing manager at a mid-sized company. In an RFP for e-commerce site renewal, he provided vague conditions: "mobile-responsive," "usability-focused," and "budget of 3 million yen." The result was 10 completely different proposals from various companies. After selecting the cheapest development company, it became clear mid-project that "expected features were not included." Additional development costs of 1.5 million yen were incurred, ultimately resulting in 1.5 times the original budget and a 3-month delivery delay.

What's noteworthy about this case is that the development company had no malicious intent. They simply created proposals based on their expertise and experience in response to the vague RFP. The problem was the client's insufficient requirement definition.

Let's clarify what an RFP is from the basics. An RFP is a document where clients request contractors to "please propose for this type of project." It's not merely a "quotation request," but an important communication tool that clearly conveys project background, objectives, requirements, conditions, and evaluation criteria.

The risks for clients when proper RFPs are not created are surprisingly significant. Direct costs include budget overruns (averaging 20-40% above initial budget), increased project management workload (2-3 times the staff hours), and opportunity losses (sales impact from release delays). Indirect costs include loss of internal credibility, negative impact on future outsourcing activities, and damaged relationships with quality contractors.

Conversely, creating high-quality RFPs can significantly reduce these risks. Quality contractors prefer clear requirements, so good RFPs tend to attract capable candidates. Comparing and evaluating proposals becomes easier, enabling appropriate contractor selection. Most importantly, troubles after project initiation can be prevented in advance.

Even understanding the importance of proper RFP writing, many clients cannot create adequate RFPs due to structural problems.

The primary factor is the inability to "clearly articulate internal requirements in writing." While internal consensus is formed through abstract discussions like "the current website is hard to use" or "we want a cooler design," the work of converting these into specific requirements that contractors can understand is often missing. This tendency is particularly evident in web development RFPs.

Organizational issues are also significant. Often, personnel responsible for RFP creation don't understand both technical knowledge and business requirements. Marketing staff don't understand technical constraints, while system staff don't grasp business requirement priorities. The result is RFPs that are superficial from both perspectives.

Budget setting difficulties cannot be ignored either. While we often hear clients say "we don't know the market rate," rates actually vary greatly depending on project content. The same "corporate website development" can range from 500,000 to 5 million yen depending on requirements. Creating RFPs without appropriate budget awareness leads to unrealistic pricing, deterring quality contractor applications.

There's also a deep-seated misconception that "writing detailed RFPs stifles contractor creativity." While overly detailed specifications are problematic, the purpose of RFPs is to clarify requirements, not to limit solution approaches. By clarifying "what we want to achieve," contractors can create more appropriate proposals.

Time constraints also present major obstacles. Many companies don't allocate sufficient time for RFP creation. Unrealistic schedules like "we want to release by month-end, so we need to issue the RFP this week" cannot produce quality RFPs. The result is rushed content leading to problems later.

The difficulty of internal consensus-building cannot be overlooked either. In projects with many stakeholders, unified understanding of requirements often doesn't exist. Sales departments prioritize "appearance," system departments emphasize "maintainability," and management focuses on "cost"—RFP creation proceeds with scattered priorities.

Addressing these problems requires approaching RFP creation as a systematic "outsourcing preparation process." Rather than simple document creation, it should be positioned as a comprehensive project including internal requirement organization, budget securing, internal consensus building, and clarification of contractor selection criteria.

Creating high-quality RFPs requires a systematic approach. Following these step-by-step procedures enables the creation of RFPs beneficial to both clients and contractors.

Step 1: Requirement Organization and Stakeholder Agreement

The first step in RFP creation is thorough internal requirement organization. Clarify "why this project is necessary," "what we want to achieve," and "what are the success criteria."

Specifically, begin with current situation analysis. Rather than "few monthly inquiries," conduct quantitative current situation assessment like "monthly inquiry volume remains at 1/3 of competitors, with conversion rate at 0.5% significantly below the industry average of 2%."

Next, quantify project objectives. Instead of "improved usability," set measurable goals like "improve inquiry conversion rate from current 0.5% to 2%" or "increase mobile inquiries from 50 to 150 per month."

What's crucial at this stage is unified understanding among all stakeholders. Continue discussions until project owners, working staff, system personnel, and management share the same understanding. Creating RFPs with misaligned perceptions leads to later change requests and additional costs.

Step 2: Clarification of Technical Requirements and Constraints

Once requirement organization is complete, organize technical requirements and constraints. The key point here is describing "requirements" rather than "means."

For example, instead of "please build with WordPress," write "CMS functionality is needed for content updates by non-engineers within the company." This approach allows contractors to propose optimal technical choices to meet requirements.

Also clarify constraints. Specifically describe existing system integration requirements, security standards, operational systems, and maintenance requirements, such as "integration with existing customer management system (Salesforce) is required" or "must meet ISO27001-compliant security standards."

Step 3: Realistic Budget Setting

For budget setting, research market rates while referencing proposal request templates. Obtain rough estimates from multiple development companies or check industry reports to understand realistic budget ranges.

What's important is understanding budget breakdown. For web development projects, break down into elements like design fees, development fees, coding fees, system development fees, testing fees, and project management fees. This makes it easier to predict impact when requirements change.

We recommend presenting budgets as ranges. Instead of "3 million yen," show ranges like "2.5 to 3.5 million yen," allowing contractors to judge appropriate proposal levels.

Step 4: Setting Evaluation Criteria and Schedules

Clarify proposal evaluation criteria in advance. Quantify and set how much weight to give elements like technical capability, track record, proposal content, price, team structure, and communication ability.

For example, set allocations like "technical capability 30%, track record 25%, proposal content 20%, price 15%, structure/communication 10%." Including these criteria in the RFP helps contractors understand evaluation perspectives when creating proposals.

For schedules, aim for realistic timeframes. Secure at least 2 weeks from RFP publication to proposal deadline, 1 week for evaluation/selection, and about 1 week for contract conclusion. Avoid the risk of receiving only low-quality proposals by rushing the process.

Step 5: Structuring the RFP Document

Create the final RFP document with the following structure:

1. Project Overview (background, objectives, expected outcomes)
2. Current Situation Analysis (challenges, constraints, resources)
3. Requirements Specification (functional, non-functional, technical requirements)
4. Proposal Request Items (content to include in proposals)
5. Contract Conditions (budget, delivery, payment terms, rights)
6. Evaluation Criteria (selection process, evaluation items, weightings)
7. Schedule (RFP publication through contract conclusion)
8. Proposal Submission Guidelines (format, deadline, contact information)

In each section, aim for specific and measurable expressions. Abstract expressions cause misunderstandings, so clearly describe numbers, deadlines, and conditions.

When creating RFPs in practice, there are common failure patterns that clients unconsciously fall into. Understanding these in advance enables higher-quality RFP creation.

Failure Pattern 1: "Outsource Everything" RFPs

Writing like "please propose the optimal website for our business" or "please handle everything including SEO comprehensively" delegates requirement definition to contractors. While this may seem to respect contractor creativity, it's actually responsibility shifting.

The problem with this pattern is that contractors must create proposals based on understanding the client's business. This results in either off-target proposals or safe, mediocre proposals. Additionally, vague evaluation criteria make appropriate selection difficult.

The solution is for clients to clarify minimum requirements. Clearly indicate "what's decided and what we want proposed."

Failure Pattern 2: Excessive Specification Detail

Conversely, specifying technical specifications in excessive detail is also problematic. Limiting solution approaches with requirements like "use WordPress version 5.8," "must use jQuery library," or "base color code must be #3366cc."

This approach prevents leveraging contractor expertise and may lock in technically suboptimal solutions. It also increases cost increase risks when specifications change.

The appropriate approach is clarifying "what to achieve" while leaving "how to achieve it" to contractor proposals.

Failure Pattern 3: Non-disclosure of Budget

The attitude of "we'll decide budget after seeing proposals" is also problematic. Contractors must create proposals without budget understanding, often resulting in either over-quality or under-quality proposals.

Additionally, not disclosing budget may deter "quality contractors who want to avoid price competition" from applying. More capable development companies tend to prefer projects with appropriate budget setting.

Always disclose budget, even if approximate. When exact amounts aren't confirmed, show guidelines like "expecting approximately XX yen" or "XX to XX yen range."

Failure Pattern 4: Unrealistic Schedules

Unrealistic schedule setting like "must release next month-end" or "3-day proposal period" is also a typical failure. Rushing prevents quality proposal creation, increasing the risk of selecting inappropriate contractors.

Additionally, unrealistic schedules cause quality contractors to withdraw. More capable development companies prefer not to engage with unrealistic projects.

Set realistic schedules, and if urgency is unavoidable, clearly set "speed priority" as an evaluation criterion.

Failure Pattern 5: Opaque Evaluation Criteria

Vague evaluation criteria like "comprehensive judgment" or "emphasizing price-quality balance" are also problematic. Contractors don't know what to emphasize in proposals, and clients find objective evaluation difficult.

Particularly problematic is when "actually prioritized points" emerge after evaluation. This not only damages contractor trust but also prevents optimal selection.

Quantify evaluation criteria as much as possible and clearly indicate weightings. Even subjective elements should be specified as evaluation items like "design impression" or "proposal clarity."

Failure Pattern 6: Last-minute Contract Conditions

Another common pattern is presenting conditions like "all copyrights belong to the client" or "warranty period is 2 years" after selection without mentioning them in the RFP. This overturns contractor proposal assumptions and causes troubles.

Always include important contract conditions in the RFP. Particularly, copyright, intellectual property rights, warranties, confidentiality, and payment terms require advance disclosure.

RFPs don't end with creation and publication. Proper management of the entire process from Q&A response to contract conclusion enables building good relationships with quality contractors.

Building Trust Through Q&A Response

Responding to contractor questions after RFP publication is an important opportunity to demonstrate client attitude. Quick and courteous responses to questions create the impression of "this client is trustworthy."

Some questions point out RFP deficiencies. Rather than receiving these as "criticism," welcome them as "advice for project success." Actually, questions from experienced contractors often contain important perspectives that clients haven't noticed.

Share Q&A with all candidates. Responding to only one company prevents unfairness from information gaps. However, anonymize questioner company names when sharing.

Ensuring Proposal Evaluation Transparency

In proposal evaluation, strictly apply pre-established criteria. Maintain objective judgment without distorting evaluation based on emotional preferences ("this company's representative seemed nice").

In evaluation processes, implement multi-person evaluation. Rather than decisions by individual staff subjective judgment, evaluate from technical, business, and project management perspectives.

Even for unsuccessful proposers, provide feedback when possible. Even brief reasons like "budget didn't match" or "selected another company for technical requirements" provide valuable information for contractors.

Building Win-Win Relationships in Contract Negotiations

In post-selection contract negotiations, aim for mutually beneficial conditions rather than one-sided condition imposition. Particularly important is appropriate risk allocation design.

Clearly categorize client-side risks (requirement changes, decision delays, lengthy approval processes) and contractor-side risks (technical difficulties, delivery delays, quality issues), and agree in advance on handling methods for each.

Consider contractor cash flow in payment conditions. Rather than full post-payment, consider installment payments with advance payments, interim payments, and completion payments. Stable cash flow is particularly important for small businesses and freelancers.

Long-term Partnership Perspective

Rather than ending with single outsourcing, aim for relationship building with medium to long-term partnerships in mind. Ongoing relationships with quality contractors provide significant benefits for clients too.

Maintain regular communication even after project completion, building relationships for consulting on operations, maintenance, and additional development. This also reduces RFP creation costs for future outsourcing.

Additionally, actively accept improvement proposals and new technology information from contractors. Show willingness to have them contribute to business growth as external specialists.

While understanding RFP importance, the hurdle to actually taking action is high. Implementing the following concrete action steps enables initiating quality RFP creation.

First, this week, implement internal requirement organization sessions. Hold 2-hour meetings with stakeholders to discuss "why this project is necessary," "what we want to achieve," and "how to measure success." Don't seek perfection at this stage—organize within currently understood scope.

Next, conduct budget rough surveys. Send "rough estimate requests" to about 3 development companies to understand market rates. Detailed specification confirmation isn't necessary at this point—general requirements like "corporate site renewal, approximately X pages, with CMS functionality" are sufficient.

By next month, create RFP framework. Following the aforementioned structure, organize each section's items at bullet point level. Even without perfect sentences, organizing "what to write" is the first step.

Use this checklist during actual RFP creation:

Requirement Definition Check

• Are current challenges described quantitatively?
• Are project objectives set in measurable form?
• Are technical constraints and existing system relationships specified?
• Are success judgment criteria clearly defined?

Budget/Conditions Check

• Are realistic budget ranges presented?
• Are important contract conditions (copyright, warranties, etc.) specified?
• Are schedules sufficiently flexible?
• Are evaluation criteria specifically set?

Communication Check

• Are technical term explanations appropriately added?
• Is an environment where contractors can easily ask questions established?
• Are internal decision-making processes clear?

For long-term improvement, accumulate internal knowledge of RFP creation and management. After project completion, record "requirements not covered in RFP," "unexpected challenges," and "contractor feedback" for use in future RFP creation.

Finally, I want to emphasize that RFP creation is not work completed by one person alone. Success requires organizational approaches utilizing internal stakeholder knowledge and sometimes external specialist expertise. Appropriate RFP creation can dramatically improve project success probability and build long-term partnerships with quality contractors. The next step for clients is scheduling next week's requirement organization session.