Selecting a system integrator is one of the highest-stakes decisions in any technology programme. It determines who will build the thing you are paying for, how it will be built, and what happens when things go wrong. Yet most organisations make this decision based on the sales process: polished presentations, impressive credentials, and competitive pricing. The sales team is not the delivery team. Here is what to evaluate instead.
Delivery track record, not platform credentials
Every major SI will tell you they have delivered dozens of implementations on the platform you are buying. That is not the question. The question is whether they have delivered programmes of comparable complexity, in comparable industries, with comparable organisational constraints.
An SI that has delivered fifteen Dayforce implementations for mid-market companies is not necessarily equipped to deliver a complex, multi-country HRIS transformation for a regulated enterprise. An SI with extensive SAP S/4HANA experience in manufacturing may not understand the governance requirements of a financial services implementation. Platform credentials are table stakes. Delivery track record at your level of complexity is what matters.
Ask for references that match your programme's profile. Not their best case study. Their most comparable one.
The team on the proposal is not the team on the project
This is the single most common failure point in SI selection. The people who present during the sales process are rarely the people who will deliver the programme. Senior partners and practice leads appear at the pitch. They disappear after the contract is signed. What arrives is a delivery team you have never met, often less experienced, sometimes assembled from whoever is available.
Evaluate the proposed delivery team, not the sales team. Ask to meet the project director, the solution architect, and the workstream leads who will actually be on site. Ask about their tenure at the firm, their experience on comparable programmes, and their availability commitment. If the SI cannot commit named individuals to the delivery team in writing, that tells you something about how they resource their projects.
Commercial structure and incentive alignment
How an SI is paid determines how they behave. A pure time-and-materials contract incentivises hours, not outcomes. A fixed-price contract incentivises scope restriction and change requests. Neither is inherently wrong, but you need to understand what behaviour each commercial structure drives.
Look at the change request mechanism. In most implementations, change requests are where the commercial relationship gets tested. An SI that defines scope narrowly and then charges for every variation is not being dishonest. They are following their commercial incentive. The question is whether the contract gives you enough clarity on what is in scope, what triggers a change request, and what the pricing model is when scope does change.
The same principle applies to milestone payments. Are milestones defined by effort completed or by outcomes achieved? There is a significant difference between "configuration workshops delivered" and "configuration signed off by the client". One rewards activity. The other rewards results.
How they define scope and handle ambiguity
Every technology implementation has ambiguity. Requirements that are not fully defined at contract signing. Integrations that depend on third-party systems. Business processes that will evolve during the programme. How an SI handles this ambiguity defines the relationship.
Some SIs scope tightly and manage ambiguity through formal change control. This is clean but creates friction. Others scope broadly and absorb more variability, but price accordingly. Neither approach is wrong. What matters is that you understand which approach the SI is taking and that it matches your organisation's appetite for commercial rigour.
Pay particular attention to assumptions. Every SI proposal contains a section of assumptions. These are the conditions under which the quoted price and timeline are valid. When those assumptions prove wrong (and they will), the assumptions section becomes the basis for scope variation. Read it carefully. Challenge anything that transfers implementation risk to the client without the client having visibility or control.
Reference checks that test resilience, not success
Every SI will provide references from successful engagements. That is not useful. You already know they can succeed. What you need to know is how they behave when things go wrong.
Ask for references from programmes that experienced difficulty. A timeline overrun. A scope dispute. A go-live delay. Then ask the reference client: How did the SI respond? Did they own the problem or deflect it? Did they bring solutions or change requests? Did the relationship survive the difficulty, and was the programme ultimately successful?
An SI that can only provide references from smooth implementations either has a very short track record or is being selective about what they show you. Every long-tenured SI has navigated programme difficulty. The ones worth hiring are transparent about it.
Methodology and client-side dependency management
Every SI has a methodology. The question is not whether it exists but how it handles the client's responsibilities. In any implementation, the client has dependencies: business process decisions, data cleansing, user acceptance testing, change readiness, executive approvals. These are not the SI's deliverables, but the programme cannot succeed without them.
Evaluate how the SI's methodology tracks and escalates client-side dependencies. Do they simply list them as assumptions and leave it to the client to manage? Or do they actively track readiness, flag risks early, and escalate when client deliverables are at risk? This is particularly important in HRIS implementations where business process decisions often require HR leadership time that is not readily available, and in AI deployments where data governance decisions require board-level engagement.
Knowledge transfer and client independence
The end state of any implementation should be a client that can operate the platform independently. Not all SIs are incentivised to achieve this. Some build delivery models that create long-term dependency: proprietary configuration approaches, specialised skills that only their consultants hold, or support arrangements that lock the client into an ongoing commercial relationship.
Ask about the knowledge transfer plan. When does it start? What does it include? How is it measured? Is there a defined point at which the client is expected to be self-sufficient? If the SI's answer is vague or deferred to "after go-live", the knowledge transfer is not a priority. It is an afterthought.
A good SI wants you to succeed without them. That is the mark of a firm that values its reputation over its recurring revenue.
Selecting an SI is not a procurement exercise. It is a governance decision. The organisation you choose will be embedded in your programme for twelve to twenty-four months. They will influence your platform configuration, your business process design, and your go-live readiness. Getting this decision right requires evaluation that goes well beyond the sales pitch.
How to evaluate a system integrator before signing
The sales team is not the delivery team. The proposal is not the plan. The reference list is not the full story.
Evaluate the people who will actually deliver, the commercial incentives that will shape their behaviour, and how they perform when the programme gets difficult. That is what separates a good SI from a good sales pitch.