Selection — Choosing the vendor, the integrator, and the contract

This is the third of thirteen chapters in "Inside a Large ERP Program." The opening chapter laid out the triple lens this whole document reads each phase through: technical, business, organizational. The second followed scoping, what gets decided before anyone talks about software. This one moves to selection: how you actually choose the vendor, the integrator, and the contract that will govern everything after the signature. I'm writing it from an unusual seat. I've spent most of my career on the client side, but I've also built the RFP responses from inside the integrator. So I know where the seams are, because I've sewn them.

A selection process produces a scoring grid. The grid lines up the candidates against weighted criteria and promises to tell you, objectively, which integrator is best. It's the artifact everyone trusts, because it looks like rigor.

Here's the problem. When two finalists are close, and at the end of a serious RFP they always are, the grid stops deciding anything. What decides is somewhere else, in the part the grid was never built to see. The client who believes the grid protected them has already made their first mistake of the program.

What the grid actually measures

I've sat on the integrator side of an RFP. Putting the response together is an exercise in staging. You don't show the team that will run the project; you show the best consultants you have. You show the best reference projects, the ones as close as possible to this one. You defend the shortest timeline you can stand behind, build the most convincing deck, and if you can, you put a small proof-of-concept on the table to prove you already master one piece of the problem.

Every serious competitor does exactly this. That's the point most clients miss. The grid measures the quality of that staging, not the capacity to deliver, and all the credible finalists know how to make it excellent. So the grid does something the client never intended: it equalizes the strong candidates instead of separating them. It's good at one job, eliminating the obviously unfit, and useless at the one the client actually cares about, choosing between two good firms.

So what breaks the tie? Two things, and neither is on the grid. The first is price, because there's usually one player who comes in aggressively cheap. The second is the firm's flexibility, its willingness to bend to the client's calendar, to absorb a schedule that suits the client more than itself. That's what the close calls turn on. Not the competence the grid spent forty pages scoring.

What the demo doesn't show

The same mechanism runs through every demo you'll watch, and it's worth naming the general rule before the example: what's demonstrable in pre-sales is precisely what was prepared to be demonstrated. The happy path is the product. Everything off that path is invisible until you're the one walking it.

The cleanest illustration I have isn't an integrator demo, it's a vendor one, and the distinction matters. When SAP Fiori was new, it was presented as a mature, finished experience, in the press and in front of clients. It looked ready. Then we implemented it. Every new Fiori app we put on the launchpad came with its own problems: setup, authorizations, integration with the backend, basic functions that should have worked and didn't. Buttons that did nothing. A good share of the apps were buggy, some mildly, some seriously enough that we fell back to the old technology to get the work done.

Two things about that example. First, it's a product-maturity gap, the editor overselling its own roadmap, not an integrator trap. They're different failures. The vendor oversells how finished the product is; the integrator oversells how completely it has mastered it. Both leave you with the same surprise on the project, but you defend against them differently. Second, Fiori today is not the Fiori of that story. It's mature now, and strategically unavoidable, S/4HANA Cloud ships with no SAP GUI at all. But the ground is still mixed: as of late 2025, surveys put a majority of organizations running mixed UI environments, with only a small fraction fully transitioned.

The lever for the client is the same in both cases. Don't accept the showcase. Ask to see the thing that doesn't work cleanly yet, the migration of your actual legacy data, the edge case, the unhappy path. A demo that only shows the prepared scenario has told you nothing you can plan against.

The contract decides the behavior

Now the part most clients get backwards. The contract isn't insurance. It's an incentive structure, and the structure you choose will shape how the integrator behaves for the next two years.

The common belief runs like this: a fixed price (forfait) protects the client and puts the result risk on the integrator, while time-and-materials (régie) is the dangerous one, where the firm just bills hours and has no reason to be efficient. It's a reasonable intuition. It's also mostly wrong.

Start with the fixed price. It pushes the integrator to go fast, to stay inside the envelope and protect the margin. Fast isn't the same as careful. When every extra day eats the firm's profit, the pressure is to close items and move, not to do the quiet, unbilled work that makes a configuration durable. The incentive is speed, and speed has a quality cost you'll pay later.

Now time-and-materials, which is more aligned than its reputation. The more efficient and genuinely useful the firm is, the more the client values them, and the longer and healthier the engagement. Efficiency serves the integrator's own commercial interest directly, because a satisfied client renews. That's a cleaner alignment than people credit it with.

There's a second, more structural reason, and it's the one almost nobody contracts for. The integrator's people are not "fixed-price." A consultant can leave. A freelancer can walk off the engagement. So a fixed-price contract locks the firm into a commitment while its actual workforce stays mobile underneath it. That mismatch, rigid contract over fluid team, is a permanent source of tension on milestones and deliverables: the team shifts, but the commitment can't shift with it, and the gap lands on the schedule. Read the contract for what it really is. Fixed price doesn't buy you peace of mind. It buys you a particular speed and a particular rigidity.

Milestones and penalties: a lever, not a switch

This is where clients most often comfort themselves with a clause that won't do what they think.

Penalties don't fire like a switch. In any real conflict between an integrator and a client, the penalty clause opens a long negotiation over the fine print, not an automatic deduction. The reason is that the operational reality of a complaint is almost impossible to prove contractually.

Here's the mechanism. You write into the contract that ten deliverables are due by a certain date. The ten arrive on time. Contract respected. But the quality? If you judge them thin, hollow, not at the level you needed, how do you prove it? "Delivered" is binary and checkable. "Delivered well" is a judgment, and a judgment doesn't trigger a penalty, it triggers an argument. So you debate. That's the real function of milestones and penalties: they're a lever in that negotiation, a way to bring the firm back to the table and apply pressure. They are not an executable guarantee. The client who signs believing the clause will protect them automatically has misunderstood the tool in their hand.

The team sold is not the team that arrives, and the lock cuts both ways

Of everything in this chapter, this is the one to internalize, because the lever here is mutual and clients usually grab only half of it.

The team that was sold almost never arrives intact. It's rare, genuinely rare, and an informed client doesn't expect otherwise. The strong profiles in the bid were there to win the bid. Delivery staffs from who's free when the project actually starts.

That gives the client a lever it underuses. If the seniority of the profiles doesn't match what was sold in the bid, you can, and should, require the integrator to realign the consultants on the project to what the appel d'offres committed to. That's a contractual right, and most clients let it sit unused.

But the lever runs the other way too, and this is the part that surprises people. The client does not own the consultants. In a tight digital market, good consultants are not obliged to stay. If a client treats them as interchangeable subcontractors, refuses to work in close collaboration, lets the working conditions degrade, they leave. They have somewhere else to go. So the lock is mutual: you can demand the right profiles, and you also have to be worth staying for. Team composition isn't a contractual asset you secured at signature. It's a relationship you maintain, in both directions, for the life of the program.

What you actually chose

Selection isn't won on the day you sign. That day, you didn't buy a guaranteed outcome. You chose who you'll be steering alongside, through all the blind spots your grid never scored, the price pressure, the demo gap, the incentive baked into the contract, the team that quietly changed. The contract won't run any of that on its own. It sets up incentives you'll have to read and pull on for the whole program.

And once the signature is dry, the work moves to what gets built. That's where the next chapter goes: Program architecture — Designing the landscape, the integrations, and the extensions.