SAP RFP Questions That Expose a Weak Partner

Most SAP RFP questions get answered by a proposal team that will never set foot on your project. That’s not a scandal. It’s how the industry staffs a bid: a pursuit lead, a solution architect on loan for three weeks, a writer who has answered “describe your implementation methodology” four hundred times, and a library of past responses to paste from.

So the useful question isn’t “what should our RFP ask?” It’s “which questions can a bid team not answer without the people who would actually deliver?” Below are 14 of them. For each one: why it exposes a weak partner, what a good answer sounds like, what a weak one sounds like, and where to ask it so the answer means something.

What an SAP RFP Can and Can’t Tell You

An RFP (request for proposal) asks a shortlist of firms to propose how they would do a defined piece of work, and at what price. It sits in a family of documents procurement people call RFx. An RFI (request for information) comes first and collects capabilities so you can build a shortlist. An RFQ is a request for quote when price is the main question, or a request for qualifications when you are pre-screening who may bid at all.

In an SAP project the RFP usually selects the implementation partner, the systems integrator (SI) who will configure S/4HANA, move your data, and run the program. That is a different exercise from choosing the software, and most RFP templates online are written for the software decision. They ask whether the product can do three-way match. You already know it can.

What a partner RFP can tell you is how a firm thinks about your specific scope. What it can’t tell you, on its own, is whether the people who wrote that thinking will be the ones doing the work. That gap is the whole game, and it’s why this list leans on questions that have to be answered live. (If you’re earlier in the process, our guide on how to choose an SAP implementation partner covers the full selection method and a weighted scorecard to score these answers against.)

One thing the RFP should not reward: the badge. A partner level tells you about the firm’s commercial relationship with SAP, not its delivery record, and SAP retired the silver and gold partnership logos years ago. The history is in our breakdown of SAP partner levels. Every proposal will still lead with it.

Answers come from three places, and the questions below are sorted with that in mind:

• The written response. Good for facts a firm can be held to later: names, numbers, rate cards, assumptions. Bad for judgment, because a bid writer can produce judgment-shaped prose on demand.
• Oral presentations. The only place you can ask a follow-up and watch who answers it.
• The reference call. The only place someone who paid the invoices tells you how it went.

SAP RFP Questions About Approach and Scope

1. “What transformation approach do you recommend for us, and when would you recommend the opposite?”

Why it exposes weakness: Greenfield (a fresh S/4HANA build), brownfield (a technical conversion of the ECC system you run today), and the selective middle path some firms call bluefield are different programs with different risk, cost, and staffing. A firm that recommends the same path to every client is describing its delivery model, not your situation. The second half of the question is the test. A partner who can’t say when they’d advise the other way hasn’t thought about your case.

A good answer names the facts about your system that drove the recommendation: how much custom code you carry, how clean the master data is, whether you want to redesign processes or keep them, how much history you need online. Then it names the one condition that would flip the call.

A weak answer is a slide about the firm’s “proven conversion factory” or “greenfield accelerator,” with no reference to anything you told them. If you haven’t decided yet, our comparison of greenfield vs brownfield gives you enough to judge the reasoning. With ECC mainstream maintenance ending at the close of 2027 (extended maintenance runs to 2030 at a premium), expect every firm to push speed. Speed is an argument for a path, not a reason.

2. “Model one scope expansion for us: add a country, or a module. What changes in cost, timeline, and team?”

Why it exposes weakness: A firm that built its estimate from your actual scope can tell you which workstreams stretch, which integrations get touched, and which roles extend. A firm that templated its response has to go away and think.

A good answer is specific and a little uncomfortable: “Adding Mexico adds a localization workstream, an e-invoicing integration, and a second data migration wave. We’d extend our finance lead and add a localization consultant, and your go-live moves.”

A weak answer: “We’d need to assess that.” Sometimes that’s honest. In a finalist presentation, after weeks of discovery, it usually means the estimate wasn’t built on your environment.

3. “What are the three biggest risks you see in our project, and what would you do about each?”

Why it exposes weakness: Every partner knows where your project is fragile. Saying so in a proposal feels like losing the deal. The firm that names real problems in week zero is showing you who shows up in week twelve.

A good answer is particular to you: “Your vendor master has duplicates across three company codes; your month-end relies on a custom report nobody owns; your team can’t release a finance lead full time.” Each risk comes with a mitigation and an owner.

