How to run an SI RFP and read the answers

An SI (systems integrator) RFP is not a second software RFP. The software RFP tests features; this one tests delivery capability and commercial honesty. The SI runs 40 to 60% of implementation cost, so on a $6M implementation one firm holds $2.4M to $3.6M and most of the risk of a program that goes live late or over budget. A good RFP exposes three things: whether the integrator has committed its best people by name, whether the estimate covers the whole job rather than a convenient slice of it, and whether you understand your own responsibilities before you sign. Write it to force those three answers, and make the answers binding.

SI selection is a separate decision from software selection

Buyers often spend four to six months choosing the software and two weeks choosing the SI. The money and the risk run the other way. The software behaves the same whoever installs it. The difference between a program that lands on its business case and one that does not is design quality, data discipline, test coverage, and whether the business was carried through the change, and all four are delivered by people, most of them the SI's.

So run the SI competition on its own, with its own RFP and its own scoring, after the software is chosen or alongside the final two. A firm that is strong on one tier 1 product can be thin on another, and a firm that is excellent at finance can be weak on the plant floor. The right SI is specific to your product, your industry, and the size of your program, which a software shortlist does not tell you.

What to ask for in writing

Keep the RFP short and demand depth. Six things separate a useful proposal from a brochure, and each one should be a required section the integrator cannot skip.

Methodology-fit. How the firm would run a program of your product, size, and industry, with the phases and the range of weeks each takes, not a fixed-week pitch.
Named staffing. The actual people for each lead role, with CVs, years on this product, and the percentage of their time committed to you by month.
References of your shape. Two or three customers that match you on size, industry, and scope, with the sponsor and process owners reachable, not only the account manager.
Assumptions and exclusions. Everything the price assumes you will do, and everything it leaves out, listed in one place rather than scattered through footnotes.
Rate card by role. The hourly rate for every role and the hours by work area, so you see both halves of the price instead of one blended number.
Change-request process. How a change gets priced and approved, who signs, and how long it takes, so you know the mechanism before the first change arrives.

A ten-page RFP that demands those six things tells you more than a hundred-page one that demands a feature matrix. Ask for each answer in a fixed order so you can lay the proposals side by side.

How to read the staffing answer

The proposal is signed by a firm. The work is done by a team, and the gap between the two is where most SI disappointment lives. The common pattern is the A-team selling and the B-team delivering: the senior experts who win the work roll off within the first weeks after go-live, replaced by juniors you are still billed for at the blended rate.

Read the staffing section for three facts. First, are the people named, with CVs, or does the proposal say "a senior consultant"? A role with no name is a seat the firm has not filled. Second, how many full implementations of this exact product has each lead actually led, and at what size? A lead with ten programs on a different product is a stranger to yours. Third, what percentage of each lead's time is committed to you, and from what date? A solution architect at 20% who is committed elsewhere until two months after your design starts is not really on your program.

Then interview the three leads who matter most, the program manager, the solution architect, and the data lead, the way you would hire them, because for 12 to 36 months you are. Pin start dates and time commitments in writing, and require contractual key-person tenure: name those leads in the contract and require your written approval before the firm replaces any of them. Pair each with a named backup you have also met. Watch turnover after signing. Turnover above 20% in the named roles within six months, or the loss of the program manager, architect, or data lead inside two quarters, is a warning sign that forces a joint review.

Fixed price versus time-and-materials, and what each excludes

No single pricing model fits a whole program, and each one hides a different risk. A fixed price protects you where scope is firm and punishes you where it is not, because the integrator either pads the fee to cover the unknowns or claws them back through change orders. Time-and-materials protects the integrator and leaves you exposed to open-ended hours. Read each quote for what it quietly leaves out.

Pricing model	What it covers well	What it usually excludes	Where it fits
Fixed price	Standard configuration, training, a defined cutover	Data cleanup, integrations to unmapped systems, scope the business has not pinned down	Work you can specify in detail today
Time-and-materials	Genuinely uncertain work, discovery, unknown integrations	A ceiling, unless you write a not-to-exceed cap into the contract	Work no one can scope yet
Hybrid	Most tier 1 and tier 2 programs	A clear line between the two halves, unless you draw it in the contract	Fixed on the firm parts, capped T&M on the rest

The rule that holds up is fixed price on anything you can specify today, time-and-materials with a not-to-exceed cap on anything you cannot, and the line between them written into the contract rather than left to the integrator. A fixed price on data cleanup or on integrations to systems nobody has mapped is a fixed price on a guess, and it returns as a change order the first time the guess is wrong.

