The Statement of Work You Didn't Read Is the One You'll Argue About

Most technical leaders inherit a vendor contract the way you inherit weather. It was signed before you turned up, somebody in procurement owns the file, and you find out what's actually in it at the precise moment it stops working in your favour.

Almost nobody reads a statement of work end to end, and honestly, you don't need to. Legal has read the indemnity section and you are not going to improve on their work. But there are three parts that are yours, and if you haven't read those, you're running the delivery blind.

The first is acceptance. What, exactly, counts as the vendor having finished? Look for the phrase "deemed accepted". It usually means that if you don't formally reject the deliverable within some window, ten working days is common, it's accepted whether it works or not. That clause has ended more arguments than any technical evidence I've ever produced, and not in my favour.

The second is client obligations. Every statement of work contains a list of things you have to provide: access, environments, data, decisions, a named contact, sign-off within a stated number of days. This list is the vendor's insurance policy. The day they slip, their account manager will read it back to you, and they will be right, because nobody on your side ever tracked it.

The third is the service levels, and here's the thing people get wrong about those. A service level is not a promise that something will work. It's a formula for how much money you get back when it doesn't. "Four-hour response" means somebody acknowledges your ticket in four hours. It does not mean anything is fixed. I have watched a team plan a cutover around a four-hour response SLA, which is roughly like planning a flight around the airline's compensation policy.

Read those three. Twenty minutes. Do it before you need them, because reading them for the first time during a dispute means you're reading them in front of an audience.

A dairy cooperative, 95 sites across creameries, depots and milk collection points, network refresh running over about seven months. The vendor was delivering the edge hardware and the managed configuration. Clean enough division of labour on paper.

Buried on page eleven of the statement of work, under client obligations, sat one line: the customer would provide working circuits at each site a minimum of fifteen working days before the scheduled installation date.

Nobody on the customer side owned that line. Circuits were being ordered by a facilities team who were working from the depot refurbishment plan, not the network plan, and the two plans had drifted by about three weeks somewhere around site twenty-five. The vendor's engineers started turning up to sites with no service. The vendor, entirely reasonably, started charging abortive visit fees and stopped counting those sites against their own delivery dates.

By site fifty the programme was eleven weeks late and there were two versions of why. The customer's version was that the vendor couldn't deliver. The vendor's version was a spreadsheet of dates showing every site where the obligation had been missed, and their spreadsheet was better than ours. We had status reports. They had evidence.

That's what a dependency really is: a risk with a contract wrapped round it, and the contract has already decided whose fault it is.

The most common failure I see is a project plan that has one line on it saying "vendor delivers edge hardware" with a bar that runs for four months.

That line is a black box, and black boxes only tell you they were wrong when they're already wrong. What you need is the handful of vendor milestones that your work actually depends on, sitting in your plan with dates and names against them. Firmware validated. First site pack issued. Kit landed at the warehouse. The named engineer confirmed for the cutover weekend. Four or five items, not forty. You're not managing their project, you're managing the points where their project touches yours.

Then put the reverse in too. Every client obligation from the contract goes on your plan as a task with your team's name on it, and a date fifteen working days before it's actually needed if that's what the document says. Own what you control. The obligations list is entirely within your control, which means every one you miss is yours.

One more thing worth the effort: know who at the vendor can actually make a decision. The delivery manager on the weekly call frequently cannot. If the first time you meet their account director is when you're angry, you've wasted the relationship you needed most.

There's a myth that escalating a vendor issue damages the relationship. What damages the relationship is escalating late, because by then you're not raising a problem, you're allocating blame for one.

The pattern that works is boring. You raise it on the call. If it doesn't move in a week, you put it in writing to the same person, politely, with the specific ask and a date. If that doesn't move, it goes to their manager, and you tell the person you're doing it before you do it. Never let someone find out they've been escalated over by being copied on the email.

Keep the tone flat. "We're eight days past the date for the firmware validation and it's now on the critical path for the November cutover. Can you confirm a date by Thursday, or tell me what you need from us." No adjectives. No history. No hint that you think they're incompetent, even when you do.

And be honest about the commercial reality underneath all of it. You will probably still be working with this vendor in three years. The engineer who is currently letting you down might be the person who saves your weekend in April. Hard on the problem, never on the person, and never in a way that leaves somebody no route back.

Open the statement of work for whichever vendor is most load-bearing on your current delivery. Find the client obligations section, and write each obligation into your plan as a task with a named owner on your side and a date.

If you get to the end and every one of them already has an owner, you're in better shape than most. If you get to the end and three of them belong to nobody, you've just found where your next eleven weeks were going to go.