A weak answer lists risks that apply to every ERP project on earth, such as change management, executive sponsorship, and data quality, with no detail about yours. It also tends to skip timeline realism. A partner quoting “typically 12 to 18 months” before seeing your system is quoting its brochure.

The Team Questions Bid Teams Hate

4. “Name the people. What percentage of their time is on our project, and what happens when one of them leaves?”

Why it exposes weakness: The most consistent complaint in SAP delivery is that the people who sold the work are not the people who did it. Senior consultants win the deal, then move to the next pursuit. No malice is required. A consultancy’s economics produce this on their own.

It’s also the complaint at the center of the most expensive public SAP dispute of the last few years. In September 2025 Zimmer Biomet sued Deloitte Consulting for $172 million over its S/4HANA implementation, alleging that the team Deloitte assigned included unskilled and inexperienced personnel and delivered an overly customized system full of defects. Deloitte disputes the claims and moved to dismiss in November 2025, arguing that the contract Zimmer Biomet signed covered what it’s now complaining about. An allegation is not a finding. The lesson for your RFP doesn’t depend on who wins: according to UpperEdge’s analysis of the filings, neither the master agreement nor the work order set guardrails on staffing continuity or qualifications.

A good answer gives names, roles, years on the module, percentage allocation, and start dates, and accepts a key-personnel clause: named people can’t be moved without your written approval, replacements need equal or better credentials, and the partner eats the knowledge-transfer cost.

A weak answer: “We’ll finalize staffing after contract signature.” Translation: you’ll get whoever is on the bench that month.

5. “Who wrote this proposal, and which of those people will work on our project?”

Why it exposes weakness: It’s a slightly rude question, which is why it works. Big firms have professional bid centers. Nothing wrong with that, but it means the written response measures the bid center. Ask it in the orals, and insist the proposed delivery lead presents the solution section rather than the partner who owns the account.

A good answer is plain: “The solution design was written by Priya, who’d be your solution architect; the rest was pulled together by our pursuit team.” Then Priya answers your follow-ups without looking at anyone.

A weak answer is a room where the salesperson takes every technical question, or where the proposed project manager is “being finalized.”

6. “Which work goes to subcontractors or offshore centers, and who configures the system?”

Why it exposes weakness: Blended rates hide the delivery model. A low rate usually means a larger share of the work is done remotely, and some of the “firm” may be subcontractors. Either can be fine. Neither should be a surprise. The different types of SAP partners run very different models here, from boutiques that do everything with their own people to global firms with large offshore benches.

The risk has been known for a long time. Michael Doane, writing in 2012 about global delivery models, warned:

“The worst practice when ‘going global’ is to opt for a maximum measure of remote services as a cost-cutting strategy. As with many other short-term economies, this one will lead to far greater long-term losses.”

His reasoning still holds: configuration is iterative, remote teams often lack the business context, and knowledge transfer to your people suffers when they never sit in the configuration work.

A good answer gives the onshore/offshore split by phase, names any subcontracting firms, and explains how design decisions made on site reach the people configuring remotely.

A weak answer gives one blended number and calls the rest “our global delivery network.”

Technical Questions That Separate Method From Marketing

7. “How will you size our custom code before you commit to an estimate?”

Why it exposes weakness: On a brownfield or selective conversion, custom ABAP (the Z-code your team has built up over years) is one of the biggest swing factors in cost. Most partners will say “we’ll assess it early.” That’s a delay, not a method.

A good answer describes SAP’s own toolchain, which is documented in SAP Activate, SAP PRESS’s methodology book: usage data from the Usage Monitor (transaction SUSG) to find code nobody runs, the Custom Code Migration app to build deletion packages, and the ABAP Test Cockpit (ATC) to flag S/4HANA incompatibilities and offer semi-automated quick fixes. The same book says the rough-cut estimate should assume those quick fixes where possible. For code that survives, a good answer places each extension in SAP’s three-tier extensibility model: tier 1 is new ABAP Cloud development, tier 2 wraps legacy code behind released APIs, tier 3 is classic custom code, used only when nothing else works. That tiering is what “clean core” means in practice.

A weak answer: “Our experienced ABAP developers will handle remediation.” Experience isn’t a method. Ask for a sanitized ATC output from a past project and see if they can produce one.