The client responsibilities buried in the assumptions

The most expensive part of an SI proposal is often the assumptions page, because that is where the integrator moves work onto your books without counting it. Read it line by line. Four responsibilities hide there most often, and each one blows up a budget that looked complete.

Data cleanup is the largest. Fixing duplicate records, missing fields, and stale master data runs 10 to 15% of the program budget, and it is the client's job, not the SI's. The integrator will load what you give it; making the data loadable is yours. Testing is the second. User acceptance testing needs your business people writing cases and running cycles, often 15 to 30 working days of their time across the program, and a proposal that assumes "client provides testers" has handed you a staffing bill. Backfill is the third. The finance, order-to-cash, and supply chain owners the program needs at least half-time cannot do their day jobs at the same time, so someone has to cover those jobs, and that cost rarely appears in the SI quote. Environments are the fourth. Development, test, training, and staging systems, plus the licenses and infrastructure behind them, are frequently the customer's responsibility in the fine print.

These are not the integrator trying to cheat you. They are real client work, and a good SI names them clearly. The danger is the proposal that assumes them silently, so the headline price looks lower than a rival's that counted them. Price every assumption as money and time on your side before you compare two bids.

A client-versus-SI responsibility split

The business keeps accountability for its own decisions, data, and readiness even when it outsources the implementation. The integrator configures the software and runs the method; it cannot own the choices only your people can make. Write the split down before the program starts, so no task sits in the gap between the two sides.

Responsibility	Client owns	SI owns
Design decisions	Signing off process designs through the business owners	Proposing the configuration and showing the options
Data	Cleanup, validation, and the sign-off that data is correct	The load mechanism and reconciliation reports
Testing	Writing acceptance cases and running UAT cycles	System and integration testing, fixing defects
Staffing and backfill	Freeing owners at least half-time and covering their day jobs	Staffing the named delivery team at the committed percentages
Environments	Licenses, infrastructure, and access	Build and configuration inside the environments
Change control	Approving or rejecting each change and its cost	Pricing the change and showing the hours behind it

A design signed by an IT delegate instead of the business owner is a decision the business has not made, and it reopens as a change order the moment testing reaches it. Track sign-offs by name.

Recommendations

Run the SI RFP as its own competition, separate from the software RFP, because the integrator is 40 to 60% of implementation cost and most of the delivery risk.
Demand six required sections: methodology-fit, named staffing with CVs and time percentages, references of your shape, assumptions and exclusions, a rate card by role, and the change-request process.
Interview the program manager, solution architect, and data lead, and name them in the contract with your written approval required before replacement and a named backup for each.
Treat turnover above 20% in named roles within six months as a warning sign that forces a joint review.
Split pricing by scope certainty: fixed price on what you can specify today, time-and-materials with a not-to-exceed cap on what you cannot.
Read the assumptions page as a bill. Budget data cleanup at 10 to 15% of the program, plus testing time, backfill, and environments, as client costs before you compare bids.
Write the client-versus-SI responsibility split into the contract, and track design and data sign-offs by the business owner's name, not an IT delegate's.

Frequently asked questions

How is an SI RFP different from a software RFP? The software RFP tests features; the SI RFP tests who will deliver and whether the estimate covers the whole job. It asks for a named team, a rate card, references of your shape, a clear list of assumptions and exclusions, and a position on key contract clauses, not a feature list.

What is the single most important thing to pin down in writing? Named key personnel with replacement approval. Name the program manager, architect, and data lead in the contract, require your written sign-off to replace them, and name a backup for each, so the people who win the work are the people who do it.

How do I stop the integrator hiding costs in the assumptions? Require every assumption and exclusion in one section, then price each as money and time on your side. Data cleanup at 10 to 15% of budget, testing time, backfill for freed owners, and environments are the four that most often sit on the client's books uncounted.

Should I ask for a fixed price or time-and-materials? Both, split by scope certainty. Fixed price the work you can specify in detail today, such as standard configuration and training. Put time-and-materials with a not-to-exceed cap on data cleanup, discovery, and integrations to systems nobody has mapped.

If I outsource the implementation, what stays mine? The decisions, the data, and the readiness. The integrator configures the software and runs the method, but only your people can sign off designs, confirm the data is correct, write acceptance tests, and free the business owners to do the work. Those responsibilities do not transfer with the contract.