By Ryan Darby, PPM AI Solution Specialist
If your RFQs are not delivering the results you expect, you are not alone. With a 130% increase year-on-year in RFQs as the preferred buying method, it’s time to get the process, and the outcomes, right.
Vague requirements get vague answers. Ask for “reporting capability”, and you’ll get a yes, with no idea whether that yes covers what you specifically need. The fix is not more detail for its own sake, it is the right detail: the goals, constraints, and context that let a vendor design a solution instead of guessing at one. Get that right, and your RFQs become faster to run, easier to compare, and far more likely to deliver.
Summary
Vague Request for Quote (RFQ) requirements produce vague vendor responses, generic capability confirmations, broad assumptions, and quotes that are hard to compare or trust. The gap is rarely about vendor capability, it is about missing context: the business problem, the intended use, and what success looks like. When that context is included and RFQS become goal-led, vendors can propose real solutions instead of guessing, and buyers get quotes they can actually compare. This article shows what that looks like in practice.
When your RFQ requirements are not actually what you need
This can happen when an RFQ is issued before the underlying needs are fully understood. Sometimes, procurement becomes more about completing a process than exploring what is truly required. From the vendor’s perspective, it is common to receive long spreadsheets filled with broad headings or generic labels, sometimes with ideas still taking shape. When requests for precise commitments follow these, it can be difficult to provide meaningful responses and to compare options fairly. This can affect both the review process and the final delivery.
For example, we have seen RFQs that simply ask for project management capabilities such as waterfall, agile, and hybrid. While we can confirm these are available, it helps to understand why you need each approach, how deeply you plan to use them, and whether you need them to work together or report across all methods. Sharing any challenges you hope to address with these methods allows us to tailor our response to your needs. When you provide that context, we can offer solutions that are much more relevant and valuable.
You know projects are central to your company’s strategic goals. Your project and portfolio management (PPM) solution should support that work. The same applies to your PMO and PPM goals. When you share those goals, vendors can align their responses more easily and deliver better results.
We understand that sharing goals and requirements can sometimes feel daunting. The following sections offer practical ways to ask clearer questions in your RFQ, helping you receive more useful and comparable responses.
Structuring goal-led RFQ questions to get better quality answers
Requirements are often described as labels or broad capability statements, such as ‘reporting capability.’ While these are a starting point, they do not always provide enough detail to guide a meaningful response.
For example, do you need to solve a particular reporting challenge? Are standard reports sufficient, or do you require several custom reports? The difference can have a significant impact on cost. If you are under or over quoted for what you need, it may affect your decision-making.
One of the most common capability examples requested for a PPM tool is ‘integration with the finance system’, or ‘the ability to integrate with SAP’. Yes, that is possible. But why do you want the link? What process are you trying to automate? Do you want to move actuals, forecasts, or other data? These details make a real difference to the work involved and help us provide a realistic quote. Without them, we may need to rely on assumptions, which can lead to misunderstandings. Those assumptions may be wrong.
To cover this, you might ask vendors to provide their assumptions, but this often results in lengthy lists that cover details missing from the RFQ. By sharing more information upfront, you enable clearer, concise and more accurate responses. That helps you choose a PPM solution that better fits your needs.
Another common example we often see is asking for an ‘intuitive user interface.’ While every vendor will say their solution is easy to use, this does not always help you compare options or find the best fit. For instance, if your users are not professional project managers and only use the system occasionally, it is important to have a simple, easy-to-use solution. If visibility into project progress is a challenge and your team is still building project management skills, sharing this context helps us recommend the right approach. With this information, we gain a clearer understanding of your needs and environment, which allows us to tailor our response to what will work best for you.
Getting more specific about RFQ requirements
Another area that can cause confusion is when it is unclear whether a requirement is needed immediately or simply being considered for the future. A classic example in PPM is the ability to create project registers. Ability adds little, a standard response may be: “Yes, we can create registers.” But that may not give you the detail you need. It helps to specify whether you need one register or several, if it is required now or in the future, and whether you want the cost included. Without this detail, important elements may be missed or unnecessary costs included, making it harder to compare quotes.
The best approach is to be as specific as possible. For instance, you might need a risk register with specific fields, or you may want confirmation that the tool can support this in the future without a cost estimate at this time. Ideally, begin by sharing your goal. For example: ‘We currently use Excel for registers and cannot report on them. We need a risk register at minimum, and we would like to know if more can be added as needed.’
A long list of requirements in Excel can make it hard to see the overall objectives. Without understanding the bigger picture, it is challenging for vendors to suggest the best solutions or help you achieve your main outcomes. This often leads to responses that address each item separately, rather than offering a cohesive, streamlined solution that delivers real value.
You have to follow an RFQ process, but is it working against you?
We recognise that good procurement takes time, and sometimes you need to begin the process before all requirements are fully defined. From a vendor’s perspective, it’s common to receive extensive documentation to complete, sometimes over several weeks, only to find out that requirements will be finalised later. Once the project starts, new needs often come up that weren’t included in the original RFQ. This can affect timelines, budgets, and the overall scope of work, and may mean the original quote needs to be adjusted.
Trying and failing to solve every problem with the first implementation
One of the biggest reasons implementations fail is when the initial requirements try to cover everything at once. From experience, we know this can be too much for any organisation to absorb.
Introducing too much change or extra functionality can make adoption harder. We’re always happy to share what’s worked well for other organisations and help guide you through the process.
We’re here to help you shape a requirements list that tackles your key challenges while staying manageable and valuable. If you can involve us early in the process, we encourage you to do so. There are practical ways to engage with vendors before the formal RFQ, even within standard procurement policies. For example, you might organise an informal Q&A session, set up a pre-RFQ workshop to clarify objectives, or invite feedback on draft requirements.
These early engagement methods can fit within most procurement policies as long as all vendors are treated equally and everything is documented. Early conversations like these help everyone get a clearer understanding of needs, surface important details, and spot potential issues before they become problems. By including early engagement, you help make sure your RFQ addresses the right requirements and sets your project up for success.
At Sensei, we are passionate about sharing knowledge and supporting client success. Our team is dedicated to helping you, and we are always happy to offer our experience and insights. It can be challenging to gather requirements without the right context or experience with PPM solutions. We would welcome the opportunity to help you run an effective RFQ process that leads to the best outcome for your organisation (which may not be us!).
Here is a better way to frame common RFQ questions.
| Generic RFQ question | Strategic RFQ question |
|---|---|
| Does the system provide role-based access control? | We manage project and financial data across multiple business units, and access needs vary by role. How does your solution support role-based access to ensure data security while still enabling cross-functional reporting and collaboration? |
| Can the solution support resource management? | We currently struggle to understand resource capacity and allocation across projects, leading to overcommitment and missed deadlines. How does your solution help forecast capacity, optimise allocation, and improve resource decision-making at a portfolio level? |
| Does the tool provide dashboards? | Our leadership team needs a simple, real-time view of portfolio performance, but they are not frequent users of PPM tools. How does your solution provide intuitive, executive-level dashboards that improve visibility and support faster decision-making? |
| Is the system cloud-based? | We are transitioning to a cloud-first IT strategy and need to ensure scalability, security, and minimal internal infrastructure management. How does your cloud architecture support these goals, including data security, performance, and future growth? |
| Can the system track project budgets? | We currently track project budgets in separate systems, making it difficult to reconcile forecast vs actuals and report on portfolio financial performance. How does your solution support integrated financial tracking, including budgets, forecasts, and actuals, and improve reporting accuracy? |
Checklist for a good RFQ
- Start with outcomes, not features. Clearly define the business goals, challenges, and outcomes you’re trying to achieve before detailing solution requirements.
- Engage vendors early. Use pre-RFQ discussions or workshops to validate assumptions, refine requirements, and identify gaps before issuing the request.
- Provide context, not just requirements. Share the business drivers, current challenges, constraints, and measures of success so vendors can tailor their recommendations.
- Assess more than technical fit. Evaluate implementation approach, delivery experience, support, adoption, and how the solution will deliver business value.
- Be clear on scope. Distinguish between what must be included in the current quote and what may be considered in future phases.
- Leave room for discovery. Highly prescriptive RFQs can limit innovation. Give vendors the opportunity to suggest alternative approaches and improvements.
- Invest time upfront. A well-prepared RFQ leads to more accurate quotes, better vendor selection, smoother delivery, and stronger outcomes.
- Remember: The quality of responses you receive is often directly related to the quality and clarity of the information you provide.
Better RFQs begin with better conversations
A strong RFQ isn’t about listing every detail. It’s about giving vendors a clear understanding of your goals, challenges and what matters most, so they can recommend the right solution and provide a realistic quote.
We often see the best results when organisations spend a bit more time at the start. By involving vendors early, focusing on the real problem to solve, and allowing space for discovery before finalising requirements, you set the stage for clearer responses, more accurate pricing and a smoother delivery.
If you’re preparing for a PPM procurement, try looking at your RFQ from a different angle. Are you simply listing what you need, or are you sharing what you’re aiming to achieve? Shifting your focus in this way can make a real difference to the quality of responses you receive.
At Sensei, we’re always glad to share our experience and help organisations create stronger RFQs. Even if you’re just starting out or exploring your options, an early conversation can help you avoid common pitfalls and feel more confident in choosing the right solution.
If you’re planning a PPM procurement or working on an RFQ, we’d love to chat. Let’s talk about your goals, refine your requirements together, and help set your project up for success. Get in touch today!
Frequently Asked Questions (FAQ)
Q: Why do generic or vague RFQ requirements lead to disappointing vendor responses?
A: Broad labels like reporting capability, integration with SAP, or an intuitive UI make vendors guess. They may answer with simple yes statements or assumptions. Without context, vendors may under-scope or over-scope. Detailed, goal-led requirements lead to better proposals and better delivery outcomes.
Q: What kind of context should we include to get more accurate quotes?
A: Start with your business goals, pain points, current limitations, and desired outcomes before listing features. For example, explain why you need an integration and what data or process it should support; explain user type and usage frequency for usability needs; and say whether a feature is required now or checked for later use. That turns a tick-box RFQ into a request for quote that vendors can price and design from.
Q: How can we reframe generic questions into strategic ones?
A: Tie each question to the problem and result you want. Instead of asking whether the tool has dashboards, ask how executive-level dashboards will improve visibility and decisions for users who are not frequent PPM users. The table above shows the same shift for access control, resource management, dashboards, cloud strategy, and financial tracking.
Q: What are the first steps to transition from generic to goal-led RFQs in our organisation?
A: Start small rather than trying to rewrite your entire procurement template at once. Pick one upcoming RFQ and, before listing any features, write down the two or three key business problems it needs to solve. Use that as the filter for every requirement you include; if a line item does not trace back to one of those problems, question whether it belongs. The reframing table above is a useful internal exercise: take five of your usual generic questions and rewrite them the way we have shown. Once your team sees how much more useful the responses are, it becomes easier to make goal-led framing the default rather than the exception.
Q: What should we specify about inclusions vs. future possibilities in the RFQ?
A: Be clear about what must be built and priced now, versus what is only being checked on for future use. For example, do not ask for the ability to create project registers unless you say whether you need a risk register now and what it must include, or just confirmation that more can be added later. Clear scope keeps pricing fair and comparisons clean.
Q: How do we avoid over-scoping the first implementation and hurting adoption?
A: Focus on the most important problems and phase the rollout to fit readiness. Ask vendors how they would sequence the work to deliver early value, ensure change control, and enable real use. Bring vendors in early, before formal procurement, so they can share experience, shape a manageable scope, and align support with your goals.
Q: How can procurement teams practically involve vendors earlier without breaching procurement policies?
A: Early engagement does not need to compromise fairness or probity. Most procurement frameworks allow market sounding, requests for information (RFIs), or informal briefing sessions ahead of a formal RFQ, provided that every shortlisted vendor is given equal access and the process is documented. A pre-RFQ workshop or Q&A session, open to all vendors under consideration, lets you test whether your draft requirements make sense before they are locked into a formal document. The goal is not to pick a favourite early; it is to stress-test your thinking so the RFQ you eventually issue reflects real needs rather than assumptions.
Q: How can we measure the effectiveness of improved RFQ practices over time?
A: Look at both the RFQ process itself and what happens afterward. To make measurement simple and effective, here are the key metrics to track:
- Number of clarification questions sent by vendors
- Difference between quoted cost and final delivered cost
- Incidences of scope creep during delivery
- User adoption rates after implementation
- Stakeholder satisfaction with the solution
- Measurable value delivered
Fewer vendor questions and closer alignment between quoted and final costs usually reflect clearer requirements. High adoption and positive feedback indicate the solution is delivering value. Improvements across these metrics over successive RFQs show that better questions are leading to better decisions.
Q: What strategies help manage internal resistance to sharing more context or changing RFQ processes?
A: Resistance usually comes from two places: concern about fairness or confidentiality, and concern about the extra effort involved. Address the first by making it clear that sharing business context is different from sharing a budget or favouring a vendor; it simply helps every respondent understand the problem you are solving. Address the second by piloting the approach on a single RFQ rather than mandating it everywhere at once and using the results to build the case internally. Having a template, like the reframing table above, also lowers the effort barrier considerably; teams are not starting from a blank page; they are adapting a proven structure to their own requirements.
About the author
Ryan Darby has worked in PPM and work management for over 20 years. He is currently part of the National Industry PhD Program at UniSQ, where he is helping to advance the use of AI to improve project success. Ryan brings deep expertise and insight to both the project management profession and Sensei’s clients. He is also an industry expert across PMI, PMO, and project management and has completed more RFQs than he can remember.
