When a vendor is central to a program, the vendor and the client are usually managing two different definitions of progress. The vendor is responsible for the scope it signed, the milestones it priced and the resources it planned. The client needs a business result: a process that runs, a report that reconciles or a system people can actually use.
Both views are legitimate. Problems begin when the program treats them as though they are the same.
The document that connects them is often filed away after signing.
Start with the agreement, not the status deck
Many programs treat the agreement as a legal artifact. It is negotiated, signed and filed. Delivery then runs from kickoff slides, working plans and status calls. The people managing the work may not return to the document until something goes wrong.
That leaves useful delivery information on the shelf. A statement of work records what the vendor agreed to produce, what the client must provide and what both parties assumed when the work was priced. It should answer practical questions: which activities are included, which prerequisites belong to the client and what evidence is required for acceptance.
I connect those commitments to the delivery plan at the start. Vendor milestones map to plan milestones. Client prerequisites receive owners and dates. Assumptions are made visible while there is still time to test them. Otherwise, a delay attributed to the vendor may turn out to be a client dependency that nobody put on the plan.
A technically sound change can still be the wrong decision
A change request arrives. The technical team confirms that the approach will work. Finance sees the amount. Legal holds the agreement. Each group can perform its own review without anyone deciding whether the change makes sense as a whole.
That is how an operational yes becomes a financial commitment by default.
The safeguard is straightforward: review changes and invoices against the governing agreement before approval, with the delivery need and commercial terms in the same conversation. On a recent engagement, that review led us to decline an upgrade from daily to near-real-time data replication. The proposal was technically sound. The business still operated on daily data and could not identify a benefit that justified the added cost.
That was not a technical rejection. It was a value decision. Saying no preserved the budget for work the business needed more.
Escalate against the commitment, not the mood
When confidence in a vendor begins to slip, the client side often escalates the frustration rather than the evidence. The complaint may be justified, but it gives both sides very little to resolve.
A useful escalation is tied to agreed work: the deliverable, the acceptance criterion, the date and the record of what was communicated. That changes the discussion from a general concern into a specific decision or corrective action.
It also keeps the relationship workable. Most vendor teams want to deliver well. Referring to a shared commitment treats the vendor as a professional counterpart, not an adversary, and gives the team a clear path back to delivery.
This does not replace specialist review. Legal interprets the terms, finance controls payment and technical owners verify the work. The program lead connects the implications before a decision becomes a commitment.
Five questions before approving a change or an invoice
- What does the governing agreement already say about this work?
- Is this an operational improvement or a commercial commitment, and who has decided the second?
- What prerequisite or dependency does this create on the client side, and who owns it?
- What evidence will show the change delivered what it promised?
- If the answer were no, what would the business actually lose?
These questions take minutes to ask. If they go unasked, they tend to return months later as disputes. That is the most expensive time to discover what the agreement says.
Darryl Kwan is the founder and principal of Factum Partners. He leads technology and operating transformation from assessment through delivery.