How to hold a system integrator accountable during implementation

Define deliverables and acceptance criteria in the contract

The contract is the first accountability mechanism. Most SI contracts define what will be delivered. Few define what done looks like. A deliverable is a thing. An acceptance criterion is the standard that thing must meet.

If the deliverable is "configuration of payroll processing in Dayforce", the acceptance criteria might be "payroll for 500 employees processes without exception in production environment" or "all award rates and deduction rules have been configured and tested". If the deliverable is "SAP S/4HANA implementation", the acceptance criteria should specify "all production transactions can be executed end-to-end without manual workaround" and "integration to legacy general ledger system performs within SLA".

The contract should also specify how acceptance will be verified. Is it the client's business team, or the SI's QA? Usually it is both. Define the process. Define who signs off. Define what happens if the deliverable does not meet the criteria. Does the SI rework it at no cost. What is the timeline for rework. These details matter because they determine whether acceptance is subjective or objective.

For an AI deployment, acceptance criteria might be "model output accuracy of 92% or higher on validation dataset" and "latency under 500ms for 95th percentile requests". Get specific. Specificity is accountability.

Track earned value, not activity

SI status reports are notoriously optimistic. 90 percent complete for three months running. Test script development is "underway". Configuration is "nearly finished". This happens because SI teams report activity, not completion. Work in progress looks like progress, but it is not delivery.

Shift the tracking to earned value. Earned value is the tangible output that can be observed and verified. Configuration that has been tested and signed off. Data migration runs that have completed successfully. Testing cycles that have passed. Code that has been integrated and is running in a stable environment. These are objective measures. You can see them. You can verify them.

Build a simple earned value tracker that maps each deliverable to specific outputs. For Dayforce, that is "payroll cycles processed" and "employee records migrated and verified". For SAP, it is "modules configured and baseline tested" and "custom code delivered and integrated". For an AI model, it is "training data prepared", "model trained", "model validated on test set", "model deployed to staging".

Report this in steering committee weekly. Not percentage complete. Actual deliverables received and verified. This changes the conversation from optimism to reality. The SI will quickly understand that activity is not currency. Delivery is.

Manage change requests commercially

Change requests are the second-largest cost overrun in SI engagements. The first is underestimation. But underestimation is usually hidden in delay, while change requests are visible and contentious.

Most clients treat change requests as accommodations. The SI identifies something that was missed or needs to be different. The client approves it. The SI executes it. The cost and schedule impact flow through. This approach means scope is fluid and accountability is impossible.

Treat change requests as what they are. Variations to scope. Establish a change control board with clear authority. Define a threshold: changes above $50,000 or two weeks require steering committee approval. Below that, the PMO can approve. Require the SI to document each change: the scope, the business justification (is it fixing SI error or responding to client requirement), the effort estimate, the cost, the schedule impact.

Distinguish between error corrections (SI funds them) and genuine scope variations (client funds them). If the SI did not build what the contract specified, that is an error. If the client wants something new that was not in scope, that is a variation. This distinction is not always clear, which is why the change control process must be commercial and documented.

Build a change register and review it weekly in steering committee. Track approval status, cost impact, and schedule impact. This brings discipline. The SI will stop padding change requests when they know every one is scrutinised. The client will stop approving every request when they see the cumulative cost.

Challenge resource substitutions

The team on the proposal is not always the team on the project. The lead architect who pitched the engagement might work on it for two weeks, then hand off to someone junior. The implementation manager might be split across three programmes. The QA lead might be in a different geography.

The contract should specify key roles and seniority levels. Lead solution architect, senior developer, QA lead. Define commitment percentage. What portion of their time is allocated to your programme. Define who can be substituted and who cannot. Usually, the lead role cannot be substituted without steering committee approval.

Review team composition monthly. If the SI substitutes someone, meet with them. Understand their background. Do they have relevant experience. Are they capable of the work. Do not accept substitution as inevitable. The SI made commitments. Hold them to them.

This is a relationship conversation, not a contractual argument. You are not accusing the SI of breach. You are confirming that the team you are working with matches the team you hired. Usually, it does not, and the SI can explain why and offer an alternative. Sometimes the alternative is better. Sometimes it is worse. Either way, you know what you have.

Maintain escalation discipline

Issues emerge constantly on implementations. Configuration problems. Integration failures. Data quality issues. Design disagreements. Most of these are resolved between the SI and the client team through normal work. Some need escalation.

Define the escalation pathway in the governance framework. If a workstream team cannot resolve an issue with the SI, who do they escalate to. Usually it is the programme manager or PMO. The PMO tries to resolve it with the SI account manager. If that does not work, it escalates to steering committee. Define timelines: first-level escalation within two days, second-level within one week.

Maintain discipline about this. Do not escalate issues that should be resolved by the delivery team. Do escalate issues that are blocking delivery, affecting scope, or involving resource decisions. This discipline keeps the relationship professional while ensuring issues are surfaced and resolved.

The escalation pathway is also accountability. When an issue escalates to steering committee, it means the SI and the client team could not resolve it. The steering committee will want to understand why. This incentivises both parties to find solutions at a lower level.

Deploy independent oversight as leverage

The most effective accountability mechanism is independent oversight. A client-side delivery leader who sits between the SI and the steering committee. Someone who verifies status independently, challenges assumptions, and acts as a reality check.

This person is not an SI employee. They do not report to the SI. They report to the client sponsor and the steering committee. They have access to every workstream. They review deliverables before acceptance. They validate earned value claims. They assess risk independently.

In most cases, the SI knows you have this oversight. That knowledge changes behaviour. The SI team is more diligent when they know an independent voice is reviewing their work. Issues are escalated earlier because the SI team knows the oversight will find them anyway.

This is not adversarial. The oversight team is not looking to catch the SI out. They are looking to ensure the programme stays on track. When the SI and the client team are aligned on delivery, oversight is not a barrier. It is a confirmation. When there is misalignment, oversight brings it to light early.