RFI, RFP and RFQ Management

Selecting a Partner Is the First Delivery Decision

An enterprise implementation begins taking shape before the project team is mobilized.

The questions asked during procurement influence which suppliers respond, what they assume, how they estimate and what the customer eventually signs.

A vague request can produce confident proposals that describe different projects. A detailed questionnaire can still miss the business processes that determine success.

The purpose of RFI, RFP and RFQ management is to create a clear, evidence-based selection decision and a deliverable commitment.

Chapter 4 established the business case. This chapter explains how the organization translates that intent into a sourcing process that tests capability, exposes assumptions and prepares both parties for delivery.

The objective is not to collect the most impressive presentation.

It is to understand which solution and delivery team can support the required business outcomes, under which conditions and at what sustainable cost.

5.1 Understand RFI, RFP and RFQ

This book uses RFQ to mean Request for Quotation. Terminology can vary between organizations, so the issued document should define its purpose explicitly.

An RFI explores available approaches and supplier capabilities. An RFP requests a proposed solution and delivery approach. An RFQ requests a quotation against a sufficiently defined requirement.

These are tools, not a compulsory three-step sequence.

An organization that understands the market and its requirements may proceed directly to an RFP. A well-defined additional service may justify an RFQ without another broad discovery exercise.

Conversely, asking for a fixed quotation while major scope decisions remain unresolved can create misleading price comparisons.

Choose the instrument according to the uncertainty that must be resolved.

The document title alone does not determine the legal effect of a response or an award. The organization's procurement function should establish the applicable process and obtain appropriate contract review.

5.2 Begin with the Business Case

A sourcing package should explain why the organization is undertaking the transformation.

Translate Chapter 4's business outcomes into the processes and capabilities suppliers must address.

If the objective is to shorten the billing cycle, describe the current delays, affected business units, approval dependencies and financial-system interfaces. “Provide an invoicing module” is not an adequate description of that need.

Give enough context to support a responsible proposal without turning an early business case into a prescriptive technical design.

Clarify the in-scope organizations, expected user groups, deployment priorities and important constraints. Distinguish confirmed facts from working assumptions.

A target go-live date should include its business reason and the dependencies already known. Suppliers should be able to explain the conditions under which the date is achievable.

Where information is incomplete, acknowledge it and define how it will be resolved.

The sourcing process should improve the investment decision, not conceal uncertainty until after a supplier has been selected.

5.3 Build the Evaluation Team Before Issuing the Request

The people who will judge the responses should help shape the questions.

Procurement coordinates the process. Business process owners define operational needs and acceptance expectations. IT and architecture teams assess the enterprise landscape. Finance evaluates commercial assumptions and the connection to the business case.

Security, data, support and legal specialists participate where the scope requires their judgment.

The delivery leader connects these perspectives.

Agree evaluation responsibilities, decision authority, review dates and escalation arrangements. Review potential conflicts of interest and handle them through the organization's established process.

The evaluation team needs time to read, question and compare responses. A sourcing timetable that ignores reviewer availability can force important decisions into hurried meetings.

Separate subject-matter evaluation from final approval. An architect's recommendation about integration feasibility does not automatically authorize a commercial commitment.

Likewise, a low price does not resolve a failed operational requirement.

The team should know who can recommend, who can approve and which evidence is required for each decision.

5.4 Use an RFI to Reduce Market Uncertainty

An RFI is useful when the customer needs to understand the available approaches before defining a detailed competition.

Ask focused questions about comparable delivery experience, solution options, implementation constraints, support models and the information required to estimate responsibly.

For example, a company considering a project-management transformation may ask suppliers how they would approach shared resources, multiple financial systems and phased business-unit rollout.

The response should reveal how the supplier thinks about the problem.

Keep the request proportionate. Requiring a fully designed solution at the information-gathering stage creates unnecessary effort and may encourage unsupported assumptions.

If asking for indicative costs, identify their preliminary nature and request the assumptions that drive them. Do not compare an early budget range with a later committed quotation as though they have equal certainty.

