Why Your Tenders & RFPs Fail: A Design Ops Guide to RFI, RFP, and PRD

I’m finally back from the summer break and ready to roll with new posts. I’ve given quite a bit of thought to the direction I want to take with this blog, focusing on what drives me and what I see missing in the content landscape. While I’ve touched on popular topics like my Personal site toolset review and why Research Ops is part of Design Ops!, I now want to dive into more insightful content that provides unique, field-tested value, much like my post on the Tools We Rely On Daily for Design-Ops Success.

These days, my work revolves around two core goals: boosting the effectiveness of our design processes and driving sales for our group. A significant part of that sales process involves the world of tenders, RFI (Request for Information), and RFP (Request for Proposal). The more I work in this space, the more I see a critical need for improvement. I've been responsible for preparing numerous bids and conducting business analysis, and frankly, I'm often surprised at how poorly these crucial documents are crafted.

This isn't just a rant; it's a diagnosis. The way we ask for work directly impacts the quality of the work we receive. Let's break down the problem and explore a more effective, design-driven solution.

The Procurement Alphabet: A Quick Look at Tenders, RFI, RFP, and PRD

Before we dissect the issues, let's get our terms straight. These acronyms are often used interchangeably, but they represent distinct stages in the procurement and product development lifecycle. Understanding them is the first step to using them effectively.

• RFI (Request for Information): This is the exploratory phase. A company uses an RFI to gather general information from various suppliers about their capabilities. It’s like window shopping—you’re not ready to buy, but you want to see what’s out there and who the key players are. It’s a low-commitment way to survey the market.
• RFP (Request for Proposal): This is a formal invitation to bid. An RFP provides detailed information about a specific project or need and asks vendors to submit a proposal outlining their solution, timeline, and, of course, cost. This is where the serious courtship begins. A good RFP is built on a clear understanding of the problem.
• Tender: Often used synonymously with an RFP, a tender is a more formal, structured, and often public process for procuring goods or services. It’s common in government and large corporate projects where transparency and adherence to strict rules are paramount.
• PRD (Product Requirements Document): This is an internal document, but it’s the secret ingredient to a great RFP. A PRD clearly articulates a product's purpose, features, functionality, and behavior. It’s the blueprint. Without a solid PRD, an RFP is just a list of wishes built on a shaky foundation.

The Tender Trap: Common Issues I See Every Day

The goal of any tender or RFP is to find the best partner to deliver the best solution for a fair price. Yet, the process is often structured in a way that achieves the opposite. Here are the most common traps I've encountered, particularly within the Polish market.

The Price-Only Paradox

In Poland, there’s a strong tendency to create tenders that are scored almost exclusively on one metric: price. While budget is undeniably important, a price-only evaluation creates a race to the bottom. It incentivizes agencies to cut corners, understaff projects, and skip crucial discovery and research phases just to submit the lowest bid. This approach provides no guarantee of quality or even that the final delivery will fit the actual need. The client gets a cheap solution, but rarely the right solution, leading to higher costs down the road in the form of redesigns, bug fixes, or a product that fails to meet user needs.

The Vague vs. The Overly-Specific RFP

I constantly see RFPs that fall into one of two unhelpful categories:

• The Black Box: The document is so vague and poorly defined that it’s impossible for any vendor to create an accurate estimate or propose a meaningful solution. It’s a guessing game, and the proposals submitted are often wildly different because everyone is interpreting the requirements differently.
• The Locked Box: The document is so hyper-specific that it seems written to favor a pre-selected vendor. I recently analyzed a tender for the city of Tarnów where the description for a 3D model was so particular—down to technical specifications that seemed inappropriate for the stated performance requirements—that it strongly suggested an existing asset was already earmarked for the job. This practice stifles fair competition and prevents the client from discovering potentially better, more innovative solutions from other bidders.

The NDA Labyrinth

Non-Disclosure Agreements are a standard part of business, but they can be misused in the RFP process. I recently bid on and won a project where the scope of work we discussed after signing the NDA was substantially different from what was described in the initial tender documents. Certain critical aspects were intentionally omitted from the public-facing RFP.