8. “How many mock data loads are in your plan, how do you reconcile them, and what does your dress rehearsal look like?”

Why it exposes weakness: Data migration is where estimates are thinnest and projects slip the most. The number of rehearsals a partner commits to in writing tells you how seriously it takes the riskiest chapter of the program.

A good answer gives a count of mock loads, a reconciliation method (record counts and financial balances agreed by your business owners, not just “load successful”), and a dress rehearsal that matches SAP’s own definition. In SAP Activate, the dress rehearsal system is built from the most recent copy of production, and “the rehearsal is intended to confirm the ownership, sequence, and duration of the conversion activities.” Its result feeds the go/no-go decision.

The reconciliation piece matters more than it sounds. Migrating to SAP S/4HANA (SAP PRESS, 2024) tells the story of a company that stored Northern Ireland as “NI” in its old system. NI is also SAP’s country key for Nicaragua. The value passed every syntax check, and after the conversion the Northern Irish companies were Nicaraguan. Loads that “succeed” can still be wrong.

A weak answer treats migration as a technical task inside “build,” with no count and no named migration lead. If you can’t find migration as its own line in the estimate, that’s the answer.

9. “List our integrations back to us. What happens to each one, and what happens to PI/PO?”

Why it exposes weakness: Most scope disputes trace back to interfaces nobody modeled at selection. A partner that can read your interface inventory back to you, grouped by what it will do with each, has actually looked.

A good answer sorts every interface into keep, rebuild, or retire, and has a view on middleware. If you still run SAP Process Integration or Process Orchestration (PI/PO), its mainstream maintenance ends at the close of 2027, with extended maintenance to 2030, so the RFP answer should say how and when interfaces move to SAP Integration Suite. If you’re buying through RISE with SAP (SAP’s bundled cloud subscription), a good answer also explains where extensions will live on SAP BTP (Business Technology Platform) rather than inside the core.

A weak answer: “We support RISE” and “we have deep integration expertise,” with no interface count anywhere.

Commercial Questions That Show Who Carries the Risk

10. “List every assumption in your proposal that would trigger a change order if it proves false.”

Why it exposes weakness: The assumptions section is where the real price lives. “Client will provide cleansed data by the end of design.” “Client decisions within the agreed turnaround.” “Interfaces capped at the number listed in the appendix.” Each one is reasonable. Each one is also a future invoice.

A good answer produces a numbered list, with the cost effect of each assumption breaking, and is willing to make some of them reciprocal: if the partner’s own dependencies slip, the same logic applies to them.

A weak answer is a proposal where the assumptions are scattered across appendices, or a partner who says “standard assumptions apply.” (The partner will call a missed assumption scope clarification. Your invoice will call it a change order.)

11. “How do your invoices tie to deliverables we can inspect?”

Why it exposes weakness: Fixed fee, time and materials (T&M), and milestone billing all sound different on paper. What matters is what has to be true before you pay. In the Zimmer Biomet case, UpperEdge’s reading of the contract found that roughly $50 million of a $63 million engagement was tied to calendar dates rather than to confirmed deliverables. Calendar billing pays for time passing.

A good answer ties payment to artifacts you can check: a signed-off design, a passed integration test cycle, a reconciled mock load, a completed dress rehearsal. Some firms will also offer a holdback released after hypercare.

A weak answer: “We can do fixed price or T&M, whichever you prefer.” That’s a sales position, not a risk position.

12. “What is your rate for change-order work, by role, and does it differ from the base rate?”

Why it exposes weakness: Buyers negotiate the headline rate and forget the change-order rate, which is where a lot of project margin gets recovered. Ask for the rate card by role and seniority, and ask whether it applies to out-of-scope work. Our table of SAP consultant hourly rates gives you market ranges to check it against.

There’s an older point underneath this one. As Michael Doane observed in The SAP Blue Book in 2012:

“Whenever a consulting firm comes to a client site to make its pitch, the opening remarks often include the phrase, ‘We wish to partner with you.’ What this proposed partnership consists of will seldom be elaborated because there is no ‘partnership’ substance in a straight billing relationship.”

He’s right, and it isn’t cynical. A billing relationship is a fine thing to have. Just price it like one.

A good answer is one rate card that covers base and change work, with the onshore/offshore split held constant.