Use the findings to refine the sourcing scope, identify unresolved questions and establish a justified shortlist where the chosen process allows one.

An RFI does not validate every capability it describes. Important claims still require evidence during subsequent evaluation.

5.5 Structure an RFP Around the Operating Model

An RFP should help suppliers understand the business and produce comparable, inspectable proposals.

Include the transformation objectives, organizational context, process scope, current systems, relevant data volumes, integration landscape and expected rollout approach.

Provide the response format, evaluation approach, submission arrangements, clarification process and required assumptions.

Ask suppliers to describe how they will address People, Process, Data and Technology throughout the ten-stage lifecycle.

A useful response should explain discovery, solution design, build and configuration, migration, testing, business readiness, cutover, hypercare and transition to support.

The proposal should distinguish supplier responsibilities from customer responsibilities.

For example, “customer provides clean data” is too broad to manage. Ask which data objects are required, who defines cleansing rules, who executes corrections and who accepts reconciliation.

Request an integrated delivery plan with dependencies and decision points. A series of dates without assumptions is not enough.

Allow justified alternatives where appropriate, but require suppliers to separate the requested baseline response from optional variations so comparison remains possible.

5.6 Write Requirements That Can Be Evaluated

A requirement should describe the business need clearly enough for both a supplier response and later acceptance.

“User-friendly time entry” is difficult to evaluate consistently.

A stronger example is: “An authorized employee can enter time against an eligible project task, submit it to the designated approver, correct rejected entries and view the resulting status.”

Add relevant conditions, volumes, controls and exceptions.

Do not invent performance thresholds merely to make the document look complete. Agree them with process owners and technical specialists, supported by expected workload.

Give requirements stable identifiers. Record their priority, owner, related outcome and acceptance scenario.

Distinguish mandatory conditions from preferences and future aspirations. If every requirement is labeled mandatory, the evaluation loses its ability to separate essential capability from desirable functionality.

Include non-functional needs such as security, availability, recoverability, accessibility, maintainability and performance where they matter to the operating model.

A long feature list should complement, not replace, end-to-end scenarios. Individual features can all be present while the complete business process remains unsupported.

5.7 Require More Than a Yes-or-No Response

A supplier's “Yes” may mean standard functionality, configuration, custom development, a third-party component or a future product possibility.

Those answers have different delivery and ownership implications.

Use a structured response classification.

For each material requirement, ask for the proposed treatment, evidence, limitations, dependencies and commercial inclusion.

An extension may be entirely appropriate. The evaluation should make its implications visible rather than treating all non-standard responses as automatically unacceptable.

Similarly, a standard capability still requires configuration, permissions, data and testing before it supports the customer's process.

Roadmap statements should remain separate from currently available capability. Do not treat an uncommitted future feature as proven readiness for a critical release.

The aim is to understand how the supplier will deliver the outcome and what must be true for the response to remain valid.

5.8 Manage Clarifications as Controlled Information

Supplier questions frequently reveal weaknesses in the sourcing package.

Maintain a clarification log with a reference, question, approved answer, issue date and any effect on the response requirements.

Use the communication route and timing defined for the procurement. Material clarifications affecting the common requirement should be made available consistently to the relevant participating suppliers, subject to the applicable process.

Protect supplier-confidential information. A common answer should not disclose another bidder's proprietary design or pricing.

When a clarification changes scope, update the relevant document or issue a controlled addendum. Explain whether suppliers must revise their responses and whether the timetable changes.

Avoid allowing informal conversations with individual stakeholders to become hidden commitments.

For example, if Finance tells one supplier that historical migration is unnecessary while the published request requires it, the resulting prices will not be comparable.

The clarification process should restore one understood baseline before evaluation and contracting proceed.

5.9 Test the Business Process in Demonstrations

Supplier-led demonstrations show what a product can do. Customer-defined scenarios reveal how the proposed solution handles the customer's important work.

Provide a manageable set of scenarios in advance, with clear objectives and representative sample data.

For a project-based business, follow project creation, resource assignment, time submission, rejection, approval, billing eligibility and the required financial handoff.

