Statement of work: learning platform and content services

Written by a person. Last read by a person on 2026-09-07, 21 days ago. Its facts were checked by the eval suite on 2026-09-28.

You are judging procurement judgment, or you want to see what a real out-of-scope section looks like.

Scenario-based sample. Halden Systems is invented, and so is every figure about it.

Between Halden Systems and the selected supplier.

Bottom line. 4 deliverables, each with acceptance criteria a third party could apply without us in the room. Payment follows acceptance, never a date. What is out of scope is listed at the same length as what is in, because that is the half every dispute turns on.

Deliverables and acceptance criteria

Each test below is one a stranger could run. Where a test needs judgment, it says who judges it and against what.

D4 is the one vendors negotiate hardest and the one we hold. A platform that cannot report level 2 leaves us measuring completion again, which is the failure the program exists to correct.

Out of scope

Listed at length on purpose. A vendor who has read this and signed cannot later present any of it as a change order, and we cannot later expect it for free.

Writing any of the material. The vendor moves the 44 surviving units onto the platform and writes none of them. Our own people write it: a content lead who holds the standard, and the team that owns each engineering system for the pages about that system. The material is the capability, and buying it would leave us with a subscription instead of one.

Anything that touches our engineering systems. The platform reads who somebody is from our sign-in service and nothing else. It cannot reach a repository, join a build, or write to any engineering tool. That is a security line, not a preference.

Translation and localization. 4 continents and we are still delivering in English. That is a known gap, it is recorded in the strategy, and it is not being solved by this contract.

Change management and internal communications. The vendor does not talk to our staff. Adoption is our problem and buying it produces a rollout with no owner inside the company.

Any measure beyond the 4 levels. No scores for taking part, no leaderboards, and no completion dashboard sold to us as an outcome. We have too much of that number already.

Data migration out. Export is in scope. Anything the vendor would do to help a successor is not, and we have priced our own exit accordingly.

Payment against acceptance

No milestone is released on a date. A vendor who is late is late, and a vendor who is late and paid has been told that the schedule is ours to worry about.

The 30-day tail on D4 exists because reporting is the deliverable most likely to pass a demo and fail in use.

When acceptance fails

First failure. The vendor has 15 working days to remedy, at their cost. The clock on dependent milestones stops. This is expected at least once and is not a dispute.

Second failure on the same deliverable. We take a 15% reduction on that milestone and either accept the remedy or move the deliverable out of scope with a matching reduction. Which of those happens is our choice, not theirs.

Third failure, or any failure on D3. We end the contract for cause, they lose the retention, and they must hand our data back at once. D3 stands alone here because a security line that fails twice is not a quality problem.

If we cause the failure. Where acceptance fails because we did not supply access, data or people on time, the remedy period pauses and the vendor is entitled to a schedule extension of the same length. Stating this protects the relationship: a buyer who never admits a cause is a buyer vendors price defensively.

Governance after signature

We review the vendor monthly, against the scorecard in the budget document. Most of the money in a deal like this is lost after signing, not before it, and a statement of work that stops at acceptance has described the cheap part.