A weak answer leaves change-order rates “to be agreed,” which means agreed later, when you have no alternative.

Support and Reference-Call Questions

13. “How long is hypercare, what ends it, and who supports us after that?”

Why it exposes weakness: Go-live is the start of the part your business actually feels. A partner whose support team (application management services, or AMS) has no connection to the implementation team creates a handoff gap right when your users are least sure of the system.

A good answer gives a hypercare length, exit criteria written as measures (open defect counts by severity, a clean month-end close), incident response times, and the names of the people who carry over from the project into support. Ask about the junior-to-senior ratio in the AMS team. That’s where margins quietly shift.

A weak answer: “We provide post-go-live support.” A promise, not a plan.

14. The reference call: “Tell me about the project that slipped.”

Why it exposes weakness: Every partner has a project that went sideways. The firm that claims otherwise is the risk. References a partner selects will be happy ones, so ask for references you choose from their client list, at your size and in your industry, and ask them questions a satisfied client can still answer honestly:

• How accurate was the original timeline, and what caused the biggest delay?
• How many mock conversions did it take before the data reconciled?
• How much custom code did you end up with, and has it slowed your upgrades?
• What was the biggest cost you didn’t see coming in year two?
• Were the people in the proposal the people on the project?
• How did the partner behave at your first month-end close after go-live?

A good sign is a reference who names a problem and then tells you how the partner handled it. A bad sign is a reference who can’t remember who the project manager was.

Where to Ask Each SAP RFP Question (and How to Lock the Answer In)

A good answer that doesn’t make it into the contract is a nice memory. This table routes each question to the place where it’s hardest to fake, and to the clause that holds the partner to it.

Question	Where to Ask It	Weak-Answer Tell	Clause That Locks It In
1. Recommended approach, and when you’d advise the opposite	Written, then challenged in orals	Same approach for every client	Approach and scope baseline in the SOW (statement of work)
2. Model a scope expansion	Orals, live	“We’d need to assess that”	Priced options for named expansions
3. Top three risks in our project	Written	Generic ERP risks	Risk register as a contract exhibit, with owners
4. Named team, allocation, replacement	Written	“Staffing finalized after signing”	Key-personnel clause with approval rights
5. Who wrote the proposal	Orals, delivery lead presents	Sales takes technical questions	Named solution architect in the SOW
6. Subcontracting and offshore share	Written	One blended rate, no split	Staffing-mix and subcontractor disclosure clause
7. Custom code sizing method	Written, sample output in orals	“Our ABAP team will handle it”	Remediation scope tied to tool output
8. Mock loads, reconciliation, dress rehearsal	Written	No count, no migration lead	Number of mock loads and reconciliation sign-off as deliverables
9. Integration inventory and PI/PO plan	Written	No interface count	Interface list as a scope exhibit
10. Assumptions that trigger change orders	Written	“Standard assumptions apply”	Numbered assumptions list, reciprocal where possible
11. Invoices tied to deliverables	Written, then negotiation	Payment by calendar date	Milestone payments on accepted deliverables
12. Change-order rate by role	Written	“To be agreed”	Rate card applying to all change work
13. Hypercare exit and AMS continuity	Written, then orals	“We provide support”	Hypercare exit criteria and SLA schedule
14. The project that slipped	Reference call (your pick)	Only partner-chosen references	None; it’s your go/no-go input

How to Run the SAP RFP So the Answers Mean Something

The best questions still fail inside a rushed process. Len Riley’s 2018 advice in CIO, written for large SAP programs, holds up well, and other ERP selection guides say much the same:

1. Keep the shortlist short. Riley argues for three SIs. Leaner buyer teams in other ERP guidance settle on three to five. More than that and nobody reads the responses properly.
2. Hold a half-day workshop before proposals are due. Written Q&A alone gives partners a thin picture of your program, so they fill the gaps with assumptions, which come back later as change orders.
3. Give each finalist a real day. Two or three hours of orals is not enough for finance, supply chain, and IT to each get to their follow-up questions. Don’t schedule two firms on the same day.
4. Tag requirements as mandatory, important, or optional so partners know what’s negotiable.
5. Normalize the proposals before you negotiate. Compare scope, resources, and rates on the same basis. Otherwise you’re comparing one firm’s assumptions to another’s.
6. Plan for several weeks, set the dates backward from the decision you need, and leave room for reference calls and one final clarification round.