Include an exception. A successful normal transaction does not demonstrate recovery from an integration failure or correction of an incorrectly approved entry.

Ask the supplier to identify what is standard, what has been configured, what is a demonstration-only customization and what remains to be built.

Observe the process with the relevant business owners. Record evidence against the evaluation criteria rather than relying on the presenter's confidence.

A focused proof of concept may be appropriate for a high-impact uncertainty. Define its scope, environment, evidence and exit criteria before it starts.

Use synthetic or approved sample data. A selection exercise should not require unrestricted access to production information.

Demonstration success is selection evidence. It does not replace implementation testing or User Acceptance Testing.

5.10 Evaluate the Team That Will Deliver

A capable product does not guarantee a capable implementation.

Assess the proposed delivery organization, not only the supplier's brand or the experience of its sales presenters.

Ask who will lead architecture, functional design, integrations, migration, testing and program governance. Establish which people are proposed, which are confirmed and which will be assigned later.

Review relevant experience in comparable complexity, including business-unit rollout, cross-system processes and operational transition.

Discuss availability and allocation. A highly experienced architect assigned to several overlapping programs may not provide the capacity assumed in the plan.

Ask how substitutions are handled, how knowledge is retained and how delivery quality is reviewed.

Reference discussions should focus on evidence: how the supplier handled unclear requirements, migration quality, difficult decisions, changes and support handover.

Seek appropriate permission for reference contact and respect confidentiality.

The aim is not to demand a perfect delivery history. It is to understand whether the supplier recognizes delivery risk and has a credible way to manage it.

5.11 Use an RFQ for a Defined Commercial Baseline

An RFQ works best when the requested service or product can be described clearly enough for meaningful quotation.

For an enterprise rollout, this may follow clarification of scope and solution assumptions. It can also support a bounded activity such as a specified training package or a defined additional migration rehearsal.

State quantities, deliverables, responsibilities, environments, acceptance expectations, timing and the required pricing breakdown.

Require exclusions and dependencies to be explicit.

Two quotations for “data migration” may cover different numbers of objects, rehearsals and reconciliation activities. One may include extraction and cleansing; another may assume the customer performs both.

A price difference is informative only after the scope difference is understood.

If significant uncertainty remains, request a suitable commercial structure or a bounded discovery step rather than implying that a fixed price removes the uncertainty.

Chapter 6 will examine estimation and commercial planning in more detail. At this stage, the essential principle is that the quotation must describe a deliverable baseline.

5.12 Normalize Commercial Responses

Compare total scope and ownership cost, not just the first price shown in the proposal.

Use the same assessment horizon and assumptions for recurring costs. Distinguish implementation services, subscriptions, third-party products, support, travel and other applicable charges.

Record currency, tax treatment, price validity, payment timing, volume assumptions and any conditions affecting the quoted amount.

Keep genuine optional work separate from work required to achieve the baseline.

Consider two fictional proposals, shown in ₹ lakh.

Supplier A appears cheaper at ₹80 lakh until the baseline gaps are included. The normalized comparison reverses that initial impression.

This does not automatically make Supplier B the preferred supplier. Technical fit, delivery capacity, risk and the agreed evaluation method still matter.

The additions in this example are illustrative confirmed charges, not estimates silently attributed to a real supplier. In an actual process, obtain clarification of uncertain amounts and record the basis of comparison.

Do not modify the underlying quotations to create an apparently clean comparison. Maintain an evaluation view that reconciles back to each supplier's response.

5.13 Establish an Evidence-Based Evaluation Model

Define the evaluation criteria and scoring method before reviewing supplier responses, and communicate them as required by the sourcing process.

Assess mandatory conditions separately from weighted preferences. A strong price score should not compensate for failure to meet a genuinely essential requirement.

An illustrative model for suppliers that pass mandatory gates might allocate 30% to business-process fit, 20% to delivery capability, 15% to architecture and security, 15% to migration and adoption, and 20% to commercial value.

These weights total 100%. They are an example, not a universal recommendation.