While I understand the need for confidentiality, this bait-and-switch wastes an enormous amount of time and resources for all the bidding companies who prepared proposals based on incomplete information. It poisons the well of trust before the project even begins. A simple clause stating that "further critical details will be disclosed under NDA" would be a more transparent and respectful approach.

The "We Think We Know What We Want" Syndrome

It's a classic scenario in the agency world. A potential client comes to us with a request for a specific piece of software. We invest time in estimation and offer preparation. Then, once we start talking to them, it becomes clear that what they're asking for is completely different from what they actually need.

This is a natural part of the sales and discovery process, but it points to a deeper problem. How many companies go through a full tender process, sign a deal, and start a project based on terms that neither side fully understands? This misalignment is a recipe for disaster, and it starts with a poorly researched and defined set of requirements long before any vendors are contacted.

Anatomy of a Good Tender: My suggestion

It’s not all bad news. I recently had the chance to analyze a tender for the city of Olsztyn, and it was a breath of fresh air. While not perfect, it was a fantastic example of what to do right. The requirements were clearly stated, giving us a solid basis for estimation. They even included diagrams to help visualize complex parts of the system, which was hugely beneficial.

Could it have been better? Sure. Some sections were a bit repetitive, and the requirements could have been organized more logically. But it stood head and shoulders above the average RFP because it demonstrated a genuine effort to be clear and comprehensive. It proved that creating an effective tender is possible, even for a public institution.

"communication is the most significant factor for success in IT projects"

This all comes back to a fundamental truth of our industry. As a study from 2017 noted, "communication is the most significant factor for success in IT projects" (Stevenson & Starkweather, 2017), so it should be tailored to its audience. A tender is the very first, and arguably most important, piece of communication in a project.

The Solution: Injecting Design Thinking into Procurement

So, how do we fix this? The answer lies in applying the very same principles we use to build great products: discovery practices and user experience (UX) design. We need to treat the procurement process itself as a design problem.

Start with an Internal PRD

The root of most bad RFPs is a lack of internal clarity. Before you even think about writing a Request for Proposal, your team needs to create a robust Product Requirements Document (PRD). This involves:

• Stakeholder Workshops: Get all the key decision-makers in a room. What are the business goals? What problem are we really trying to solve?
• User Research: Who is this product for? What are their needs and pain points?
• Defining Scope: Use techniques like user story mapping to define the core features and prioritize them (e.g., MoSCoW method - Must have, Should have, Could have, Won't have).

A solid PRD, born from a thorough discovery process, becomes the unshakeable foundation for your RFP. You’ll be asking for what you actually need, not just what you think you want.

Write Your RFP Like a UX Writer

Think of the vendors reading your RFP as users. Your goal is to help them understand your needs quickly and clearly so they can give you their best possible response.

• Structure & Hierarchy: Use clear headings, bullet points, and a logical flow. Start with the "why" (the business problem) before diving into the "what" (the requirements).
• Clarity Over Jargon: Avoid ambiguous language. Define your terms. If a requirement is complex, add a diagram or a flowchart. The Olsztyn tender was a great example of this.
• Provide Context: Don’t just list features. Explain the user scenario behind each requirement. Instead of "Add a data export button," try "As a sales manager, I need to export a monthly report of all new leads in .csv format so I can analyze team performance." This gives vendors invaluable context to propose better solutions.

By applying these principles, you transform your RFP from a confusing list of demands into a clear, compelling project brief that attracts the right partners. You stop wasting time on clarification calls and start receiving high-quality, relevant proposals.

Moving Forward Effectively

It feels great to be back on track and sharing these thoughts with you. My focus is shifting towards these more systemic, operational challenges because that’s where I believe we can make the biggest impact. Better tenders, RFIs, and RFPs lead to better collaborations, better products, and less wasted time and money for everyone involved. And when we speak about public tenders then hard earned money.

I'll be aiming for weekly posts from now on, and I'm also excited to be starting a small YouTube series to explore these topics in more detail. I hope you'll like it.

Let's stay effective!

References

Deborah Stevenson & Jo Ann Starkweather, 2017. "IT Project Success: The Evaluation of 142 Success Factors by IT PM Professionals," International Journal of Information Technology Project Management (IJITPM), IGI Global Scientific Publishing, vol. 8(3), pages 1-21, July.