Building that shortlist is the part most teams rush, because the longlist is whoever called them last. It’s also the part we built our engine for: describe your project and let it rank partners on delivery evidence, free and without signing up, then send your RFP to the three that fit.

Riley also makes a point teams tend to skip. If you can’t free up your own people for the selection, you probably can’t free them up for the project either, and it’s better to delay the RFP than to run it with an empty room on your side.

The most expensive mistake is the one this whole list circles: getting good answers and never writing them down. National Grid’s SAP program went live in late 2012 and had to be stabilized at great expense. It later sued its implementation partner, Wipro, for $140 million, and in 2018 the case settled for $75 million, with no admission of liability by either side, according to Wipro’s own stock-exchange filing. A settlement that size is a lawyer’s answer to a question the contract should have settled on day one.

I’ll concede the counterargument. A long RFP with fourteen hard questions costs you weeks, and good boutiques sometimes decline to bid on processes that feel like procurement theater. That’s real. The fix is to ask fewer written questions and more live ones, not to skip them.

Frequently Asked Questions

What are some good questions to ask in an RFP?

Ask questions a bid team can’t answer without the delivery team: name the people and their allocation, list every assumption that triggers a change order, model a scope expansion, and describe how data migration is rehearsed and reconciled. Ask judgment questions live in orals and fact questions in writing, where you can hold the firm to them.

What is an RFP in SAP?

In an SAP project, an RFP (request for proposal) is the document a company sends to a shortlist of implementation partners asking how they would deliver a defined scope, such as an S/4HANA implementation or migration, and at what price. It selects the systems integrator, which is a separate decision from choosing the SAP software itself.

What are the 7 steps in an RFP?

There’s no official seven, but a sound SAP partner RFP runs roughly: define scope and requirements, build a shortlist of three to five firms, hold a pre-proposal workshop, issue the RFP, run full-day oral presentations with the delivery leads, check references you choose, then normalize proposals and move the winning answers into the contract.

What are common RFP mistakes to avoid?

The costly ones: judging the proposal instead of the team, accepting “staffing finalized after signing,” letting assumptions hide in appendices, paying by calendar date instead of accepted deliverables, and calling only the references the partner picked. The biggest is getting good answers in the orals and never writing them into the statement of work.

Which requirements are included in a request for proposal?

A partner RFP usually covers a company overview and goals, the scope (modules, countries, integrations, data), technical constraints, the partner’s qualifications and named team, the pricing structure you want quoted, how responses will be scored, and the timeline and submission rules. Tag each requirement mandatory, important, or optional.

What are the 7 stages of an SAP implementation project?

SAP’s current methodology, SAP Activate, uses six phases rather than seven: Discover, Prepare, Explore, Realize, Deploy, and Run. Seven-stage lists online are usually variations on these. Ask each partner to show real deliverables from each Activate phase on a past project, not just the phase names.

Sources

• Denecken, Musil and Santhanam, SAP Activate: Project Management for SAP S/4HANA Cloud and SAP S/4HANA, 3rd ed. (SAP PRESS, 2025): custom code tooling, three-tier extensibility, dress rehearsal definition.
• Densborn, Finkbohner, Höft, Rubarth, Klöß and Mathäß, Migrating to SAP S/4HANA (SAP PRESS, 2024): the Northern Ireland country-key example.
• Michael Doane, The SAP Blue Book (SAP PRESS, 2012): quoted on global delivery and on “partnership” in billing relationships.
• UpperEdge, “Deloitte’s Defense Unfolds” (November 2025): contract terms in Zimmer Biomet v. Deloitte.
• Loeb & Loeb, Zimmer Biomet’s $172 million lawsuit (September 2025): the complaint’s allegations.
• Wipro stock-exchange filing (2018): National Grid settlement terms.
• Len Riley, “Is your SAP SI partner evaluation missing the mark?”, CIO (2018): shortlist size, workshops, orals, proposal normalization.
• SAP Community, NetWeaver 7.5 maintenance strategy: PI/PO maintenance dates.

An RFP can’t make a weak partner strong. It can make one visible, and it can make a strong one sign up to the things that made it look strong. When you’re ready to build the shortlist, browse the vendor directory by module and industry and bring these fourteen questions with you. The good firms will like them. That’s the point.