Define what each score means. On a 0–5 scale, a claim without adequate evidence should not receive the same treatment as a demonstrated capability with understood limitations.

Specify any minimum thresholds and the handling of missing evidence.

For this example, a supplier with category scores of 4, 3, 4, 3 and 5 receives a weighted total of 3.85 out of 5, or 77 out of 100.

The calculation is (4 × 30 + 3 × 20 + 4 × 15 + 3 × 15 + 5 × 20) ÷ 100.

Record individual assessments, discuss differences and retain the rationale for the moderated result. Where price is evaluated separately, follow that separation consistently.

Scores organize judgment. The decision record must still explain material risks, unresolved conditions and the reasons for the recommendation.

5.14 Complete Due Diligence Before Commitment

Due diligence should address the risks that remain after written responses and demonstrations.

Confirm the proposed team, significant subcontractors, dependency ownership, support arrangements and the status of any third-party components.

Where appropriate, relevant specialists should review financial resilience, security evidence, data handling, continuity arrangements and the ability to sustain the engagement.

Match the depth of review to the importance and exposure of the procurement.

Do not confuse a policy document or certification with proof that every part of the proposed service meets the required operating conditions. Understand its scope and relevance.

For solution claims, distinguish demonstrated behavior from statements that still require validation.

For resource claims, distinguish named individuals from indicative role profiles.

Retain open matters in a decision log with an owner and required resolution date.

Some conditions may be resolved before selection, others before contract execution or mobilization. The approval should explicitly state what remains unresolved and what commitment may proceed.

5.15 Turn the Selection into a Deliverable Agreement

Selecting a preferred supplier is not the end of the sourcing work.

The final agreement must reconcile the request, response, clarifications, agreed changes and commercial schedules into a consistent set of commitments.

Check scope, exclusions, customer responsibilities, assumptions, deliverables, acceptance criteria, environments, integrations, migration, training, cutover and hypercare.

Ensure that a capability demonstrated during selection is treated explicitly where it forms part of the purchased scope.

Conversely, do not assume that every feature seen in a product demonstration is included in the agreed implementation.

Resolve conflicting statements before mobilization. “Partner validates migrated data” and “customer is solely responsible for reconciliation” may conceal different expectations about execution and approval.

Procurement and legal owners should establish the intended document hierarchy and contract terms through the applicable process.

The delivery team should review whether those commitments are operationally achievable.

Chapter 7 will develop the Statement of Work in detail. Here, the essential outcome is a consistent baseline that both parties can explain in the same way.

5.16 Handover from Presales to Delivery

The delivery team needs more than a signed document and a project start date.

Transfer the original business objectives, evaluation findings, response assumptions, clarification decisions, demonstration commitments, commercial boundaries and remaining risks.

Include the rationale behind effort and schedule estimates and the expected level of customer participation.

Review any gap between the team proposed during selection and the team now available.

A useful handover asks the delivery leads to explain the critical commitments back in their own words.

Which processes must work at the first go-live? Who cleans the data? What is excluded? Which dependency could change the timeline? What does acceptance require?

Uncertainty discovered here should be resolved before it becomes a dispute during delivery.

The handover connects Presales and Commercial Definition with Mobilization in the ten-stage lifecycle. Its purpose is continuity of understanding, not completion of another administrative meeting.

5.17 The Delivery Leader's View

Supplier selection is an early test of how the future partnership will handle uncertainty.

Observe whether the supplier asks meaningful questions, distinguishes standard capability from extension, challenges unrealistic assumptions respectfully and explains the customer's responsibilities.

The customer should demonstrate the same discipline.

Provide reliable information, make decisions available and avoid seeking unconditional commitments against an undefined scope.

A good sourcing process allows both parties to disagree constructively before the disagreement becomes expensive.

The delivery leader's responsibility is to make operational consequences visible.

A compressed timeline may require additional customer capacity. A lower price may exclude essential validation. A broader scope may delay the benefits established in Chapter 4.

Select with those consequences understood, and preserve that understanding when the project begins.